7 Replies Latest reply on Jun 4, 2012 12:03 PM by Anil Saldanha

    Endless loop on SP with PingIdentity IDP

    Zoltan Csoka Newbie

      Hi,

       

      I am trying to set up a PicketLink SP with a PingIdentity IDP. I use the PicketLink 2.1.1 on Tomcat 6. I got the quickstart projects from the repo and I try to use the example of the POST-sig (POST binding with signature, but actually I want to only verify the IDP cert. To reduce the number of possible errors I disabled the cert validation and my config looks like:

       

      <PicketLink xmlns="urn:picketlink:identity-federation:config:2.1" EnableAudit="true">

          <PicketLinkSP xmlns="urn:picketlink:identity-federation:config:1.0"

              ServerEnvironment="tomcat" BindingType="POST" SupportsSignatures="no"> 

              <IdentityURL>https://int-idp-dev.anonymous.com:9031/idp/startSSO.ping?PartnerSpId=SalesTest</IdentityURL>

              <ServiceURL>http://iamsp.anonymous.com:8080/sales-post-sig/</ServiceURL>

          </PicketLinkSP>

          <Handlers xmlns="urn:picketlink:identity-federation:handler:config:2.1">

              <Handler

                  class="org.picketlink.identity.federation.web.handlers.saml2.SAML2LogOutHandler" />

              <Handler

                  class="org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler" />

          </Handlers>

      </PicketLink>

       

      I use the tomcat-users.xml for the user definition and for my user id I defined the "manager" role, since I do not get any roles from the IDP.

      The web.xml defines the

      <auth-constraint>

                  <role-name>manager</role-name>

      </auth-constraint>

      for the URI /*

       

      If I try to run an SP initiated login and I put into the browser the http://iamsp.anonymous.com:8080/sales-post-sig/,

      1. the SP redirects with the samlRequest to the IDP. The IDP authenticates via Kerberos and sends back the samlResponse

      2. the SP does something with the response and redirects to the application with a 302

      3. the response is a 200, but it contains an onload submit to the IDP with a samlRequest

       

      It goes to the IDP again and these steps are looping forever.

      I caught the samlResponse, decoded it and found that nameid is in the response under:

      <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos"> and it is the correct user name.

       

      and I also found that the Issuer has a discrepancy between the configured URL and the Issuer name (one is int-idp-dev.anonymous.com and the second one is : ext-idp-dev.anonymous.com)

      <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">ext-idp-dev.anonymous.com</saml:Issuer>

       

      According to the PingIdentity admin it should not make any problems.

       

      On top of that, the log files are quasi emtpy, the server.log has only 1 entry, so I have no chance the troubleshoot. (although log4j root level is set to DEBUG):

      main INFO  sp.BaseFormAuthenticator - BaseFormAuthenticator:: Setting the CanonicalizationMethod on XMLSignatureUtil::http://www.w3.org/2001/10/xml-exc-c14n#WithComments

       

      Questions:

      1.) Do you have any idea what my problem is?

      2.) Does PicketLink verifies the issuer against the IdentityURL?

      3.) Is it normal, that the DEBUG level is not printing anything? I would ecpect some log entries for the SAML ticket verification.

       

      Many thanks in advance for your help,

       

      Kind Regards,

       

      Zoltan

        • 1. Re: Endless loop on SP with PingIdentity IDP
          Pedro Igor Master

          Hi Zoltan,

           

              Did you try to isolate the problem using the PicketLink Identity Provider example (idp.war) ? If you follow the same steps using this example you get the same error ?

           

          Regards.

          Pedro

          • 2. Re: Endless loop on SP with PingIdentity IDP
            Zoltan Csoka Newbie

            Hi Pedro,

             

            No, I did not try that, since the issue seems to be between the PingIdentity IDP and the PicketLink SP, hence I did not think that changing to the PicketLink IDP could help me to tackle the problem.

             

            Kind Regards,

             

            Zoltan

            • 3. Re: Endless loop on SP with PingIdentity IDP
              Zoltan Csoka Newbie

              Could at least someone please tell me why nothing is logged? I have the log4.xml in the lib folder with:

               

              <?xml version="1.0" encoding="UTF-8"?>

              <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

              <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="true">

              <appender name="makeafile" class="org.apache.log4j.FileAppender">

                      <param name="File" value="../logs/server.log" />

                      <param name="Threshold" value="DEBUG" />

                      <param name="Append" value="true" />

                      <layout class="org.apache.log4j.PatternLayout">

                        <param name="ConversionPattern" value="%t %-5p %c{2} - %m%n"/>

                      </layout>          

                   </appender>

               

              <root>

                  <level value="DEBUG" />

                <appender-ref ref="makeafile"/>

              </root>

              </log4j:configuration>

               

               

              I would expect the filter to log something. It is not even logging on TRACE level. Could someone help me to get PicketLink logging, that I get a chance to fix it?

              • 4. Re: Endless loop on SP with PingIdentity IDP
                Zoltan Csoka Newbie

                If anyone is still reading these posts, I would like to give an update. The Issuer ID on the IDp side was corrected and it matches now the IDP URL, but still no change in the behavior.

                • 5. Re: Endless loop on SP with PingIdentity IDP
                  Zoltan Csoka Newbie

                  I made the logging work, DEBUG level is not enough, it has to be set to TRACE. But even then do not expect much, I got only (posts are replaced by ....):

                   

                  2012-05-23 07:35:34,221 TRACE util.PostBindingUtil - <HTML><HEAD><TITLE>HTTP Post Binding (Request)</TITLE></HEAD><BODY Onload="document.forms[0].submit()"><FORM METHOD="POST" ACTION="https://....</HTML>

                  2012-05-23 07:35:34,529 TRACE process.ServiceProviderBaseProcessor - Handlers are:[org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler@186c730, org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler@1d6a56e]

                  2012-05-23 07:35:34,529 TRACE process.ServiceProviderBaseProcessor - Handlers are : [org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler@186c730, org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler@1d6a56e]

                  2012-05-23 07:35:34,534 TRACE process.ServiceProviderBaseProcessor - Finished Processing handler:org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler

                  2012-05-23 07:35:34,534 TRACE process.ServiceProviderBaseProcessor - Finished Processing handler:org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler

                  2012-05-23 07:35:34,536 TRACE util.PostBindingUtil - <HTML><HEAD><TITLE>HTTP Post Binding (Request)</TITLE></HEAD><BODY Onload="document.forms[0].submit()"><FORM METHOD="POST" ACTION="https://...</HTML>

                  2012-05-23 07:35:34,844 TRACE process.ServiceProviderBaseProcessor - Handlers are:[org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler@186c730, org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler@1d6a56e]

                  2012-05-23 07:35:34,844 TRACE process.ServiceProviderBaseProcessor - Handlers are : [org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler@186c730, org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler@1d6a56e]

                  2012-05-23 07:35:34,846 TRACE process.ServiceProviderBaseProcessor - Finished Processing handler:org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler

                  2012-05-23 07:35:34,846 TRACE process.ServiceProviderBaseProcessor - Finished Processing handler:org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler

                  2012-05-23 07:35:34,848 TRACE util.PostBindingUtil - <HTML><HEAD><TITLE>HTTP Post Binding (Request)</TITLE></HEAD><BODY Onload="document.forms[0].submit()"><FORM METHOD="POST" ACTION="https://...</HTML>

                  2012-05-23 07:35:35,177 TRACE process.ServiceProviderBaseProcessor - Handlers are:[org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler@186c730, org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler@1d6a56e]

                  2012-05-23 07:35:35,177 TRACE process.ServiceProviderBaseProcessor - Handlers are : [org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler@186c730, org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler@1d6a56e]

                  2012-05-23 07:35:35,179 TRACE process.ServiceProviderBaseProcessor - Finished Processing handler:org.picketlink.identity.federation.web.handlers.saml2.SAML2AuthenticationHandler

                  2012-05-23 07:35:35,180 TRACE process.ServiceProviderBaseProcessor - Finished Processing handler:org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler

                  2012-05-23 07:35:35,181 TRACE util.PostBindingUtil - <HTML><HEAD><TITLE>HTTP Post Binding (Request)</TITLE></HEAD><BODY Onload="document.forms[0].submit()"><FORM METHOD="POST" ACTION="https:....</HTML>

                   

                  The TRACE level is not detailed enough to reveal what is happening in the SAML2AuthenticationHandler. Hence the last hope of making it work is gone.

                  • 6. Re: Endless loop on SP with PingIdentity IDP
                    Zoltan Csoka Newbie

                    Dear Interested parties,

                     

                    The issue was the typical trailing slash issue. The PingIdentity administrator configured the

                    <samlp:Response Destination

                    and Recipient in the Subject

                    without trailing slash, hence when the POST binding arrived, the request was redirected to the URL with trailing slash, but in the meantime the POST data was lost. Of course it forced the SP to get to the IDP again.

                    Since then it works fine, even signature verification is in place. I get into the Attributes handling, hopefully I will not face any problems there. I would appreciate a bit better documentation, but I am indeed thankful for teh developers for PicketLink.

                     

                    Have fun,

                     

                    Zoltan

                    • 7. Re: Endless loop on SP with PingIdentity IDP
                      Anil Saldanha Master

                      Zoltan Csoka wrote:

                       

                      Dear Interested parties,

                       

                      The issue was the typical trailing slash issue. The PingIdentity administrator configured the

                      <samlp:Response Destination

                      and Recipient in the Subject

                      without trailing slash, hence when the POST binding arrived, the request was redirected to the URL with trailing slash, but in the meantime the POST data was lost. Of course it forced the SP to get to the IDP again.

                      Since then it works fine, even signature verification is in place. I get into the Attributes handling, hopefully I will not face any problems there. I would appreciate a bit better documentation, but I am indeed thankful for teh developers for PicketLink.

                       

                      Have fun,

                       

                      Zoltan

                      An issue with tomcat wherein it does internal redirect if the tailing slash is not present.