STS returning attributes (such as roles)

[anil.saldhana]

(09:26:10 AM) anil: sguilhen: what is the simplest way by which the STS can return user attributes
(09:26:21 AM) anil: sguilhen: with an additional AttributeProvider, maybe?
(09:27:26 AM) sguilhen: anil: you mean attributes to be included in the assertion?
(09:27:32 AM) anil: sguilhen: right
(09:27:40 AM) anil: sguilhen: such as roles
(09:29:21 AM) sguilhen: anil: there is the claims element... one needs to add a ClaimsProcessor that will parse the contents of the Claims section and return the required attributes in a Map. The SAML token provider iterates through this map and creates the attributes. Only downside is that the Claims contents are non-standard, so we need to create our own schema or find an existing one

[bmozaffa]

I noticed that some picketlink classes expect user roles as values to an attribute named "roles" but PicketLinkSTS does not return attributes.

1- It took me a few lines of code to get PicketLinkSTS to return the attribute values under JBoss. Is this something that is meant to be supported or done by PicketLinkSTS or am I taking the wrong approach?

2- At first glance, it appeared that SAML2STSLoginModule and/or SAML2LoginModule would extract the roles from the attribute and insert them as standard JAAS principals but this did not happen and upon closer inspection, I found that they require the SamlCredential to have been set in the JAAS options as the password and none of the login modules I know of do that. Any advice on this?

[anil.saldhana]

Stefan says:

1- The STS *does* return attributes if the original WS-Trust request
 contains a Claims section and the respective ClaimsProcessor has been implemented to 
parse the Claims and obtain the attributes. Now, we can change the SAML token provider 
to use something like an AttributeProvider. Such provider would be configured as one of 
the SAML20TokenProvider options and would be used to include attributes in the 
generated assertions, irrespective of whether a Claims section has been specified 
in the request or not. I think we should do this as the whole Claims thing is often 
a source for confusion and complexity.

 

<TokenProvider 
ProviderClass="org.picketlink.identity.federation.core.wstrust.plugins.saml.SAML20TokenProvider"
            TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"
            TokenElement="Assertion"
            TokenElementNS="urn:oasis:names:tc:SAML:2.0:assertion">
        <Property Key="AttributeProvider" Value="com.mycompany.MyAttProvider"/>
     </TokenProvider>

The class com.mycompany.MyAttProvider would be responsible for retrieving and returning the 
attributes that can applied to the assertion principal.

2- The SAML2STSLoginModule does extract the roles from the assertion in the getRoleSets methods 
and those roles will ultimately end in the JAAS subject. This module is meant to be used in 
scenarios in which a token has been obtained by the client and supplied to JBAS as part of an 
EJB invocation. In this case, once the invocation reaches the container, the assertion is extracted 
from the invocation and then set in the callback handler before the login process takes place.

Anil, I noticed something we need to fix: STSIssuingLoginModule and STSValidatingLoginModule 
can be used to issue and validate an assertion via JAAS. The problem with these modules is that 
they don't seem to extract roles from assertions and they share the issued assertion using a 
different key than the one used by SAML2STSLoginModule. We need to agree on a common key to be 
used by all modules to store security tokens - I think password is fine.

[anil.saldhana]

The STS is supposed to issue tokens alone. We can bring in the concepts of attributes to the STS as a value added feature. It has to be done via pluggable providers.