Multi-factor authentication with two IdPs
Dan Ciarniello
DCiarniello at central1.com
Fri Aug 28 14:22:54 EDT 2015
> -----Original Message-----
> From: Cantor, Scott [mailto:cantor.2 at osu.edu]
> Sent: Thursday, August 27, 2015 1:58 PM
> To: Shib Users
> Subject: Re: Multi-factor authentication with two IdPs
>
> On 8/27/15, 4:29 PM, "users on behalf of Dan Ciarniello" <users-
> bounces at shibboleth.net on behalf of DCiarniello at central1.com> wrote:
>
> >The current setup is, I believe, fairly standard with a service provider behind
> a reverse proxy (an F5) with an ADFS system providing SSO services.
> >
> >
> >As I understand it, the basic workflow is:
> >
> >1. F5 redirects user to ADFS for login
> >2. ADFS returns SAML response to the F5 with various “claims” including a
> user id
> >3. F5 then forwards the SAML response to the service provider
>
> Unless the F5 is the SP itself, I'm not sure it's relevant to the conversation.
In this case the F5 does act as an SP but I don't have the ability to do any customization there that would help solve my problem.
> Regardless...
>
> >
> >What I would like to do is insert a step after step 2 whereby after initial
> login, the F5 forwards the SAML Response to Shibboleth for further
> authentication using a custom extension.
> >The custom extension requires the user id from the initial login to perform
> the second authentication step.
>
> That's not just a simple custom extension, that's an *SP*. Shibboleth IdPs
> don't include an SP or support for natively proxying SAML authentication. You
> would have to install a SAML SP as an authentication mechanism for the IdP
> to site behind along with adding additional custom code to the attribute
> resolver to do all that.
I had a feeling that the answer would be something along those lines but wanted to see if there were any alternatives.
>
> Most other major IdP implementations include that sort of thing natively.
>
> >
> >I’m wondering if this is possible?
>
> Not easily.
>
> -- Scott
Thanks,
Dan.
This email and any attachments are strictly confidential, may be privileged, and are intended only for the use of the person(s) named above. Any other person is strictly prohibited from disclosing, distributing, copying or using it. If you are not the intended recipient (or are not receiving this communication on behalf of the intended recipient), please notify the sender immediately by return email or telephone call, and securely destroy this communication. Thank you.
Please reply to this message with "Unsubscribe" or "Unsubscribe All" in the subject line to unsubscribe from this mailing list or from all commercial electronic messages from Central 1.
More information about the users
mailing list