Adding attributes to external IdP response

Richard Abdill rabdill at
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 ( might be practical alternatives, but
it's great just to have the vocabulary to search for more accurate


Richard Abdill
System Programmer | Minnesota Supercomputing Institute |
University of Minnesota |
rabdill at | 612-624-4714

On Tue, Mar 13, 2018 at 2:44 PM, Tom Scavo <trscavo at> wrote:

> Hi Rich,
> On Tue, Mar 13, 2018 at 3:24 PM, Richard Abdill <rabdill at> 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, 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
> confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list