Portable Identity & WS - Trust Prabath Siriwardena Director, Security Architecture

Portable Identity When a subject identity established and verified in one trust domain wants to assert its identity and rights in another trust domain, this is said to be portable. An assertion is a claim that may be challenged and proven before being believed. Authentication is an assertion that a subject is who he claims to be. Authorization is an assertion that the subject identity is allowed to perform a specific action.

Portable Identity & SOAP When two entities with different trust models want interact, SOAP has no standardized and interoperable way to communicate their security properties. Because SOAP messages are sent from one trust domain to another, the identity of the requesting subject and its assertions must travel with the message.

SAML SAML is the XML based standard created to enable portable identities and the assertions these identities want to make. SAML not tied in to any transport. Defines a standard message exchange protocol. Specifies how it is transported.

SAML SAML is fundamentally three XML-based mechanisms. – Assertions (An XML schema and definition security assertions). – Protocol (An XML schema for request/response protocol). – Bindings (Rules for using assertions with standards transport and messaging frameworks).

SAML Assertions SAML defines three types of assertions. – Authentication – Authorization – Attributes

SAML Encrypted Assertions The element represents an assertion in encrypted fashion, as defined by the XML Encryption Syntax and Processing specification. The element.

SAML SAML is fundamentally three XML-based mechanisms. – Assertions (An XML schema and definition security assertions). – Protocol (An XML schema for request/response protocol). – Bindings (Rules for using assertions with standards transport and messaging frameworks).

SAML and WS-Security WS-Security has a security extension to SOAP, specifies SAML assertions as one of the types of security tokens it supports in the SOAP header.

SAML and WS-Security <saml:NameIdentifier NameQualifier=" Format=“urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName”> uid=joe,ou=people,ou=saml-demo,o=baltimore.com urn:oasis:names:tc:SAML:1.0:cm:bearer...

SAML and WS-Security...

SAML and WS-Security <saml:Assertion xmlns:saml="..." AssertionID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" IssueInstant=" T00:46:02Z" Issuer=” MajorVersion="1" MinorVersion="1"> <wsse:SecurityTokenReference wsu:Id=”STR1” wsse11:TokenType=” <wsse:KeyIdentifier wsu:Id=”...” ValueType=” _a75adf55-01d7-40cc-929f-dbd8372ebdfc...

SAML and WS-Security When a key identifier is used to reference a SAML assertion, it MUST contain as its element value the corresponding SAML assertion identifier. The key identifier MUST also contain a ValueType. The key identifier MUST NOT include an EncodingType4 attribute and the element content of the key identifier MUST be encoded as xs:string.

SAML and WS-Security <wsse:SecurityTokenReference xmlns:wsse="..." xmlns:wsu="..." xmlns:wsse11="..." wsu:Id=”STR1” wsse11:TokenType=” <saml:AuthorityBinding xmlns:saml="..." Binding=”urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding” Location=” AuthorityKind= “samlp:AssertionIdReference”/> <wsse:KeyIdentifier wsu:Id=”...” ValueType=” _a75adf55-01d7-40cc-929f-dbd8372ebdfc

SAML and WS-Security A SAML V1.1 assertion that exists outside of a header may be referenced from the header element by including (in the ) a element that defines the location, binding, and query that may be used to acquire the identified assertion at a SAML assertion authority or responder. Remote references to V2.0 assertions are made by Direct reference URI.

SAML and WS-Security <wsse:SecurityTokenReference xmlns:wsse="..." xmlns:wsu="..." xmlns:wsse11="...” wsu:Id=”...” wsse11:TokenType=” 1.1#SAMLV2.0”>

QUESTION 1 When do we want to reference a SAML token and when do we not to ?

Subject Confirmation Bearer (defined in SAML core specification) Holder-of-Key (defined in SAML token profile for SOAP) Sender-vouches (defined in SAML token profile for SOAP) Allows the subject to be confirmed. If more than one subject confirmation is provided, then satisfying any one of them is sufficient to confirm the subject for the purpose of applying the assertion.

Bearer Anyone who holds the SAML token can use it. The sender need to prove the possession of the token. If you know OAuth 2.0 – this is just like the OAuth 2.0 Bearer token. This does not have a key. So – Bearer SAML tokens cannot be used to sign on encrypt messages. No point if referring Bearer token from a

Holder-of-Key Sender (Subject) of the token should prove the possession of the token. This has a key in it and it can be used to sign or encrypt messages. Holder-of-Key SAML tokens can be referred from a

Holder-of-Key urn:oasis:names:tc:SAML:1.0:cm:holder-of-key Ye9D13/K1GFRvJjgw1kSr5/rYxE= a/kALeV0b0Y3oNcE7fdepUuF0sbQUGs012r87BMBUx/FL8

Sender Vouches The attesting entity, (presumed to be) different from the subject, vouches for the verification of the subject. The receiver MUST have an existing trust relationship with the attesting entity. The attesting entity MUST protect the assertion in combination with the message content against modification by another party.

Sender Vouches

WS-Trust Trust – Trust is the characteristic that one entity is willing to rely upon a second entity to execute a set of actions and/or to make set of assertions about a set of subjects and/or scopes. Direct Trust – Direct trust is when a relying party accepts as true all (or some subset of) the claims in the token sent by the requestor. Direct Brokered Trust – Direct Brokered Trust is when one party trusts a second party who, in turn, trusts or vouches for, a third party. Indirect Brokered Trust – Indirect Brokered Trust is a variation on direct brokered trust where the second party negotiates with the third party, or additional parties, to assess the trust of the third party.

WS-Trust

A protocol framework – Supports different exchange patterns Builds on WS-Security Defines mechanisms for brokering trust Provides ways to establish and access the presence of trust relationship Defines a mechanism for issuing and exchanging security tokens Security Token Service – Anyone can be an STS

Common Patterns Issuance Defines mechanisms for requesting a new token Renewal Defines mechanisms for renewing previously issued tokens Validation Defines mechanisms for verifying validity of tokens Cancellation Defines mechanisms for cancelling a previously issued token

WS-Trust REQUESTERISSUER RST RSTR

RequestSecurityToken 1.1#SAMLV1.1

RequestSecurityTokenCollection /BatchIssue

RequestSecurityTokenResponse profile-1.1#SAMLV

RequestSecurityTokenResponseCollection... +

WS – Trust Token Issuer (Example) T10:29:17.487Z T10:34:17.487Z nVY8/so9I3uvI3OSXDcyb+9kxWxMFNiwzT7qcsr5Hpw=

WS – Trust Token Issuer (Example) 2 2 AppliesTo This is the end point where the client going to use this token against. KeyType Use Symmetric key when generating the key for the SubjectConfirmation. KeySize Use this key size when generating the key for the SubjectConfirmation.

WS – Trust Token Issuer (Example) 3 3 Entropy/BinarySecret WS-Trust allows the requestor to provide input to the key material via a wst:Entropy element in the request. The requestor might do this to satisfy itself as to the degree of entropy (cryptographic randomness if you will) of at least some of the material used to generate the actual key which is used for SubjectConfirmation. Entropy/ComputedKeyAlgorithm : The key derivation algorithm to use if using a symmetric key for P, where P is computed using client, server, or combined entropy. With the key is computed using P_SHA1 from the TLS specification to generate a bit stream using entropy from both sides. The exact form is: key = P_SHA1 (EntREQ, EntRES) It is RECOMMENDED that EntREQ be a string of length at least 128 bits.

WS – Trust Token Issuer (Example) 4 4 Based on the Key Type in the request - STS will decide whether to use Holder-of-key or not. For following key types, holder-of-key subject confirmation method will be used trust/200512/PublicKey 2. trust/200512/SymmetricKey If it is SymmetricKey - then STS will generate a key - encrypt the key using the public certificate corresponding to the end point attached to the AppliesTo element in the RST and add that to the SubjectConfirmation element in the response.

WS – Trust Token Issuer (Example) 5 5 Key Generation If client provides an entropy and the key computation algorithm is then, the key is generated as a function of the client entropy and the STS entropy. If client provides an entropy but the key computation algorithm is NOT then, the key is same as the client entropy. If neither of above happens, then the server generates an ephemeral key. Whatever the way the key is generated, it will be encrypted with the certificate corresponding to the AppliesTo end point and will be added in to the SubjectConfirmation element in the response.

WS – Trust Token Issuer (Example) 6 6 urn:oasis:names:tc:SAML:1.0:cm:holder-of-key Ye9D13/K1GFRvJjgw1kSr5/rYxE= a/kALeV0b0Y3oNcE7fdepUuF0sbQUGs012r87BMBUx/FL8

WS – Trust Token Issuer (Example) 7 7 As per the above code, what you see inside CipherValue element is the encrypted key. And it is encrypted from a certificate which is having the thumbprint reference Ye9D13/K1GFRvJjgw1kSr5/rYxE=. Only the service which owns the certificate having the thumbprint reference Ye9D13/K1GFRvJjgw1kSr5/rYxE= would be able to decrypt the key - which is in fact the service end point attached to the AppliesTo element. Can anybody in the middle fool the service endpoint just by replacing the SubjectConfirmation element..? This is prevented by STS signing the SubjectConfirmation element along with Assertion parent element with it's private key. The SAML token is protected for integrity.

WS – Trust Token Issuer (Example) 8 8 Passing the generated key to the requestor (subject) Client application can use SAML token to encrypt/sign the messages going from the client to the service end point. Then the question is which key would the client use to sign and encrypt - it's the same key added to the SubjectConfirmation by the STS - but it's encrypted with the public key of the service end point - so, client won't be able to decrypt it and get access to the hidden key. There is another way, STS passes the generated key to the client. Let's look at the following element also included in the response passed from the STS to the client - this is out side the Assertion element.

WS – Trust Token Issuer (Example) 9 9 Passing the generated key to the requestor (subject) <wst:BinarySecret Type=" Nonce">3nBXagllniQA8UEAs5uRVJFrKb9dPZITK76Xk/XCO5o= Here in the Entropy/BinarySecret STS passed the entropy created to generate the key. The key is generated as a function of the client entropy and the STS entropy - client already knows the client entropy and can find the STS entropy inside Entropy/BinarySecret in the response - so, client can derive the key from those.

Entropy In information theory, entropy is a measure of the uncertainty associated with a random variable. In other words, entropy adds randomness to a generated key. In WS-Trust, under Holder-of-Key scenario - the Security Token Service has to generate a key and pass that to the client - which will later be used between the client and the service to secure the communication. nVY8/so9I3uvI3OSXDcyb+9kxWxMFNiwzT7qcsr5Hpw=

Entropy The optional element allows a requestor to specify entropy that is to be used in creating the key. The value of this element should be either a or depending on whether or not the key is encrypted. Secrets should be encrypted unless the transport/channel is already providing encryption. The BinarySecret element specifies a base64 encoded sequence of octets representing the requestor's entropy.

Entropy The keys resulting from request are determined in one of three ways. 1. Specific 2. Partial 3. Omitted

Entropy In the case of specific keys, a element is included in the response which indicates the specific key(s) to use unless the key was provided by the requestor(in which case there is no need to return it). This happens if the requestor does not provide entropy or issuer rejects the requestor's entropy. In the case of partial, the element is included in the response, which indicates partial key material from the issuer (not the full key) that is combined (by each party) with the requestor's entropy to determine the resulting key(s). In this case a element is returned inside the to indicate how the key is computed. This happens if the requestor provides entropy and the issuer honors it. Here you will see, in the response it will have an Entropy element - which includes the issuer's entropy. <wst:BinarySecret Type="

Entropy In the case of omitted, an existing key is used or the resulting token is not directly associated with a key. This happens if the requestor provides entropy and the responder doesn't (issuer uses the requestor's key), then a proof-of-possession token need not be returned.

Entropy

ActAs

This OTPIONAL element in the RST indicates that the requested token is expected to contain information about the identity represented by the content of this element and the token requestor intends to use the returned token to act as this identity. The identity that the requestor wants to act-as is specified by placing a security token or element within the element

RequestedAttachedReferences Since returned tokens (RquestedSecurityToken) are considered opaque to the requestor, this OPTIONAL element is specified to indicate how to reference the returned token when that token doesn't support references using URI fragments (XML ID). This element contains a element that can be used verbatim to reference the token (when the token is placed inside a message). Typically tokens allow the use of wsu:Id so this element isn't required. Note that a token MAY support multiple reference mechanisms; this indicates the issuer’s preferred mechanism. When encrypted tokens are returned, this element is not needed since the element supports an ID reference. If this element is not present in the RSTR then the recipient can assume that the returned token (when present in a message) supports references using URI fragments.

RequestedAttachedReferences <SecurityTokenReference TokenType= > _55696a58-9dd2-

RequestedUnAttachedReferences In some cases tokens need not be present in the message. This OPTIONAL element is specified to indicate how to reference the token when it is not placed inside the message. This element contains a element that can be used verbatim to reference the token (when the token is not placed inside a message) for replies. Note that a token MAY support multiple external reference mechanisms; this indicates the issuer’s preferred mechanism.

lean. enterprise. middleware