AW: AW: IdPV3 login page access to AuthnRequest

[Roehrl Patrick]

Thanks all for your replies!

> Why not just use RelayState with the requested URL as value?
Perhaps it would be an option, but the redirect to the password update site was done in the login.jsp, so I think the IdP won't add the RelayState to the redirection URL in this case.

> Why not just interrupt the login process and then redirect back to the IdP to pick up the web flow where it left off? All you need to do that is readily available, the flowExcutionUrl.
Oh I didn't thought about using the web flow....
In the old process there were two login handler involved in the password update process:
1. UserNamePassword login handler --> PasswordUpdateRequired error
2. Redirect to password update application and update password
3. Generate a login token and redirect to IdP with another AuthnContextClassRef to trigger the other login handler that processes the login token and logs the user in (then the user doesn't have to retype the new password)

So would it be possible to interrupt the web flow and continue with another "login handler" (I know that in V3 there aren't login handler anymore and that it was replaced by the flows)?

>Maybe something like this, although it uses getInBoundMessageContext() :

Yeah this works perfectly thanks! No I can try if we can reuse our old (and working) password update process!

> Not every request contains the URL, so that won't work reliably.
This shouldn't be a problem for us, because all SPs are hosted by us and configured to contain the URL.

Thanks guys for your help!


-----Ursprüngliche Nachricht-----
Von: users [mailto:users-bounces at shibboleth.net] Im Auftrag von Cantor, Scott
Gesendet: Dienstag, 28. Juli 2015 17:27
An: Shib Users
Betreff: Re: AW: IdPV3 login page access to AuthnRequest

On 7/28/15, 10:34 AM, "users on behalf of Tom Zeller" <users-bounces at shibboleth.net on behalf of tzeller at dragonacea.biz> wrote:

>On Tue, Jul 28, 2015 at 8:32 AM, Cantor, Scott <cantor.2 at osu.edu> 
>wrote:
>
>I don't think what you're doing makes a lot of sense, but be that as it 
>may, the ACS endpoint information can be found in a complex context 
>tree located under profileRequestContext.getOutboundMessageContext()
>
>I don't have the complete tree handy to my mind, and it's not documented at this point.
>
>Maybe something like this, although it uses getInBoundMessageContext() :

Not every request contains the URL, so that won't work reliably.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net