|
|
Use SAML Token for authentication, Part I
Jong Lee's Blog |
August 9, 2005 3:36 PM
|
Comments (2)
Subject confirmation refers to the method that is used to verify the subject of SAML subject statement in a SAML assertion. An attesting entity, which is presumed to be different from the subject, vouches for the verification of the subject. The receiver of the SAML token has already established a trust relationship with the attesting entity. By confirming the attesting entity, the receiver hence trusts the subject. This method of subject confirmation is called sender-vouches.
A sender-vouches SAML token would look like this:
<Assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
AssertionID="de1d35cd610786bef62d157adbfbe342"
IssueInstant="2005-07-11T22:45:20.053Z" Issuer="http://www.bea.com/saml";
MajorVersion="1" MinorVersion="1"
wsu:Id="CS2AkOQw2PZGrygZH1rX6iN65zBHlwaKqHMpEfiOOtM486D463r1">
<AuthenticationStatement AuthenticationInstant="2005-07-11T22:45:20.044Z"
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified">
<Subject>
<NameIdentifier
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
NameQualifier="wsrpConsumer">weblogic</NameIdentifier>
<SubjectConfirmation>
<ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</ConfirmationMethod>
</SubjectConfirmation>
</Subject>
</AuthenticationStatement>
</Assertion>
The receiver of this SAML token does not need to know anything about the subject "weblogic", but to trust the issuer "http://www.bea.com/saml" and validate this assertion. It's strongly recommended for the attesting entity to protect the SAML assertion by digitally sign and/or encrypt it, especially in the unsecured transport channel.
You can download and play with my dev2dev sample here.
The use case demonstrates the following:
- A web service client needs to invoke a secure operation of Web Service B.
- Web Service B knows nothing about this client, but has established a trust relationship with Web Service A.
- The client sends a valid Username token to Web Service A for authentication.
- Web Service A authenticates the client and generates a valid SAML token for the client.
- Web Service B now then authenticates the SAML token and grants access to the client.
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Is this really the intended use of sender-vouches?
This seems more like a use-case for the "bearer" confirmation method. A sender-vouches assertion should only be trusted if the relying party (Web Service B) is able to authenticate the sender some other way (an SSL client certificate or an XML digital signature covering both the assertion and the message body).
From what I have read, sender-vouches is more useful in a scenario as follows:
- Web Service A trusts Web Service B.
- Web Service B trusts Joe (either directly, or through federation).
- Web Service B wants to make a request to Web Service A on behalf of Joe.
B has the following options:
- Sign an assertion saying that the bearer is Joe, and send this assertion along with the message, effectively impersonating Joe
- This assertion must be used over a confidential link, or else an attacker could use it to authenticate another message.
- This assertion does not provide any non-repudiation (the relying party cannot say that it definitely received a request on Joe's behalf, because Web Service B could believably say, "that's not the message I attached this assertion to").
- Sign an assertion saying that the holder of key X is Joe, and then sign the message with key X, effectively creating a temporary key that will be used to impersonate Joe
- This assertion provides non-repudiation
- This practice places a huge burden on the Web Service B, which must generate a different key for each of its subjects (if it were to use the same key for two or more subjects, the relying party could mix and match the messages and the assertions - no one would be able to tell which combination of message and assertion was really sent)
- Create an assertion saying "sender-vouches that the subject is Joe", and send this along with the message. The whole message and assertion must be signed by the IDP (either using XML Sig or SSL with a client-cert). Basically, the IDP is saying "I am the IDP, and here is a message from Joe. You should trust it because I say so, and you trust me."
- If XML-Sig is used, this provides non-repudiation - if SSL is used, it does not.
- No extra key must be generated.
- Even if the assertion is leaked, it cannot be re-used because it is only trusted in the context of a message signed by the IDP or received over an SSL connection protected by the IDP's client certificate.
Posted by: erikwright on August 9, 2006 at 11:43 AM
-
I am trying to test the sample code but could not run it. Is there any help documentation on this sender-voucher project? What is the preconfigureation on the server / environment for this? How to test the client?
Greatly appreciate help / feedback in this regard.
Posted by: msarkerbea on October 22, 2007 at 4:56 PM
|
|
