7 Replies Latest reply on Jun 4, 2012 12:03 PM by anil.saldhana

Endless loop on SP with PingIdentity IDP

zcsoka May 18, 2012 1:41 AM

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:

<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>

<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

pcraveiro May 18, 2012 12:08 PM (in response to zcsoka)

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
Actions
2. Re: Endless loop on SP with PingIdentity IDP

zcsoka May 21, 2012 1:08 AM (in response to pcraveiro)

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
Actions
3. Re: Endless loop on SP with PingIdentity IDP

zcsoka May 21, 2012 11:04 AM (in response to zcsoka)

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?
Actions
4. Re: Endless loop on SP with PingIdentity IDP

zcsoka May 22, 2012 10:42 AM (in response to zcsoka)

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.
Actions
5. Re: Endless loop on SP with PingIdentity IDP

zcsoka May 23, 2012 1:40 AM (in response to zcsoka)

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.
Actions
6. Re: Endless loop on SP with PingIdentity IDP

zcsoka May 24, 2012 10:28 AM (in response to zcsoka)

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
Actions
7. Re: Endless loop on SP with PingIdentity IDP

anil.saldhana Jun 4, 2012 12:03 PM (in response to zcsoka)

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.
Actions

Go to original post