13.4. Building custom STS

It is described in section 11.8 (To Create a Third-Party STS) how to build a WS-Trust Security Token Service (STS). Thus created STS can be configured to authenticate the client with username/passwords, X.509 certificates, etc. and to issue either SAML 1.0 or SAML 2.0 assertions. By default the issued SAML tokens will contain an SAML AttributeStatement with the user authenticated identity to the STS and a dummy attribute.

In practice, users may have different identities when using different web services. For authorization or privacy purposes, different user identity and/or user attributes (e.g. role or authorization code) are required to be included in the issued SAML assertion for a service.

WSIT provides an interface com.sun.xml.ws.api.security.trust.STSAttributeProvider for use in plugging user identity/attribute mappings into an STS. The implementation class of the STSAttributeProvider is exposed to the system with the standard ServiceFinder mechanism, i.e. using a file META-INF/services/com.sun.xml.ws.api.security.trust.STSAttributeProvider in the classpath. The file contains the names of STSAttributeProvider implementation classes, one per line. The mapped user identity/attributes will be picked up when creating SAML assertions.

Here are the steps for creating a custom STSAttributeProvider and plugging it into an STS created from NetBeans:

  1. Use NetBeans to To Create a Third-Party STS.
  2. Create an MySTSAttributeProvider implementation class in the same package as the STS implementation class which extends the BaseSTSImpl.
  3. Create a directory META-INF/services in the src/java directory.
  4. Create a file with name com.sun.xml.ws.api.security.trust.STSAttributeProvider with content the path to the class MySTSAttributeProvider (e.g. org.me.sts.MySTSAttributeProvider). Then place this file in the src/java/META-INF/services directory.
  5. Run the NetBeans STS project. Your STS will now use your custom attribute provider in creating the SAML assertions.

As a reference, here is a sample STSAttributeProvider.

13.4.1. Handling Claims with Metro STS

In WS-SecurityPolicy, an IssuedToken policy assertion may carry an optional wst:Claims element, to specify the actual claims required to access the service. Here is an example of IssuedToken policy assertions with Claims:


                            <sp:IssuedToken sp:IncludeToken="...">
                                <Issuer xmlns="...">
                                    <Address xmlns="http://www.w3.org/2005/08/addressing">...</Address>
                                </Issuer>
                                <sp:RequestSecurityTokenTemplate
                                        xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">
                                    <t:TokenType>urn:oasis:names:tc:SAML:2.0:assertion</t:TokenType>
                                    <t:KeyType>http://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey</t:KeyType>
                                    <t:KeySize>256</t:KeySize>
                                    <t:Claims Dialect="http://schemas.xmlsoap.org/ws/2005/05/identity"
                                              xmlns:ic="http://schemas.xmlsoap.org/ws/2005/05/identity">
                                          <ic:ClaimType Uri="http://.../ws/2005/05/identity/claims/givenname"/>
                                          <ic:ClaimType Uri="http://.../ws/2005/05/identity/claims/surname" Optional="true" />
                                    </wst:Claims>
                                </sp:RequestSecurityTokenTemplate>
                            </sp:IssuedToken>
                      

With Oasis standard versions of WS-SecurityPolicy 1.2 and WS-Trust 1.3, syntax is different for Claims, where it is defined as a top level sub-element of IssuedToken, in stead of a sub-element of RequestSecurityTokenTemplate:


                            <sp:IssuedToken sp:IncludeToken="...">
                                <Issuer xmlns="...">
                                    <Address xmlns="http://www.w3.org/2005/08/addressing">...</Address>
                                </Issuer>
                                <t:Claims Dialect="http://schemas.xmlsoap.org/ws/2005/05/identity"
                                              xmlns:ic="http://schemas.xmlsoap.org/ws/2005/05/identity">
                                          <ic:ClaimType Uri="http://.../ws/2005/05/identity/claims/givenname"/>
                                          <ic:ClaimType Uri="http://.../ws/2005/05/identity/claims/surname" Optional="true" />
                                </wst:Claims>
                                <sp:RequestSecurityTokenTemplate
                                        xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">
                                    <t:TokenType>urn:oasis:names:tc:SAML:2.0:assertion</t:TokenType>
                                    <t:KeyType>http://schemas.xmlsoap.org/ws/2005/02/trust/SymmetricKey</t:KeyType>
                                    <t:KeySize>256</t:KeySize>
                                </sp:RequestSecurityTokenTemplate>
                            </sp:IssuedToken>
                         

On the client side, the Claims, together with all the elements in the RequestSecurityTokenTemplate, is copied into the request message RST to the STS.

With Metro based STS, the Claims will then be available in the STSAttributeProvider, for use to build the user attributes to be included in the issued SAML assertion.

In your implementation of the method, getClaimedAttributes(Subject subject, String appliesTo, String tokenType, Claims claims), one may parse the Claims to obtain the ClaimTypes with the following codes:


                            String dialect = cliams.getDialect();
                            List<Object> claimTypes = claims.getAny();
                            for (Object claimType : claimsTypes){
                                Element ctElement = (Element) claimType;
                                // parsing ctElement according to the dialect to get claim types
                                    ...
                            }

                       

Once you parse the Claims, you may create the attributes accordingly. The attributes returned from the STSAttributeProvider is available in the STSTokenProvider through:


                        (Map<QName, List<String>>) ctx.getOtherProperties().get(IssuedTokenContext.CLAIMED_ATTRUBUTES);
                      
for you to build into your issued SAML assertions.

See also Handling Token and Key Requirements at Run Time for how to inject Claims on the client side at run time.


Terms of Use; Privacy Policy; Copyright ©2013-2014 (revision 20140418.2d69abc)
 
 
Close
loading
Please Confirm
Close