Anyone working on a Proxy IDP extension for V3?

Henri Mikkonen henri.mikkonen at csc.fi
Fri Feb 26 04:51:52 EST 2016


Hello, 

In short, the goal of the MPASS project is to develop a SAML proxy IdP that outsources the user authentication for multiple sources. Those sources include for instance social media providers (via OAuth/OIDC) and SAML IdPs. We have implemented this on top of Shib IdP v3. 

Primarily every authentication source has its own authentication flow. Also the discovery of the desired authentication flow is implemented via flow that displays the available authentication flows for the user and signals the selected flow for Shib IdP. Most of our Shib-plugins at our GitHub repository are already in pilot/beta use and have so far worked without problems. However, they cannot be considered (yet) as general production-ready plugins, as we have so far concentrated on fulfilling our own requirements. I also admit that the documentation doesn't cover all at the moment. 

Regarding the Shib SP authn plugin, it's possible to either configure (1) one authentication flow for each IdP or (2) one authentication flow for many IdPs via for instance embedded DS. First option is better if you want to support also other authentication flows than SAML IdP -based flows, as this way you can include them all in the same discovery page (via our discovery-plugin). However, if you only have SAML IdPs as authentication sources, then you can use the second option and let embedded DS do the discovery for you. In that case you don't even need discovery flow at IdP as single shibsp-flow would be the only flow configured in idp.properties. 

In any case, shibsp-flow records all environment variables / headers provided by ShibSP to IdP's authentication context. You can access them in attribute resolver for instance via scripted attribute definition and thus encode them as for instance SAML attributes for the relying parties. 

Feel free to make GitHub issues if some desired feature is missing, has bugs or lacks documentation. 

BR, 
Henri.

> On 25 Feb 2016, at 18:01, Wessel, Keith <kwessel at illinois.edu> wrote:
> 
> Very interesting. Do you know how production-ready this effort is?
> 
> Reading this sentence, though, it seems like we'll be setting up a discovery service, anyway:
> 
> It's possible to  configure multiple flows with different SP Handler configurations, or support multiple IdPs for instance via Shibboleth Embedded Discovery Service  .
> 
> So, while this will give us a Proxy IDP for applications that can't handle the discovery protocol, we could have those that can go directly to the embedded discovery service. If our goal is to eliminate the discovery page and let the proxy IDP collect the campus, username and password on one screen, this won't do it. If, however, we want to keep the interface the same for both the proxy IDP and folks wanting to continue using a discovery page, this is very interesting.
> 
> Keith
> 
> -----Original Message-----
> From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Peter Schober
> Sent: Thursday, February 25, 2016 9:54 AM
> To: users at shibboleth.net
> Subject: Re: Anyone working on a Proxy IDP extension for V3?
> 
> * Liam Hoekenga <liamr at umich.edu> [2016-02-25 16:44]:
>> I haven't tried any of this stuff, but there appears to be a proxy for
>> IdPv3 available from
>> 
>> https://github.com/Digipalvelutehdas/MPASS-proxy
> 
> Ah, yes, I complete forgot about the Finnish work on this:
> https://github.com/Digipalvelutehdas/MPASS-proxy/tree/master/idp-authn-impl-shibsp
> -peter
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160226/0b908b55/attachment-0001.html>


More information about the users mailing list