WS-SecurityPolicy is a very interesting specification. It really shows that it incorporated the feedback of people which actually used WS-Security: it address historical concerns like the order of operations, the role of the tokens (initiator rather than recipient), the protection of elements of the wsse:security header… hey, it even acknowledges that sometimes the security may come from the transport! It gives up some “mathematical” beauty in favor of a more immediate usage, at the price of a proliferation of the assertions. And it’s clear from the property approach that it was designed also with the enforcing stage in mind, besided the checking one. However it got pretty think, it’s a 90 pg PDF: and some part of it is inevitably syntactic sugar.<\/P>
\n
So I thought it could be useful to pull out a Bignami out of it. “Bignami” was (is?) a collection of small sub-pocket books, which covered the absolute essentials of various school subject (Math, Latin, Italian, Phisics…) and was especially handy before classworks. I have to warn you, in the shrinking effort I may leave out important things or simplify to the point of being wrong (despite mr. Einstein advice. BTW: I had the pleasure to have tea more than once with mr. Trautman, he’s an exquisite person); plus, here it’s way past midnight and the usual drowsiness is already clouding my judgement \ud83d\ude42<\/P>
\n
==================================================<\/P>
\n
WS-SecurityPolicy describes an assertion framework which covers WSS, WS-Trust and WS-SecueConversation; however it can leverage security features of transport, too. Let’s have a short summary of relevant sections.<\/P>
\n
3.1 – WS-SP assertions fall in 5 main categories. protection assertions<\/STRONG> rule confidentiality and integrity; conditional assettions <\/STRONG>express conditions; security binding assertions<\/STRONG> gather general assertions, ruling how to deal with parts: quoting the spec, “At its simplest form, the security binding restricts what can be placed in the wsse:Security header and the associated processing rules.”; supporting token assertions<\/STRONG> describe token which perform “ancillary” operations in respect to the ones which determines the binding pattern (more about this later); WSS & trust assertions<\/STRONG> express how certain specific aspects of the specifications are applied.<\/P> 3.2 – in depht explanation of nesting and “combinatorial” assetion algebra<\/P> 3.3 – gives more detail about what a binding is. WS-SP supplies 3 bindings: symmetric binding, asymmetric binding, transport binding. They represent common patterns, that’s to say specific values for the following carachteristics:<\/P> 4 – details of the nesting machanism. From now on, every assertion will implicitly have a sp:policy subassertion evan if I don’t mention it<\/P> 4.2 – policy subjects. there are 3 possible subjects to which the policy may refer to: Message<\/STRONG>, Operation<\/STRONG>, Endpoint<\/STRONG>. Different kinds of assertions apply to different subjects.<\/P> 5 – Protection Assertions, straightforward.<\/P> 5-1 Integrity<\/STRONG>, tells you what to sign. Comes in 2 flavors: SignedParts<\/STRONG>, which can specify parts by qname (body or headers, nothing inside wsse:security), and SignedElements<\/STRONG>, which specify the signee via XPath.<\/P> 5-2 Confidentiality<\/STRONG>, with EncryptedParts<\/STRONG> and EncryptedElements<\/STRONG> pretty symmetric to the aboves.<\/P> 5-3 RequiredElemnts<\/STRONG>, tells you (via XPath) what must be present in the message <\/P> 6 token assertions. Features a complete collection of modern kinds. I’ll be very quick & cryptic from now on<\/P> 6-1-1: TokenInclusion<\/STRONG> property: determines how the token must be included<\/P> 6-2 Derived Keys<\/STRONG> property: indicates if it is mandated what is explained in ws-SecureConversation spec.<\/P> 6-3-1 UsernameToken<\/STRONG> 6-3-2 IssuedToken<\/STRONG> 633 X509Token<\/STRONG> Includeserial,keyid,thumbprint, X509 token profile props<\/P> 634 KerberosToken<\/STRONG> 635 SpnegoContextToken<\/STRONG> (n-leg ws-trust) 636 SecurityContextToken<\/STRONG> <\/P> Assumes you already have one SCT; otherwise you need SecureConversationToken (below) or IssuedToken 637 SecureConversationToken<\/STRONG> 638 SamlToken<\/STRONG> (assumes u already have one) 639 RelToken<\/STRONG> 6310 HttpsToken<\/STRONG><\/P> Indicates use of HTTPS. Can specify if the client certificate is mandatory 7 Security Bindings Properties<\/P> Like variables in code, properties are assigned according to the content of the corresponding assertions. it seems that all together they are the state of the policy. quick descriptions<\/P> 71 algorithm suite, kind of algorithm used (DES and similar) 8 securitybinding assertions<\/P> how properties are mapped into assertions 83 TransportBinding <\/P> This is the first security binding we meet. No WSS requested. It has the following subassertions: 84 SymmetricBinding<\/P> Assumes symmetric interaction between initiator and recipient. And the use of WSS, of course. 85 AsymmetricBinding<\/P> Assumes asymmetrical communication. And WSS. 9 Supporting Tokens assertions<\/P> Those tokens are not the ones which determines the kind of security binding, yet they are present in the message and they often perform an active role. 4 kinds.<\/P> 91 SupportingTokens<\/STRONG> simply appear in wsse:security. They can sign and encrypt different parts. Subassertions: 92 SignedSupportingTokens<\/STRONG>, as the above but they are included in the main signature (the one of the security binding level)<\/P> 93 EndorsingSupportingTokens<\/STRONG>, they sign the main signature<\/P> 94 SignedEndorsingSupportingTokens<\/STRONG>. The two tokens sign each other (92+93)<\/P> 10: wss options<\/P> Those are options of the WSS standard,can’t really dig them at this hour of the night \ud83d\ude42 two main flavor: Wss10, Wss11. They decide the version of WSS to which they refer to, and they contains the options in form of subassertions. For example a property may decide if the refcipien must be able to understand embedded tokens, or references made by serial number.<\/P> 11: ws-trust options<\/P> Same as above, but for WS-Trust. Trust10 is the container of MustSupportClientchallenge, Server challenge, Client entropy, Server entropy, IssuedToken…<\/P> WS-SecurityPolicy is a very interesting specification. It really shows that it incorporated the feedback of people which actually used WS-Security: it address historical concerns like the order of operations, the role of the tokens (initiator rather than recipient), the protection of elements of the wsse:security header… hey, it even acknowledges that sometimes the security…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"footnotes":""},"categories":[61],"tags":[],"class_list":["post-753","post","type-post","status-publish","format-standard","hentry","category-architecture-ws"],"_links":{"self":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/753","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/comments?post=753"}],"version-history":[{"count":1,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/753\/revisions"}],"predecessor-version":[{"id":1850,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/753\/revisions\/1850"}],"wp:attachment":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/media?parent=753"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/categories?post=753"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/tags?post=753"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
U can speciffy the ut profile version (10,11). Usual worning about cryptographic weakness.<\/P>
\n
Interesting! A token issued as described in ws-trust. Subassertions:<\/P>
\n
\n
\n
\n
\n
\n
\n
Standard X509 token. Usual properties, distinction per profile level<\/P>
\n
\n
Include, derived, keyid, kerberos profile<\/P>
\n
Include, issuer, derivedkeys<\/P>
\n
\n
Ws-sc
Include,derived, requireexternalurireference,sc10seccontexttoken<\/P>
\n
If it describes full cycle (issue+usage) of SCT, there’s the need for 2 policies: Bootstrap and Outer
Include, issuer (if different from target), derived, externaluri<\/P>
\n
Include, derivedm, samlvers(10,11,20)+profvers(10,11)<\/P>
\n
Include,requirederived, requirekeyidrf, relver (10,20)+profvers (10,11)<\/P>
\n
\n
<\/P>
\n
\n
\n
72 timestamp
73 protection order (encryptbeforesigning, signbeforeencrypting)
74 Signature protection (signature has to be encrypted)
75 tokenprotection (token has to be included in the signature)
76 entire header and body signature (most patrs have to be signed)
77 SecurityHeaderLayout (how wsse:security elements order is affected by the policy) <\/P>
\n
\n
\n
\n
\n
\n
\n
81 AlgorithmSuite<\/STRONG> sp:Basic128<\/STRONG>, sp:TripleDes<\/STRONG>, etc etc
82 Layout<\/STRONG> sp:Strict<\/STRONG>,\u2026 LaxTsFist<\/STRONG>,\u2026
<\/P>
\n
\n
Transporttoken, Algorithmsuite, Layout, includetimestamp<\/P>
\n
\n
Can have EncryptionToken and SignatureToken, OR ProtectionToken (used for both encryption and signing). The two sides of the OR cannot mix. If the messages go back and forth, the above directives will be honored also from ecipient to intiator (SignatureToken will sign both requeste and replies). Subassertions:
Algosuite, layout, includets, encryptbeforesign, protectstoken, onlysignentireheadersandbody<\/P>
\n
\n
InitiatorToken<\/STRONG> is used for signing initiator->recipient and encrypting recipient->initiator, RecipientToken <\/STRONG>is specular. Subassertions:
algosuite, layout, includets, encbeforesign, protrctstoken, onlysignentireheadersandbody<\/P>
\n
\n
\n
Token assertion, Algosuite, SignedParts\/Elements,encparts\/els<\/P>
\n
\n
\n
\n
\n
\n
\n
\n
<\/P><\/p>\n