SAML IdP Proxy

[Mark Scheible]

I don't see a problem with this scenario.  The institutional IdPs would be
sending their assertions through the SP side of the proxy, but they would
be responding to the individual vendor SPs, and the assertions should
contain the attributes requested by each vendor SP.  Having the "shared" DS
should eliminate the need for users to have to go through the Discovery
Service twice - assuming it happens transparently on the vendor side.

Mark


On Wed, Mar 13, 2013 at 3:32 AM, Peter Schober
<peter.schober at univie.ac.at>wrote:

> Not really about the Shibboleth software but I'll add a few
> comments anyway:
>
> * Eric Goodman <Eric.Goodman at ucop.edu> [2013-03-13 00:38]:
> > We're looking at implementing this in a case where multiple
> > cloud-hosted vendors (each of which supports SAML assertions, but
> > their discovery services are lacking) are each trying to integrate
> > with a defined (i.e., fixed membership) federation of
> > IdPs. Basically, the IdP Proxy is being used on the IdP side to
> > allow each vendor to see one IdP and "outsource" and share the DS
> > function, and on the SP side to allow the "home" IdPs to see the
> > multiple vendors as a single SP. (There are some other perceived
> > benefits as well, but those are some of the main drivers).
> >
> > In this case the IdP Proxy is only interacting with IdPs from within
> > one University system, so the privacy issues are (at least arguably)
> > less of an issue in this case.
>
> So this is for a single legal entity (one university system) which for
> whatever reasons has several IdPs (e.g. one for each campus)?
>
> I'd understand that some SPs would have problems with mapping multiple
> IdPs to a single customer/contract (many SPs have problem with pretty
> much everything) and seeing the one customer as only one IdP kind of
> makes sense from the SP side. (Of course if you're federating at all
> you should be able to deal with an arbitrary number of IdPs and so
> that shouldn't matter at all.)
> What I don't see is why you would want to make different SPs appear as
> one to the institutional IDPs, in the above case. That just takes away
> information and prevents the IdP from e.g. sending the minimally
> required set of information (assuming the set of data required is not
> the same for each SP). The larger the group of SPs hidden behind that
> proxied SP becomes (meaning a higher ROI in the proxy setup, by
> reducing necessary configuration at any of the involved IdPs) the more
> you're likely to run into that problem.
>
> Assuming the number of SPs hidden behind that proxy will always be
> dwarfed by the number of SPs any of those IdPs has to deal with (i.e.,
> without the proxy) that does not seem to bring any relevant reduction
> in complexity from the point of view of each individual IdP.
> -peter
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>



-- 

*Mark A. Scheible*
Sr. Lead IAM Solutions Architect
MCNC, Research Triangle Park, NC
*Office:* (919) 248-1997
*Cell:* (919) 609-8595
*Fax:* (919) 248-8419
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130313/d3482b96/attachment.html