Example is https://github.com/anilsaldhana/federation/blob/master/picketlink-core/src/test/resources/parser/config/picketlink-sp.xml

The relay state may need to be configured with url encoded string.

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

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?

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/

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.

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.

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

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.

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

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?

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

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"

                    >

  ......