<div dir="ltr">You must be right Scott; looking at old notes I see we thought we had this working, but eventually let them solicit users' credentials and use AD directly. No worries, it's only for financial transactions %-(<div><br></div><div>David</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 24, 2016 at 11:39 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>       There's no support by default to query on anything but transients.<br>
><br>
> which is what the Transact SP receives in the first SAML response, and then<br>
> uses in the attribute query; the transient nameid happens to be<br>
> orthographically equivalent to unencrypted ePPN, but encoded as a transient<br>
> name ID and included the SAML authN response as such<br>
<br>
</span>That wouldn't work, that's what I'm saying. The PrincipalConnector that is there by default only handles a transient NameID that can be reversed by mapping in memory back to the real user. A real EPPN would just be seen as an unmappable ID.<br>
<div class="HOEnZb"><div class="h5"><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div>