<div dir="ltr">Thank you so much. This gives me a good starting point.  </div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div></div><div><br></div><div>Brad Mathis</div><div>Principal Systems Analyst</div><div>Pima Community College</div><div>IT - Technical Services</div><div>520.206.4826</div><div><a href="mailto:bmathis@pima.edu" target="_blank">bmathis@pima.edu</a></div></div><div><br></div><div><img src="https://docs.google.com/a/pima.edu/uc?id=0B4QEFWYNTFJATTZySzROc0JISEk&export=download" width="200" height="150"><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Dec 21, 2017 at 7:57 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">> At the moment I get a second factor (DUO) prompt for everything.  I think<br>
> that's due to how I have the shibboleth.authn.MFA.<wbr>TransitionMap<br>
> configured<br>
<br>
You are explicitly telling it to do that. There's no "think" involved.<br>
<br>
> Eventually we will have about 10 to 15 SP's  some will need MFA and some<br>
> won't. Some will be CAS protocol and some won't (not sure that matters).<br>
<br>
It matters in that you can't tell the CAS SPs to request what they want.<br>
<br>
> Questions:<br>
><br>
> 1. Where/how to define the logic of what apps/SP's need a second factor<br>
> and which ones don't?<br>
<br>
That depends on your end game. If you want a permanent "some do, some don't" environment, then have as many SAML SPs as possible do it on their own, ask for that they want and enforce it. Use the "isAcceptable()" method on the MultiFactorAuthenticationConte<wbr>xt object in the tree to test whether to bother adding Duo, which is in the example provided with the software.<br>
<br>
For the SPs that can't request it, or are using CAS, set the defaultAuthenticationMethods property to inject a requirement on their profile configuration bean(s) in a relying party override and block them from requesting something different. That's outlined in the documentation on that property, which is the second hit from a wiki search, ProfileConfiguration-<wbr>Authentication.<br>
<br>
If your end game is "eventually on for everything", I would just move there as quickly as possible by picking a couple of big apps that will cover your population, force those on with a relying party override, and once everybody's ready, just flip the switch. If you must take years with it, I'd still focus on turning them on at the IdP end.<br>
<br>
Either way the MFA logic is trivial: do Password, if mfaCtx.isAcceptable() then done, else do Duo.<br>
<br>
> 2. Eventually we will want to use some type of opt-in for apps that don't<br>
> require MFA, we are hoping to be able to do that based on and attruibute we<br>
> set in ldap is that possible? ( I think it is )<br>
<br>
I wouldn't if your end game is all on, it's just wasted time, but that's what the example that ships with the software does, but you want to do opt-in for everything or you're going to have ordering issues that will make it difficult to get the results you're expecting because the logic only runs when the system doesn't bypass it for SSO.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Scott<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/<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>