3 Replies Latest reply on Jun 2, 2010 7:10 PM by anil.saldhana

    STS returning attributes (such as roles)


      (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

        • 1. Re: STS returning attributes (such as roles)

          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?

          • 2. Re: STS returning attributes (such as roles)

            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.

                    <Property Key="AttributeProvider" Value="com.mycompany.MyAttProvider"/>
            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.
            • 3. Re: STS returning attributes (such as roles)

              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.