TESB Client and Endpoint

This section focuses on requirements for TESB clients and endpoints. It does not describe any of the requirements of the PDP and policy repository infrastructure, beyond describing the XACML interface of the PDP. The following image describes the architecture of the authorization solution as a whole.

The scenario of interest in this section is that of a TESB client invoking a TESB service. In the case of a JAX-WS service endpoint, the WSDL of the service will contain an IssuedToken policy. The RequestSecurityTokenTemplate policy of the IssuedToken policy will require a SAML (1.1 or 2.0) token with a specific Claim corresponding to the role of the client. For example, the following policy requires a SAML 2.0 Token, with an embedded PublicKey and an Attribute containing a role:

<sp:RequestSecurityTokenTemplate>
   <t:TokenType>http://.../oasis-wss-saml-token-profile-1.1#SAMLV2.0
   </t:TokenType>
   <t:KeyType>
      http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey
   </t:KeyType>
   <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://schemas.xmlsoap.org/ws/2005/05/identity/claims/role"/>
   </t:Claims>
</sp:RequestSecurityTokenTemplate>

The TESB service provider will throw an Exception if the received SAML Token does not contain the corresponding Claim (e.g. role). Note that this means that it is not a requirement for the TESB service provider to obtain the roles of the authenticated principal itself, although this could be added at a later stage.

The TESB client parses the WSDL of the service provider, and creates a RequestSecurityToken element to send to the STS after parsing the IssuedToken policy. The Claim is passed to the STS as part of this Element, which essentially means that the client is requesting that the STS insert the specified Claim into the issued (SAML) token.

The STS must authenticate the client's credentials and obtain the roles of the client to insert into the SAML Token to fulfill the claims that the client has requested. For the case that the client has sent a WS-Security username and password over (one-way) TLS, then the STS endpoint must be instantiated with a custom WSS4J Validator that will validate the given credentials. For example, a JAAS Validator can be used if the IDM backend is an LDAP store like Apache DS. Alternatively, a Validator can be created to invoke on the REST APIs of a product like Apache Syncope.

The SAML Token is then returned to the client, which includes it in the security header of the service request. CXF will automatically extract the principal and roles from the SAML Token, and populate a CXF SAMLSecurityContext object. This latter object was added as part of CXF 2.7.0 and is shared between the JAX-WS and JAX-RS runtimes. This means that the XACML interceptors work independently of how the SAML Token was actually received. A CXF interceptor will then create an XACML request from the SecurityContext and dispatch it to a PDP for authorization. The interceptor must then enforce the returned authorization decision, by throwing an exception if access is denied.

A JAX-RS service endpoint does not have a way of advertising what Claims etc. are required as for JAX-WS. In this case, the JAX-RS client must be aware of what the JAX-RS service provider is expecting (e.g. SAML 1.1 or 2.0 etc.) and use these values when obtaining a SAML Token from the STS. An interceptor is provided which wraps CXF's STSClient to obtain a SAML Token from the STS. It thens use any of the standard CXF JAX-RS SAML capabilities (e.g. message pay-load, authorization header, etc.) to insert the SAML Token into the request. The JAX-RS (service) must be instantiated with a CXF JAX-RS provider which will handle the parsing of the SAML Token, and populate the CXF SAMLSecurityContext.

The scenario described above will be broken down into its various tasks in the following sections.