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