<div dir="ltr">A possible option that might meet your requirements would be to require MFA at the IdP based on the principal;<div>an attribute in the principal's (LDAP) record can trigger the MFA for persons, but not for the service accounts.</div><div><br></div><div>We currently allow opt-in to MFA and use a value of LDAP attribute eduPersonAssurance to trigger MFA for those who opt in.</div><div><br></div><div>David Bantz</div><div>UA OIT IAM</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 2, 2019 at 8:47 AM Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Are there any other ways the Endpoint URL can be extracted and used to apply MFA on ?<br>
<br>
It's ill-advised; there is no support for applying policy to a request beyond the entityID, to avoid tying yourself to details of a deployment that are in no way assumed to be stable. Those URLs are not "applications" in the sense that you're trying to attach meaning to.<br>
<br>
To the extent that it would ever be done, it should be done with RelayState by agreeing to specific values amongst the parties that signal the appropriate things. That's not good, but it's better than relying on the endpoints.<br>
<br>
-- Scott<br>
<br>
<br>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>