8 Replies Latest reply: Oct 11, 2011 5:07 AM by Anil Saldhana RSS

PicketLink 2.0 not processing response with requested NameIDPolicy

Ryan Fernandes Newbie

IDP: ADFS 2.0

PicketLink : 2.0

 

PicketLink 2.0 seems to issue a SAML Request with a NameIDPolicy tag

 

<samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>

 

This causes the IDP to correctly issue a SAML Response containing

 

<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">MyeHAMeGLojBt7fcc2DQtntXXFka0kybkR42ZTitTUs=</NameID>

 

 

However, post this PicketLink doesn't seem to do anything post receiving this response.

It doesn't redirect to the protected content and there are no errors in the log.

Turning the logging for org.picketlink to TRACE yeilds:

 

[ServiceProviderBaseProcessor] Handlers are:[org.picketlink.identity.federation.web.handlers.saml2.SAML2LogOutHandler..

[ServiceProviderBaseProcessor] Handlers are : [org.picketlink.identity.federation.web.handlers.saml2.SAML2LogOutHandl..

[ServiceProviderBaseProcessor] Finished Processing handler:org.picketlink.identity.federation.web.handlers.saml2.SAML..

[ServiceProviderBaseProcessor] Finished Processing handler:org.picketlink.identity.federation.web.handlers.saml2.SAML..

[SPRedirectFormAuthenticator] SAML Document=<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xm..

[SPRedirectFormAuthenticator] URL used for sending:https://mymachine.mydomain.com/adfs/ls/?SAMLRequest=lZLdT...

 

If I intercept the SAMLResponse and change the NameID tag contents to:

 

<NameID>myuser</NameID>

 

..picketlink works! (however defeating the NameIDPolicy)

 

The logs for org.picketlink at TRACE now yeild:

 

[ServiceProviderBaseProcessor] Handlers are:[org.picketlink.identity.federation.we..

[ServiceProviderBaseProcessor] Handlers are : [org.picketlink.identity.federation...

[ServiceProviderBaseProcessor] Finished Processing handler:org.picketlink.identity...

[ServiceProviderBaseProcessor] Finished Processing handler:org.picketlink.identity...

[SPRedirectFormAuthenticator] SAML Document=<samlp:AuthnRequest xmlns:samlp="urn:o...

[SPRedirectFormAuthenticator] URL used for sending:https://mymachine.mydom.....

[SAML2Response] RESPONSE=<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:

[TransformerUtil] Set Attribute Namespace=http://www.w3.org/2000/xmlns/::Qual=:xml

[TransformerUtil] Creating an Attribute Namespace=:Algorithm

[TransformerUtil] Creating an Attribute Namespace=:Algorithm

[TransformerUtil] Creating an Attribute Namespace=:URI

[TransformerUtil] Creating an Attribute Namespace=:Algorithm

[TransformerUtil] Creating an Attribute Namespace=:Algorithm

[TransformerUtil] Creating an Attribute Namespace=:Algorithm

[TransformerUtil] Set Attribute Namespace=http://www.w3.org/2000/xmlns/::Qual=:Key

[AssertionUtil] Now=2011-09-16T10:52:24.634+05:30 ::notBefore=2011-09-16T05:19:21.

[SAML2LoginModule] initialize

[SAML2LoginModule] Security domain: sp

[SAML2LoginModule] login

 

[SAML2LoginModule] User 'myuser

 

' authenticated, loginOk=true

 

[SAML2LoginModule] commit, loginOk=true

 

 

So the questions are:

1. Does PicketLink 2.0 support and process NameIDPolicy?

2. Can I configure PicketLink 2.0 to NOT send the NameIDPolicy?

3. Does NameIDPolicy have any bearing on the Logout behaviour of PicketLink?

4. PicketLink 1.0 does not send NameIDPolicy in the request. Can PicketLink 1.0 participate in Global / Local SSO Logout?

 

Please let me know if you need further information

  • 1. Re: PicketLink 2.0 not processing response with requested NameIDPolicy
    Ryan Fernandes Newbie

    An observation:

     

    When a NameIDPolicy is specified in the the SAML request, ADFS 2.0 encrypts the NameID (as seen in the post above)

    <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">MyeHAMeGLojBt7fcc2DQtntXXFka0kybkR42ZTitTUs=</NameID>

     

    Now, if we just run the example with idp.war playing the role of the IDP and intercept the messages, we find that the IDP.war returns something like

    <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">tomcat</NameID>

     

    Does this mean that PicketLink can't play with ADFS 2.0 or is there some setting (in PicketLink or ADFS 2.0) to fix this?

  • 2. Re: PicketLink 2.0 not processing response with requested NameIDPolicy
    Anil Saldhana Master

    If the service provider is running on JBoss AS, then you need to

    • either get the IDP to send the roles or
    • stack login modules at the SP end to generate the roles for the identity

     

     

    We do not explictly process the nameid.  Is there a setting in ADFS2 to not encrypt the nameid?

  • 3. Re: PicketLink 2.0 not processing response with requested NameIDPolicy
    Ryan Fernandes Newbie

    Yes we are using JBoss AS 5.1. The ADFS2 does send us the roles in the SAMLResponse, so thats not the issue. 

     

    I've managed to send an unencrypted NameID (by using a UPN and writing a tranformation rule to convert UPN to NameID with a persistent Format).

     

    However, on recieving this response, Picketlist still doesn't do anything but throws up a blank page.

     

    The SAMLResponse is :

     

    SAML RESPONSE

     

    <samlp:Response ID="_4a06c7f1-9c61-4023-9afd-64107304746b" Version="2.0" IssueInstant="2011-09-21T04:53:42.475Z" Destination="https://mySP.com:8443/employee/" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="ID_d7ac00b5-98c8-4532-8f16-f02bab3b824a" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">

    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://myIDP.com/adfs/services/trust</Issuer>

    <samlp:Status>

      <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />

    </samlp:Status>

    <Assertion ID="_0f89fff4-3fae-43ab-a4d7-fd94f668edf8" IssueInstant="2011-09-21T04:53:42.474Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">

      <Issuer>http://myIDP.com/adfs/services/trust</Issuer>

      <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

       <ds:SignedInfo>

        <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />

        <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />

        <ds:Reference URI="#_0f89fff4-3fae-43ab-a4d7-fd94f668edf8">

         <ds:Transforms>

          <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />

          <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />

         </ds:Transforms>

         <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />

         <ds:DigestValue>qhEnaARuxhahgyOI2HZOcnUxyIU=</ds:DigestValue>

        </ds:Reference>

       </ds:SignedInfo>

       <ds:SignatureValue>pN+Xv7XoZZ4qYJTVKTsTC4NBwn/qMWwF6UL9wKa312QcKYxomMKQEy0rl01PvhpJ78J5ivG9OItVPjJVEHX902cDjLPL9H+NfwbujU9fsuE+4kAhebdv6ZtNkJ0e1LiyRjUtoRtsVP9u5492yOMPBbyQNTqjnhXIddYc4UvcUG9pOlEOiNVpIlSiMIl9CPLfRlxe8ImvpeKr82Tc4a3bk83I57uOyNeMPsb/n6dvqn0WibwSHhumHwuRMBJKK6v4DUUNC2BApcCbg9mbuC0UnS0DQ8UpzqjP8zxWekDBR73KxmoZ59ESTuiTaRgZ6jb3XIcEEKlSg7eulExQHJYQHA==</ds:SignatureValue>

       <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">

        <ds:X509Data>

         <ds:X509Certificate>MIIC+jCCAeKgAwIBAgIQaKF8JNI9WKNAopamfuIDMjANBgkqhkiG9w0BAQsFADA5MTcwNQYDVQQDEy5BREZTIFNpZ25pbmcgLSBpbmQtc3B6N3YxMnc4MDQubWFzZm9yZXN0ZXIuY29tMB4XDTExMDgxMDExMTUyMVoXDTEyMDgwOTExMTUyMVowOTE3MDUGA1UEAxMuQURGUyBTaWduaW5nIC0gaW5kLXNwejd2MTJ3ODA0Lm1hc2ZvcmVzdGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALrGLuxioRiJ1FNQt8QaDHzDavCRQ9UFHxo+gWQu5JdGRw8hlCY/x1B5+rvM/d1jWgq7jOxCAh0snfb2j249X39QcmK7emauyzbz4zWizF2VgorVfjuZicvLmpS/FUjMsSzeT0J6dLuunaSNedcCYDH48m7mGDd+NfivLZBwPTnECFdg33M1gh7oBevFAZu10o7A3vAPJBdb4Ts6fE0+Qr44cNRtH8nQ7kIcpOjz6vMSm92soOPtJrDk9WkyA27PgG2QGSpJ0Caw3iTb+WvvWgWr0An+1kIFNpAM2ehViaa6nWD+lCOf9SQRndj8gnStIP46ahtcgXqKf8piVTQCJJ8CAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAjqsduBmEy/Vy2MW0crc9lxI+vnXFoI0KpgDeMOSaFquUnZ+zVn19YytAuzZDgtEHf/uoW7kHodJj0gY+yVP8D4pp/osDev4PFggihkmA2rMO9mAqyeDn9LecePpobKVGK4klad0C/qJ4WKEf2WvBS1wiwXp+dG5JFL4Zhgy+DpUXLuws9KeLxayhvN4TZ8VRuvJmJYJLkgPR7irc3G5ZgUrvKnjkEweMtxDoyGFZj+3s5goBiG5dGXOSqVEfD60CCbvR/Y0KZc7LvfiRC0lf4G9UcF2VoGGqz1stIF6sGrGm/16josC+LD9j04atZesCv7mAYYWQLFIyvSoeZjofbQ==</ds:X509Certificate>

        </ds:X509Data>

       </KeyInfo>

      </ds:Signature>

      <Subject>

       <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">myuser</NameID>

       <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">

        <SubjectConfirmationData InResponseTo="ID_d7ac00b5-98c8-4532-8f16-f02bab3b824a" NotOnOrAfter="2011-09-21T04:58:42.475Z" Recipient="https://mySP.com:8443/employee/" />

       </SubjectConfirmation>

      </Subject>

      <Conditions NotBefore="2011-09-21T04:53:42.470Z" NotOnOrAfter="2011-09-21T05:53:42.470Z">

       <AudienceRestriction>

        <Audience>https://mySP.com:8443/employee/</Audience>

       </AudienceRestriction>

      </Conditions>

      <AttributeStatement>

       <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn">

        <AttributeValue>myUser</AttributeValue>

       </Attribute>

       <Attribute Name="http://schemas.microsoft.com/ws/2008/06/identity/claims/role">

        <AttributeValue>Domain Users</AttributeValue>

        <AttributeValue>Domain Admins</AttributeValue>

        <AttributeValue>Admins</AttributeValue>

        <AttributeValue>Enterprise Admins</AttributeValue>

       </Attribute>

      </AttributeStatement>

      <AuthnStatement AuthnInstant="2011-09-21T04:53:42.432Z" SessionIndex="_0f89fff4-3fae-43ab-a4d7-fd94f668edf8">

       <AuthnContext>

        <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>

       </AuthnContext>

      </AuthnStatement>

    </Assertion>

    </samlp:Response>

     

     

    The (trace) output from JBoss AS is:

     

    Jboss Console (on trace)

    [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221053)] Started in 1m:1s:809ms

    [ServiceProviderBaseProcessor] Handlers are:[org.picketlink.identity.federation.web.handlers.saml2.SAML2LogOutHandler@18f7a385, org.picketlink.identity.fe

    [ServiceProviderBaseProcessor] Handlers are : [org.picketlink.identity.federation.web.handlers.saml2.SAML2LogOutHandler@18f7a385, org.picketlink.identity.

    [ServiceProviderBaseProcessor] Finished Processing handler:org.picketlink.identity.federation.web.handlers.saml2.SAML2LogOutHandler

    [ServiceProviderBaseProcessor] Finished Processing handler:org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler

    [SPRedirectFormAuthenticator] SAML Document=<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns="urn:oasis:names:tc:SAML:2.0:asse

    [SPRedirectFormAuthenticator] URL used for sending:https://myIDP.com/adfs/ls/?SAMLRequest=lZLdSsNAEIVfJeytJNn8kWZoArFFLFQtbfRWtunUBp

     

     

    Any help on this will be appreciated.

     

    Also, please let me know if you need any further information.

  • 4. Re: PicketLink 2.0 not processing response with requested NameIDPolicy
    Anil Saldhana Master

    Check  https://docs.jboss.org/author/display/PLINK/SAML2AuthenticationHandler   for the ROLE_KEYS  attribute on the handler. 

     

    Why this is needed?

    PicketLink does not know what the attributes representing roles are called from the IDP.

  • 5. Re: PicketLink 2.0 not processing response with requested NameIDPolicy
    Ryan Fernandes Newbie

    Thanks for pointing me in this direction.

     

    (Did I mention earlier that version 1.0.4 worked flawlessly for authentication?)

     

    Anyway, I read through PLFED-140 and its accompanying thread.

    I've also looked at the source code for the SAML2AuthenticationHandler (both 2.0 and 1.0.4).

     

    From what I can see, the ROLE_KEYS allow one to 'filter' out the roles of interest (from attributeStatement.getAttributes()).

    i.e. If  ROLE_KEYS is not defined, all attributes seem to be taken as roles (and this is why the employee.war/sales.war work without a ROLE_KEYS definition, I guess)

     

    Besides, if the rolesList is empty or contains roles that aren't in your SP's web.xml I would receive a 403 forbidden message (?)

     

    Maybe the issue is elsewhere?

  • 6. Re: PicketLink 2.0 not processing response with requested NameIDPolicy
    Anil Saldhana Master

    I will have to add a testcase with the saml response you have and see what the SPRedirectFormAuthenticator behavior is. Give me some time.

  • 7. Re: PicketLink 2.0 not processing response with requested NameIDPolicy
    Ryan Fernandes Newbie

    Thanks Anil.

    Please let me know if there is any other information you need.

  • 8. Re: PicketLink 2.0 not processing response with requested NameIDPolicy
    Anil Saldhana Master

    Sorry Ryan. I have been traveling the last few days and could not get to this.