1 2 3 Previous Next 32 Replies Latest reply on Jun 22, 2015 6:07 PM by jayzou01

    Help with picketlink and return url

    johnny.ha

      Hi all,

       

      I'm pretty new to picketlink and are testing with SSO with SAML 2.0.

       

      Has encountered a problem when trying to access a url like "http://localhost:8080/employee/test.html" then IDP may require you to login.

      Once you have logged in then you're going to "http://localhost:8080/employee/" and that's not what I want, I want the user after having logged in redirect to url that they were trying to reach before login.

       

      Read the thread https://community.jboss.org/message/730808 that you could use RelayState and it should be fixed in version PL 2.1.1.Final.

      But I can not find any documentation about RelayState, could I get help with this?

       

      Thanks in advance.

       

      Sincerely Johnny

        • 1. Re: Help with picketlink and return url
          anil.saldhana
          • 2. Re: Help with picketlink and return url
            johnny.ha

            Hi Anil,

             

            Thank you for your fast reply, I have tested the example and I can't get it working.

             

            Here is what my picketlink.xml for sp.

             

            Would be great if there was an example app like idp.war or employee.war where you could just deployed to the server

             

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

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

                    ServerEnvironment="jboss" BindingType="REDIRECT" RelayState="someURL">

                    <IdentityURL>${idp.url::http://localhost:8080/idp/}</IdentityURL>

                    <ServiceURL>${employee.url::http://localhost:8080/employee/}</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" />

                    <Handler class="org.picketlink.identity.federation.web.handlers.saml2.RolesGenerationHandler" />

                </Handlers>

            </PicketLink>

            • 3. Re: Help with picketlink and return url
              anil.saldhana

              the value someURL should be the url of the application where you need the redirect to.

              • 4. Re: Help with picketlink and return url
                hrrbrt99

                Hi Anil,

                I have the same problem as Johnny and I don't understand your reply?

                In general the 'someUrl' of the RelayState parameter would be variable depending on the requested page.

                How has this to be done?

                • 5. Re: Help with picketlink and return url
                  anil.saldhana

                  hrrbrt99 wrote:

                   

                  Hi Anil,

                  I have the same problem as Johnny and I don't understand your reply?

                  In general the 'someUrl' of the RelayState parameter would be variable depending on the requested page.

                  How has this to be done?

                  if you want the redirect to go to  "http://mysite/xyz"   put that value there. 

                  You will need to url encode the value though

                  Try: http://meyerweb.com/eric/tools/dencoder/

                  • 6. Re: Help with picketlink and return url
                    tim.kutz

                    Anil, I came here with the exact same question, and your answer still is opaque.  I think perhaps the question isn't being stated clearly.

                     

                    Suppose my SP application consists of 4 modules, each of which has a landing page, e.g. "http://mysite/module1/","http://mysite/module2/", etc.  Various users may wish to bookmark those modules.  User 1 goes to his bookmark, and sends the "http://mysite/module1/" URL, which forwards him to IDP, to login, and back to the application.  User 2, has bookmarked a different module, so he sends "http://mysite/module2/", and is forwarded to IDP, logs in, and is forwarded back to the application.

                     

                    If the RelayState value is set in picketlink.xml, then I can only set one value in it.  If I set it to "http://mysite/module1/", then User2 arrives at the wrong page, because he wanted to go to "http://mysite/module2/".  The reverse, however, is true, as well.  What is truly needed, here, is a way to pass the original URL requested of the SP over to the IDP, so that it will redirect to that value, not to a statically configured URL.

                    • 7. Re: Help with picketlink and return url
                      anil.saldhana

                      Tim Kutz wrote:

                       

                      Anil, I came here with the exact same question, and your answer still is opaque.  I think perhaps the question isn't being stated clearly.

                       

                      Suppose my SP application consists of 4 modules, each of which has a landing page, e.g. "http://mysite/module1/","http://mysite/module2/", etc.  Various users may wish to bookmark those modules.  User 1 goes to his bookmark, and sends the "http://mysite/module1/" URL, which forwards him to IDP, to login, and back to the application.  User 2, has bookmarked a different module, so he sends "http://mysite/module2/", and is forwarded to IDP, logs in, and is forwarded back to the application.

                       

                      If the RelayState value is set in picketlink.xml, then I can only set one value in it.  If I set it to "http://mysite/module1/", then User2 arrives at the wrong page, because he wanted to go to "http://mysite/module2/".  The reverse, however, is true, as well.  What is truly needed, here, is a way to pass the original URL requested of the SP over to the IDP, so that it will redirect to that value, not to a statically configured URL.

                      In your example, the module is equal to a separate SP. In that case, the forwarding works perfectly because the user bookmarks the right SP url. If we went by your example, there would be multiple SP applications.

                       

                      What you infact are asking is the use case where the SP has multiple landing pages and the user may bookmark any.  Ideally, on the response from the IDP, the SP should redirect to the page the user desired.

                      Examples would be:  http://mysite/employee/HRLanding.html   http://mysite/employee/FinanceLanding.jsp  http://mysite/employee/CarPoolLanding.jsp

                       

                      I think this is already handled by the SP. You do not need a redirect url for this. When the response comes back from the IDP, the SP would restore the saved original http request and send the user to that request.

                      • 8. Re: Help with picketlink and return url
                        tim.kutz

                        Anil Saldhana wrote:

                         

                        Tim Kutz wrote:

                         

                        Anil, I came here with the exact same question, and your answer still is opaque.  I think perhaps the question isn't being stated clearly.

                         

                        Suppose my SP application consists of 4 modules, each of which has a landing page, e.g. "http://mysite/module1/","http://mysite/module2/", etc.  Various users may wish to bookmark those modules.  User 1 goes to his bookmark, and sends the "http://mysite/module1/" URL, which forwards him to IDP, to login, and back to the application.  User 2, has bookmarked a different module, so he sends "http://mysite/module2/", and is forwarded to IDP, logs in, and is forwarded back to the application.

                         

                        If the RelayState value is set in picketlink.xml, then I can only set one value in it.  If I set it to "http://mysite/module1/", then User2 arrives at the wrong page, because he wanted to go to "http://mysite/module2/".  The reverse, however, is true, as well.  What is truly needed, here, is a way to pass the original URL requested of the SP over to the IDP, so that it will redirect to that value, not to a statically configured URL.

                        In your example, the module is equal to a separate SP. In that case, the forwarding works perfectly because the user bookmarks the right SP url. If we went by your example, there would be multiple SP applications.

                         

                        What you infact are asking is the use case where the SP has multiple landing pages and the user may bookmark any.  Ideally, on the response from the IDP, the SP should redirect to the page the user desired.

                        Examples would be:  http://mysite/employee/HRLanding.html   http://mysite/employee/FinanceLanding.jsp  http://mysite/employee/CarPoolLanding.jsp

                         

                        I think this is already handled by the SP. You do not need a redirect url for this. When the response comes back from the IDP, the SP would restore the saved original http request and send the user to that request.

                        I'm using PicketLink 2.1.5, and this is not happening.  When I got to my SP, with any page, and it sends me to the IDP to login, after login I am always returned to the ServiceURL as defined in my picketlink.xml under WEB-INF of the SP application.  As I understand it, the IDP should be returning control to the SP by using the AssertionConsumerServiceURL attribute of the original samlp:AuthnRequest.  However, it appears that the ServiceProviderAuthenticator does not capture the requested URL, and instead always populates the ServiceURL from picketlink.xml.  Are there any necessary settings, in Picketlink.xml, in web.xml or jboss-web.xml, etc, that might impact this?

                         

                        I think it's worth mentioning, that I cannot make this happen in the quickstart sample applications, either.  For the simplest version, simply go to http://mysite/employee/error.jsp, when you are not logged into the quickstarts.  As the employee war has all resources secured, you are forwarded to the IDP, and when you return, you land on the index.jsp page, and the browser address bar will read http://mysite/employee/.

                        • 9. Re: Help with picketlink and return url
                          tim.kutz

                          I've been going through the SAML login sequence with a debugger, and a non-Java (and therefore non-PicketLink) SP, alongside the PicketLink handlers.

                           

                          When using the non-Java implementation, we send a SAML AuthnRequest document into the server.  This document contains an attribute AssertionConsumerServiceURL, to which the PicketLink IDP correctly forwards it's SAML Assertion document once authentication has occurred.

                           

                          When using the PicketLink SP, this value is always set to the SP Issuer value, with is the SP's configured URL.  This happens in line 351-355 of SAML2AuthenticationHandler:

                           

                                      String assertionConsumerURL = (String) handlerConfig.getParameter(SAML2Handler.ASSERTION_CONSUMER_URL);

                                      if (StringUtil.isNullOrEmpty(assertionConsumerURL)) {

                                          assertionConsumerURL = issuerValue;

                                      }

                           

                          There does not appear to be any attempt made to determine the requested URL, here, which is what should be going into that value, in order to bring the user back to the originally requested page.  I think the information is there, in the HttpContext, but it's not being used.  Is this something we have to extend on our own? It seems like retaining the original request context is something that should be standard in the SP-side handlers.

                          • 10. Re: Help with picketlink and return url
                            moosetraveller

                            Hi Tim

                            Were you able to solve your issue? It's also an issue we are facing and did not come up with a solution yet.

                            Thank you for your hints.

                            Thomas

                            • 11. Re: Help with picketlink and return url
                              tim.kutz

                              I do, now, have a working, if rather hackish, solution, here.  It has definite limitations, and I'm working to solve at least some of those.

                               

                              I've extended the SAML2AuthenticationHandler class, and replaced the SPAuthenticationHandler's generateSAMLRequest() method with a modified version.  The change, so far, is to use the requested URL for the AssertionConsumerServiceURL:

                               

                                          // Use the requested URL first, before falling back to issuer or configured url.

                                          HTTPContext httpContext = (HTTPContext) request.getContext();

                                          String assertionConsumerURL = httpContext.getRequest().getRequestURL().toString();

                                          if (StringUtil.isNullOrEmpty(assertionConsumerURL)) {

                                                    assertionConsumerURL = (String) handlerConfig.getParameter(SAML2Handler.ASSERTION_CONSUMER_URL);

                                          }

                                          if (StringUtil.isNullOrEmpty(assertionConsumerURL)) {

                                              assertionConsumerURL = issuerValue;

                                          }

                               

                              This will fall back on the previous logic, if the requestURL cannot be read, for some reason, although I struggle to come up with a scenario where that could happen.  The main issue this faces, though, is that if the original request included query parameters or a submitted form, those are lost.  I did try including the query parameters on the AssertionConsumerURL above, but it appears to cause a parsing problem for the URL on the IDP side.  I'm trying to implement something a little more complex, to capture those values, and restore them on the return, but that will be somewhat more involved.

                               

                              Still, I can't help but feel like this is something that should already be here.  Anil, have you looked at this from your end, at all?  Your previous posts make it appear that you believed this to be working, already.  Are we missing something to enable it?

                              • 12. Re: Help with picketlink and return url
                                tim.kutz

                                Update: I am able to get query string values to pass over and come back.  Form posts remain a problem, however.

                                 

                                Anil, we would be happy to share this as a code contribution, just let me know how to submit it as a contribution.

                                • 13. Re: Help with picketlink and return url
                                  anil.saldhana

                                  Tim Kutz wrote:

                                   

                                  Update: I am able to get query string values to pass over and come back.  Form posts remain a problem, however.

                                   

                                  Anil, we would be happy to share this as a code contribution, just let me know how to submit it as a contribution.

                                  Tim, when we have time, we will take a look at the issues you mention. We are working on other things at the moment.

                                  Code contribution is as simple as git fork and sending a pull request.

                                  • 14. Re: Help with picketlink and return url
                                    hrrbrt99

                                    I can confirm that in the SAML2 request message from SP to IDP you find the AssertionConsumerServiceURL value you have put into picketlink.xml under <ServiceURL> ... </ServiceURL>

                                     

                                    e.g. picketlink.xml:

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

                                        <PicketLinkSP xmlns="urn:picketlink:identity-federation:config:2.1" ServerEnvironment="tomcat" BindingType="POST" SupportsSignatures="true">

                                            <IdentityURL>${idp.url::http://localhost:8080/portal/dologin}

                                            </IdentityURL>

                                            <ServiceURL>${owl.url::http://localhost:8080/owl2/test}</ServiceURL>

                                            <Trust>

                                                <Domains>

                                       ........

                                     

                                    produces SAML2 request:

                                     

                                    <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

                                                        xmlns="urn:oasis:names:tc:SAML:2.0:assertion"

                                      AssertionConsumerServiceURL="http://localhost:8080/owl2/test"

                                                        Destination="http://localhost:8080/portal/dologin"

                                                        ID="ID_6b110d90-ec2b-4d09-810a-166d026cfe18"

                                                        IssueInstant="2012-11-17T17:00:03.477Z"

                                                        ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

                                                        Version="2.0"

                                                        >

                                      ......

                                    1 2 3 Previous Next