External authentication on a different system than the IdP

[Brian Reindel]

I guess I'm thinking of it this way:

1.) User hits SP protected endpoint.
2.) Redirect to IdP.
3.) External auth handler takes over.
4.) Redirect to external authentication system.
5.) External authentication.
6.) Redirect back to IdP with success/failure.
7.) Redirect to original SP protected endpoint if success.

For #4 and #6 I'm assuming the Shibboleth session ID would need to be
passed back and forth, and then some sort of pass through success
header would be passed back in step number #6.

If this flow is not typical (or not secure in some way), and the
communication with the authentication mechanism should happen behind
the scenes while the user is still on the IdP, then I understand that,
and will move in that direction.


On Wed, Jul 24, 2013 at 11:05 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 7/24/13 10:59 AM, "Brian Reindel" <brian at reindel.com> wrote:
>
>>Is it possible to have the external authentication live outside the
>>context of the IdP? I noticed the externalAuthnPath is context
>>relative. Basically we have a login page already configured for our
>>external authentication system, but it it isn't on the same server as
>>the identity provider. Will this not work given how external
>>authentication is configured, or am I misunderstanding the
>>capabilities?
>
> Using the external handler means you are responsible for implementing a
> SSO protocol that is secure between the servlet path configured into the
> handler and anything else it uses. If you want it to go somewhere else,
> that's up to you, but there has to be a piece of code running locally or
> there would be no way to implement a secure protocol.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net