Skip to main content

Accessing SAML tokens in STS

10 replies [Last post]
stepan_hrbacek
Offline
Joined: 2007-07-04
Points: 0

Using WSIT I am implementing an STS that should run under Tomcat 5.5. This STS should consume multiple SAML tokens contained in the WS-Security header and based on information contained in these tokens then issue new SAML token.

I have implemented the IssueSamlTokenContract interface and the problem I face now is how to access the SAML tokens received in the WS-Security header.

Could anybody please give me a hint?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
stepan_hrbacek
Offline
Joined: 2007-07-04
Points: 0

And yet another question - when more security tokens of different types (e.g. SAML, X.509, Username, ...) are contained in the WS-Security header, do I get them all in the Subject public/private credentials? Where could be found some info/specification concerning this? (JSR 196???)

Message was edited by: stepan_hrbacek

kumarjayanti
Offline
Joined: 2003-12-10
Points: 0

In general the Subject is Populated in a Container Specific Manner. When JSR 196 is supported by the container there is a portable way of making sure that the Subject is populated in a manner that the Container Understands.

Right now in WSIT the following would happen :

UsernameToken : The Container's representation of the Caller Principal is populated into the Subject Principal Set. (True only for GlassFish, for Tomcat/other-containers we simply add the username to the Principal set)

X509 Certificates : cert.getX500Principal() : added to Principal Set
cert : added to PublicCredentials set

(in this case the container representation is not being added even for GlassFish. This is a bug and will be fixed soon w.r.t GlassFish. With Tomcat/other-containers this behaviour will continue)

SAML Tokens : The SAML Token as an XMLStreamReader would be added to PublicCredential Set (if you are using WSIT with StreamingSecurity, which is the default). If you are using WSIT with (http://blogs.sun.com/venu/entry/improved_xwss_implementation_in_wsit) ) then you would see the SAML Assertion as a DOM Element in the PublicCredentials.

In general when there are multiple tokens in the message all of them should be added to the Client Subject created on the Server. Let us know if this is not happening.

We are in the process of improving this part of things soon.

Thanks.

stepan_hrbacek
Offline
Joined: 2007-07-04
Points: 0

Thank you very much for your helpful info!

jdg6688
Offline
Joined: 2005-11-02
Points: 0

The security header is processed in the scueity pipe and the saml token should populated in the requestor Subject.

From the IssuedTokenContext you may get the Subject by
calling context.getRequestorSubject(). Then you should be able to get the SAML
token by calling subject.getPublicCredentials() ...

stepan_hrbacek
Offline
Joined: 2007-07-04
Points: 0

> The security header is processed in the scueity pipe
> and the saml token should populated in the requestor
> Subject.
>
> From the IssuedTokenContext you may get the Subject
> by
> calling context.getRequestorSubject().

Thanks!

> Then you
> should be able to get the SAML
> token by calling subject.getPublicCredentials() ...

Just to make sure - when more SAML tokens are contained in the security header, are these all contained in the subject's public credentials?

shyam_rao
Offline
Joined: 2006-05-05
Points: 0

> Just to make sure - when more SAML tokens are
> contained in the security header, are these all
> contained in the subject's public credentials?

what is the usecase for adding more than one SAML token in the security header ?

stepan_hrbacek
Offline
Joined: 2007-07-04
Points: 0

> what is the usecase for adding more than one SAML token in the security header ?

Well the specification I have to implement requires this :-) Concretely, in the use case I am implementing the STS requires:
1) One SAML token (issued by an identity+attribute provider) that contains information on authenticated principal (mainly some attributes like roles) - it says: "I am principal X".
2) Another SAML token (issued by a different STS) that authorizes this principal's request to the STS - it says: "Principal X is authorized to get a token for operation Y at service provider Z".

The STS then issues a new SAML token for service provider Z - it says: "Principal X is authorized to access operation Y at service provider Z".

shyam_rao
Offline
Joined: 2006-05-05
Points: 0

> Well the specification I have to implement requires
> this :-) Concretely, in the use case I am
> implementing the STS requires:
> 1) One SAML token (issued by an identity+attribute
> provider) that contains information on authenticated
> principal (mainly some attributes like roles) - it
> says: "I am principal X".
> 2) Another SAML token (issued by a different STS)
> that authorizes this principal's request to the STS -
> it says: "Principal X is authorized to get a token
> for operation Y at service provider Z".
>
> The STS then issues a new SAML token for service
> provider Z - it says: "Principal X is authorized to
> access operation Y at service provider Z".

You can achieve this with SymmetricBinding with either two SignedSupportingTokens or one EndorsingSupportingToken and one SignedSupportingToken, depending on the SAML token contains a key or not. You can use the latest wsit nightly build.

stepan_hrbacek
Offline
Joined: 2007-07-04
Points: 0

> You can achieve this with SymmetricBinding with either two SignedSupportingTokens or one
> EndorsingSupportingToken and one SignedSupportingToken, depending on the SAML token
> contains a key or not. You can use the latest wsit nightly build.

Thank you!

As there's currently no support for defining these kind of WS-Security-Policy requirements via Netbeans, I guess that I will have to put these requirements into STS's WSDL manually. Am I right?

shyam_rao
Offline
Joined: 2006-05-05
Points: 0

> As there's currently no support for defining these
> kind of WS-Security-Policy requirements via Netbeans,
> I guess that I will have to put these requirements
> into STS's WSDL manually. Am I right?

You are right.