Adding attributes to external IdP response
Richard Abdill
rabdill at umn.edu
Tue Mar 13 15:54:27 EDT 2018
This is very helpful, thanks Tom. I had looked at simpleSAMLphp briefly,
and tried to track down a suggestion that OpenAM or KeyCloak (
https://github.com/keycloak/keycloak) might be practical alternatives, but
it's great just to have the vocabulary to search for more accurate
solutions.
Regards,
Rich
--
Richard Abdill
System Programmer | Minnesota Supercomputing Institute | msi.umn.edu
University of Minnesota | umn.edu
rabdill at umn.edu | 612-624-4714
On Tue, Mar 13, 2018 at 2:44 PM, Tom Scavo <trscavo at gmail.com> wrote:
> Hi Rich,
>
> On Tue, Mar 13, 2018 at 3:24 PM, Richard Abdill <rabdill at umn.edu> wrote:
> > I'm trying to unravel a weird use case and could use a hand. My team
> > supports applications that connect (via various service providers) to an
> > identity provider run by our university. The basic problem is that the
> user
> > data being returned from the university's system doesn't incorporate
> > information specific to our organization: attaching details about
> internal
> > groups a person is a part of, for example.
>
> That's not weird at all. It's quite typical in fact.
>
> > The theory was that there was a way to configure an identity provider to
> > pass requests through to the main IdP, then once a user has been
> > authenticated, append extra attributes to the response before it's sent
> back
> > to the application. We would then configure our applications to use our
> > "proxy" IdP, leaving them with the "main" response plus our extra
> > decorations.
>
> Yes, you've described what's known as a SAML IdP Proxy.
>
> > I've been told this is possible (possibly using the
> > RemoteUserAuthnConfiguration flow?), but I haven't been able to find any
> > indication in the documentation that this is an intended use of
> Shibboleth
> > IdP.
>
> It's not. Other implementations (such as simpleSAMLphp) are more adept
> as an IdP Proxy.
>
> > In case it's relevant, I'm told making any custom modifications to the
> > main IdP is not an option.
>
> Which is why the IdP Proxy approach has caught on.
>
> > Has anyone given this a try? This is personally my first real foray into
> > this arena, and I can't tell if "special information attached to some
> > requests but not others" is a logical use of federated identity
> management
> > or an egregious violation of it.
>
> The architecture you seek has in fact become staple fare for science
> and research applications. If your family of apps fit that category,
> you may want to contact cilogon.org, since they offer a service to the
> R&E community. That service is built using precisely the technology
> you've described.
>
> Hope this helps,
>
> Tom
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/
> confluence/x/coFAAg
> 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/20180313/0f0f64c0/attachment.html>
More information about the users
mailing list