login within a login

[Cantor, Scott]

On 3/2/17, 5:41 PM, "users on behalf of Jim Fox" <users-bounces at shibboleth.net on behalf of fox at washington.edu> wrote:

> This login within a login works.  Can I count on it in the future?

Yes, though I suspect I might not realize we broke it until we broke it. I'll open an issue to get Tom to look at creating an integration test to try and simulate this. If we could get that to work I'd be more confident we don't screw something up.

> 7) That succeeds, as the authn part of the original login has completed.

That's the first key step. Authentication would need to continue to complete the job of creating the IdPSession object and storing it off, which is not going to change in any 3.x release certainly. And I have no reason to think I'd change it for 4.0, it's been working fine.

The caveat is if you wait long enough to resume the original flow execution in step 9, the servlet session could time out and lose track of it. That's true any time you leave in the middle and come back.

> 9) Maintenance site redirects user back to IdP (url gleaned from step 5 query params).

And that's fine, the flow state is entirely captured in that URL. I abstracted that in the External authn flows, but that's all its doing.

>  And I added a "_eventId_proceed=1" to the redirect url (step 9).  Is that too much of using an undocumented api?

It's fine. If you want your interceptor flow to cause the original request to contine, the flow needs to signal "proceed" back to the parent flow, and that means it needs to end itself with that event/state. That's normally what any interceptor containing a view would do as a final step. The _eventId_event parameter syntax is part of webflow, it's the documented way to advance the flow.

-- Scott