3 Replies Latest reply on Mar 4, 2013 9:07 AM by John Ament

    Configuration support for PLFED-383

    John Ament Master

      I am reading through the release notes of PicketLink 2.1.6.



      I noticed that PLFED-383 was fixed in this release, being able to redirect to another page on the SP side after correctly authenticating to the IDP.  However, I can't seem to get this feature to activate.  I am only able to drive this URL based on the ServiceURL specified in my picketlink-idfed.xml in my SP's WAR. 

      How do I tell PicketLink to start using the originally requested URL in the IDP?

        • 1. Re: Configuration support for PLFED-383
          John Ament Master

          So I'm noticing now that my issue is a little more complicated.


          My application is an HTML5 web app using backbone, etc and JAX-RS APIs on the server side. This is true of both the IDP and the SP.  On the IDP side, the REST resource to do logins is not secured (since you're not logged in yet).  Everything is passing in that, and near the end of the call I'm doing


          this.request.login(username, password);


          Which is triggering my authentication handler.  What's not happening is forwarding to the SP correctly after login.  Do I need to allow it to do a full HTTP POST (rather than an AJAX call?)





          • 2. Re: Configuration support for PLFED-383
            John Ament Master

            One last update for the weekend.


            My URL format is http://localhost:8082/app/index.html#view-e2


            It looks like the # portion is not being passed back to the SP, I get everything through index.html.

            • 3. Re: Configuration support for PLFED-383
              John Ament Master

              So... after some thinking (and people reminding me on twitter) I realized that in its current state I cannot use picketlink to redirect to that URL.  the #whatever does not get sent to the server, only the client.  I ended up using a servlet filter to rewrite /app/e/2 to /app/index.html#view-e2 to work around this.  It means that we cannot redirect automatically to #view-e2 if they bookmark it and log out, probably only a minor inconvenience.


              In addition, another impediment I realized was that by using a REST API to do my login, I needed to better handle the redirects.  It turns out that the response from the IDP backend included a full HTML page that could be rendered to redirect.  What I'm doing now is reading the response from the IDP via javascript, rendering that HTML on the page dynamically using an append and then submitting that form.


              I think there's probably some needed client side integration w/ picketlink to be able to do this logging in from a javascript form and being able to dynamically load a page this way.  I may submit an enhancement, since right now with PLINK forcing a redirect on the client side to the IDP to authenticate a secured resource (instead of being able to render a page client side) it limits the dynamics of the application.