SAML specify the following three methods:
- Bearer scenario
- Holder-of-key Scenario
- Vouches’ Sender Scenario
Bearer scenario
In the bearer scenario, the server automatically trusts the SAML token (after verifying its signature). Thus, in the bearer scenario any client that presents the token can make use of the claims contained in the token (roles, permissions, and so on). It follows that the client must be very careful not to expose the SAML token or to pass it to any untrusted applications. For example, the client/server connection must use encryption, to protect the SAML token from snooping.
Figure below shows a general outline of a typical bearer scenario.
The bearer scenario proceeds as follows:
1. Before invoking an operation on the server, the client sends a RequestSecurityToken (RST) message to the Issue binding of the STS. The RST specifies a KeyType of Bearer.
2. The STS generates a SAML token with subject confirmation type bearer, signs the token using its private key, and then returns the token in a RequestSecurityTokenReply (RSTR) message.
3. The client attempts to invoke an operation on the server, with the SAML token embedded in the SOAP header of the request message, where either the SOAP header or the transport connection must be encrypted, to protect the token.
4. The server checks the signature of the SAML token (using a local copy of the STS public key), to ensure that it has not been tampered with.
Holder-of-key Scenario
The holder-of-key scenario is a refinement of the bearer scenario where, instead of accepting the SAML token when presented by any client, the server attempts to authenticate the client and checks that the client identity matches the holder-of-key identity embedded in the SAML token.
There are two variations on the Holder-of-Key scenario, depending on the value of the KeyType specified in the RST, as follows:
- PublicKey—the client must prove to the WS server that it possesses a particular private key.
- SymmetricKey—the client must prove to the WS server that it possesses a particular symmetric session key.
The following figure shows a general outline of a typical holder-of-key scenario:
The holder-of- key scenario proceeds as follows:
1. Before invoking an operation on the server, the client sends a RequestSecurityToken (RST) message to the Issue binding of the STS. The STS generates a SAML token with subject confirmation type holder-of-key, embeds the client identity in the token (the holder-of-key identity), signs the token using its private key, and then returns the token in a RequestSecurityTokenReply (RSTR) message.
2. The client attempts to invoke an operation on the server, with the SAML token embedded in the SOAP header of the request message.
3. The server checks the signature of the SAML token (using a local copy of the STS public key), to ensure that it has not been tampered with.
4. The server attempts to authenticate the client (for example, by requiring a client X.509 certificate or by checking WS-Security UsernameToken credentials) and checks that the client’s identity matches the holder-of-key identity.
Implementation of this scenario has the following requirements:
- SAML tokens with a Holder-Of-Key subject confirmation method must be protected, so the token cannot be snooped. In most cases, a Holder-Of-Key token combined with HTTPS is sufficient to prevent “a man in the middle” getting possession of the token. This means a security policy that uses a sp:TransportBinding and sp:HttpsToken.
- A Holder-Of-Key token has no encryption or signing keys associated with it, therefore a sp:IssuedToken of SymmetricKey or PublicKey keyType should be used with a sp:SignedEndorsingSupportingTokens.
WSDL example
Message exchange example:
Outbound message to STS
To obtain a SAML security token issued by the security token service, the client sends the following RequestSecurityToken (RST) message to the security token service:
Inbound message from STS
The security token service sends back the following RequestSecurityTokenResponse (RSTR) message, containing a signed SAML token, saml2:Assertion, back to the client:
http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0
http://www.sopera.de/SAML2
ac:classes:X509
Gpzf8TjPATPsQDAm2ojNdEpht1A=
jsbIP1Z25q4Qedn6OSid4QcV4cs6+lgwB+jDiImwMMEoyzp1BjWQWB+1SIbHfa9rtmmTszLdmeTqxSXiAy2CeVZcIDk1UAfySAhDrrmR5N6lJMJqsQgU4o1ysLsZMKwtR2FL+eya7hJ9e4UtQVH1KOa7Cx1rvl4Dr8u8FuN5Myg=
1.2.840.113549.1.9.1=#160b737473407374732e636f6d,CN=www.sts.com,OU=IT Department,O=Sample STS — NOT FOR PRODUCTION,L=Baltimore,ST=Maryland,C=US
MIID5jCCA0+gAwIBAgIJAPahVdM2UPibMA0GCSqGSIb3DQEBBQUAMIGpMQswCQYDVQQGEwJVUzERMA8GA1UECBMITWFyeWxhbmQxEjAQBgNVBAcTCUJhbHRpbW9yZTEpMCcGA1UEChMgU2FtcGxlIFNU UyAtLSBOT1QgRk9SIFBST0RVQ1RJT04xFjAUBgNVBAsTDUlUIERlcGFydG1lbnQxFDASBgNVBAMT C3d3dy5zdHMuY29tMRowGAYJKoZIhvcNAQkBFgtzdHNAc3RzLmNvbTAeFw0xMTAyMDkxODM4MTNa
Fw0yMTAyMDYxODM4MTNaMIGpMQswCQYDVQQGEwJVUzERMA8GA1UECBMITWFyeWxhbmQxEjAQBgNV BAcTCUJhbHRpbW9yZTEpMCcGA1UEChMgU2FtcGxlIFNUUyAtLSBOT1QgRk9SIFBST0RVQ1RJT04x FjAUBgNVBAsTDUlUIERlcGFydG1lbnQxFDASBgNVBAMTC3d3dy5zdHMuY29tMRowGAYJKoZIhvcN AQkBFgtzdHNAc3RzLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAo+f8gs4WcteLdSPW
Pm8+ciyEz7zVmA7kcCGFQQvlO0smxRViWJ1x+yniT5Uu86UrAQjxRJyANBomQrirfE7KPrnCm6iV OsGDEntuIZAf7DFPnrv5p++jAZQuR3vm4ZHXFOFTXmI+/FD5AqLfNi17xiTxZCDYyDdD39CNFTrB 2PkCAwEAAaOCARIwggEOMB0GA1UdDgQWBBRa0A38holQIbJMFW7m5ZSw+iVDHDCB3gYDVR0jBIHW MIHTgBRa0A38holQIbJMFW7m5ZSw+iVDHKGBr6SBrDCBqTELMAkGA1UEBhMCVVMxETAPBgNVBAgT
CE1hcnlsYW5kMRIwEAYDVQQHEwlCYWx0aW1vcmUxKTAnBgNVBAoTIFNhbXBsZSBTVFMgLS0gTk9U IEZPUiBQUk9EVUNUSU9OMRYwFAYDVQQLEw1JVCBEZXBhcnRtZW50MRQwEgYDVQQDEwt3d3cuc3Rz LmNvbTEaMBgGCSqGSIb3DQEJARYLc3RzQHN0cy5jb22CCQD2oVXTNlD4mzAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBACp9yK1I9r++pyFT0yrcaV1m1Sub6urJH+GxQLBaTnTsaPLuzq2g
IsJHpwk5XggB+IDe69iKKeb74Vt8aOe5usIWVASgi9ckqCwdfTqYu6KG9BlezqHZdExnIG2v/cD/ 3NkKr7O/a7DjlbE6FZ4G1nrOfVJkjmeAa6txtYm1Dm/f
_181835fb981efecaf71d80ecd5fc3c74
_181835fb981efecaf71d80ecd5fc3c74
Outbound message to the server
The client now embeds the signed SAML token, saml2:Assertion, in the WS-Security header, wsse:Security, when it invokes the greetMeoperation on the server:
http://www.sopera.de/SAML2
ac:classes:X509
Gpzf8TjPATPsQDAm2ojNdEpht1A=
jsbIP1Z25q4Qedn6OSid4QcV4cs6+lgwB+jDiImwMMEoyzp1BjWQWB+1SIbHfa9rtmmTszLdmeTqxSXiAy2CeVZcIDk1UAfySAhDrrmR5N6lJMJqsQgU4o1ysLsZMKwtR2FL+eya7hJ9e4UtQVH1KOa7Cx1rvl4Dr8u8FuN5Myg=
1.2.840.113549.1.9.1=#160b737473407374732e636f6d,CN=www.sts.com,OU=IT Department,O=Sample STS — NOT FOR PRODUCTION,L=Baltimore,ST=Maryland,C=US
MIID5jCCA0+gAwIBAgIJAPahVdM2UPibMA0GCSqGSIb3DQEBBQUAMIGpMQswCQYDVQQGEwJVUzERMA8GA1UECBMITWFyeWxhbmQxEjAQBgNVBAcTCUJhbHRpbW9yZTEpMCcGA1UEChMgU2FtcGxlIFNU UyAtLSBOT1QgRk9SIFBST0RVQ1RJT04xFjAUBgNVBAsTDUlUIERlcGFydG1lbnQxFDASBgNVBAMT C3d3dy5zdHMuY29tMRowGAYJKoZIhvcNAQkBFgtzdHNAc3RzLmNvbTAeFw0xMTAyMDkxODM4MTNa
Fw0yMTAyMDYxODM4MTNaMIGpMQswCQYDVQQGEwJVUzERMA8GA1UECBMITWFyeWxhbmQxEjAQBgNV BAcTCUJhbHRpbW9yZTEpMCcGA1UEChMgU2FtcGxlIFNUUyAtLSBOT1QgRk9SIFBST0RVQ1RJT04x FjAUBgNVBAsTDUlUIERlcGFydG1lbnQxFDASBgNVBAMTC3d3dy5zdHMuY29tMRowGAYJKoZIhvcN AQkBFgtzdHNAc3RzLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAo+f8gs4WcteLdSPW
Pm8+ciyEz7zVmA7kcCGFQQvlO0smxRViWJ1x+yniT5Uu86UrAQjxRJyANBomQrirfE7KPrnCm6iV OsGDEntuIZAf7DFPnrv5p++jAZQuR3vm4ZHXFOFTXmI+/FD5AqLfNi17xiTxZCDYyDdD39CNFTrB 2PkCAwEAAaOCARIwggEOMB0GA1UdDgQWBBRa0A38holQIbJMFW7m5ZSw+iVDHDCB3gYDVR0jBIHW MIHTgBRa0A38holQIbJMFW7m5ZSw+iVDHKGBr6SBrDCBqTELMAkGA1UEBhMCVVMxETAPBgNVBAgT
CE1hcnlsYW5kMRIwEAYDVQQHEwlCYWx0aW1vcmUxKTAnBgNVBAoTIFNhbXBsZSBTVFMgLS0gTk9U IEZPUiBQUk9EVUNUSU9OMRYwFAYDVQQLEw1JVCBEZXBhcnRtZW50MRQwEgYDVQQDEwt3d3cuc3Rz LmNvbTEaMBgGCSqGSIb3DQEJARYLc3RzQHN0cy5jb22CCQD2oVXTNlD4mzAMBgNVHRMEBTADAQH/ MA0GCSqGSIb3DQEBBQUAA4GBACp9yK1I9r++pyFT0yrcaV1m1Sub6urJH+GxQLBaTnTsaPLuzq2g
IsJHpwk5XggB+IDe69iKKeb74Vt8aOe5usIWVASgi9ckqCwdfTqYu6KG9BlezqHZdExnIG2v/cD/ 3NkKr7O/a7DjlbE6FZ4G1nrOfVJkjmeAa6txtYm1Dm/f
TEST
Inbound message from the server
When the server receives the preceding SOAP request, the soap:mustUnderstand=”1″ attribute setting ensures that the server must process the security header. In addition, the presence of a signature in the SAML token means that the server must confirm the signature.After successfully processing the security header, the server sends back the following reply to the client:
Vouches’ Sender Scenario
You can use the sender-vouches confirmation method for SSO scenarios where the WS intermediary system has a trust relationship with the back-end system.
This scenario defines four different entities:
(1) a client,
(2) an intermediary,
(3) SAML issuer,
and (4) a back-end system that is the WS provider.
For an overview of the system interaction for this scenario, see the figure below:
The following steps describe in more detail the lifetime of a request using the SAML sender-vouches profile.
1. The client sends a request to the intermediary. This request can be of any kind but must contain valid authentication information to log the client on to the intermediary.
2. The intermediary authenticates the client. To process the request, the intermediary needs to retrieve information from the back-end system using Web Services forwarding mechanisms for the client’s authentication information.
3. To forward the client’s authentication, the intermediary needs to add a SAML assertion to the request. This assertion is provided by the issuer. To get it the intermediary needs to forward all necessary login information to the issuer, which in return creates the SAML assertion.
4. The assertion is added to the Web service request. To vouch for the integrity of the SAML assertion and the payload of the Web service request both are signed by the intermediary using a digital signature. The intermediary is able to vouch for the SAML assertion because there is an explicit trust relationship between the back-end system and the intermediary, which enables the back-end system to verify the digital signature.
5. The Web service request containing the SAML assertion is now sent to the back-end system.
6. The back-end system attempts to verify the SAML assertion. Other than checking the correctness of the SAML assertion, the back-end system also verifies that the issuer is trusted and there is an existing trust relationship between the intermediary and the back-end system. After successful verification, the client is logged on to the system and the request is processed.
7. The back-end system sends a response to the intermediary. The intermediary uses the received data to complete the client’s request and send a response to the client.
SAML 2.0 Assertion example:
https://technet.microsoft.com/en-us/library/dn133771.aspx?f=255&MSPPError=-2147217396
References:
1. https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Fuse/6.0/html/Web_Services_Security_Guide/files/WsTrust-BasicScenario.html
2. https://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf 3. http://dulanja.blogspot.com/2013/01/saml-subject-confirmation-methods.html
4. http://fusionsecurity.blogspot.com/2009/09/bearer-confirmation-method-huh-what-is.html
5. http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-holder-of-key.pdf
6. https://docs.jboss.org/author/display/JBWS/SAML+Holder-Of-Key+Assertion+Scenario?_sscc=t
7. https://help.sap.com/saphelp_nwpi71/helpdata/en/44/322225a52d5447e10000000a422035/content.htm
8. https://access.redhat.com/documentation/en-US/Fuse_ESB/4.4.1/html/Web_Services_Security_Guide/files/WsTrust-Demo-Messages.html