[External] Re: SP requesting MFA login
Jeffrey Williams
jfwillia at uncg.edu
Tue Sep 17 16:18:14 EDT 2019
Hi Shweta,
Thanks for the debug tip! I was able to confirm that indeed the idp is
short-circuiting the transitionMap after completing 1FA but before running
the checkSecondFactor script. It seems that the IdP is making a
sufficiency determination after the first factor, rather than waiting for
the flow to complete, like I was hoping for.
So if I want an SP to be able to request MFA, is there a way for me to
instruct the IdP to evaluate the transitionMap result's authnContext,
rather than the transitionMap's first step?
On Tue, Sep 17, 2019 at 3:36 PM Shweta Kautia <skautia at northcarolina.edu>
wrote:
> Jeff,
>
> I can't remember the exact error when i used the example you are using
> here. However, I had to add some logging to trace where the logic was
> breaking and ended up adding an attribute with a flag value, in the
> resolver file after checking for AD group membership there.
>
> I don't have an explanation of why that worked instead of checking for the
> AD group in that if statement like in the example.
>
> //SK: Determine if the nextFlow should be DUO based on criteria or pass through nextFlow = null; //SK: Adding logger logger = Java.type("org.slf4j.LoggerFactory").getLogger("net.shibboleth.idp.attribute.resolver");
>
>
> ....few lines below ...
>
> //SK: Check if user is part of the AD group Shib-Employee-MFA, if not skip the DUO Flow. if (attribute != null && attribute.getValues().contains(new valueType("1") ) ) { logger.info(" User in Shib-Employee-MFA (needs_duo). Prompting for DUO "); nextFlow = "authn/Duo"; }else{ logger.info(" User NOT IN Shib-Employee-MFA. Skipping for DUO "); }
>
>
> attribute-resolver.xml
>
> <!-- Duo flag attribute based on memberOf from AD --> <resolver:AttributeDefinition id="needs_duo" xsi:type="Script" xmlns="urn:mace:shibboleth:2.0:resolver:ad"> <resolver:Dependency ref="myLDAP" /> <Script><![CDATA[ logger = Java.type("org.slf4j.LoggerFactory").getLogger("net.shibboleth.idp.attribute.resolver.needs_duo"); duoflag = "0"; if (typeof memberOf == "undefined" || memberOf == null ){ logger.debug("memberOf attribute is not defined or null. Setting duoFlag to 0."); duoflag = "0"; }else{ for (i=0; i < memberOf.getValues().size(); i++) { tmp = memberOf.getValues().get(i); if (tmp.toLowerCase().equals("cn=shib-employee-mfa<some other values here..>")) { logger.debug("User is opted-in to Duo"); duoflag = "1"; } } }//end else memberOf == null //check if the requesting SP/relying party should be prompted for DUO. rpid = profileContext.getSubcontext("net.shibboleth.idp.profile.context.RelyingPartyContext").getRelyingPartyId(); logger.debug("rpid=" + rpid); if (rpid.equals("<entity_ID>")){ duoflag = "1"; } * needs_duo.addValue(duoflag); * logger.debug("needs_duo final value: " + needs_duo.getValues().get(0)); ]]></Script>
>
>
>
> Thanks,
>
> Shweta Kautia
>
> ------------------------------
> *From:* users <users-bounces at shibboleth.net> on behalf of Jeffrey
> Williams <jfwillia at uncg.edu>
> *Sent:* Tuesday, September 17, 2019 3:20 PM
> *To:* users at shibboleth.net <users at shibboleth.net>
> *Subject:* [External] Re: SP requesting MFA login
>
> *[CAUTION: External email. Do not click links or open attachments unless
> verified. Send all suspicious email as an attachment to
> spam at northcarolina.edu <spam at northcarolina.edu>]*
>
> David is correct. Apologies for the lack of detail. Any user, regardless
> of their MFA enrollment status, will encounter that error when they try to
> log into an SP that is requesting the MFA profile. Here is how our flow
> looks today(largely adapted from our 2.x environment that used this as a
> reference:
> https://wiki.shibboleth.net/confluence/pages/viewpage.action?pageId=32112643
> )
>
> <util:map id="shibboleth.authn.MFA.TransitionMap">
> <!-- First rule runs the authn/Password login flow. -->
> <entry key="">
> <bean parent="shibboleth.authn.MFA.Transition"
> p:nextFlow="authn/Password" />
> </entry>
>
> <!--
> Second rule runs a function if authn/Password succeeds, to
> determine whether an additional
> factor is required.
> -->
> <entry key="authn/Password">
> <bean parent="shibboleth.authn.MFA.Transition"
> p:nextFlowStrategy-ref="checkSecondFactor" />
> </entry>
>
> <!-- An implicit final rule will return whatever the final flow
> returns. -->
> </util:map>
>
> <bean id="checkSecondFactor"
> parent="shibboleth.ContextFunctions.Scripted" factory-method="inlineScript"
> p:customObject-ref="shibboleth.AttributeResolverService">
> <constructor-arg>
> <value>
> <![CDATA[
> nextFlow = null;
>
> // Go straight to second factor if we have to, or set up
> for an attribute lookup first.
> authCtx =
> input.getSubcontext("net.shibboleth.idp.authn.context.AuthenticationContext");
> mfaCtx =
> authCtx.getSubcontext("net.shibboleth.idp.authn.context.MultiFactorAuthenticationContext");
> if (mfaCtx.isAcceptable()) {
> // Attribute check is required to decide if first
> factor alone is enough.
> resCtx = input.getSubcontext(
>
> "net.shibboleth.idp.attribute.resolver.context.AttributeResolutionContext",
> true);
> resCtx.setPrincipal(input.getSubcontext(
>
> "net.shibboleth.idp.authn.context.SubjectCanonicalizationContext").getPrincipalName());
>
> resCtx.getRequestedIdPAttributeNames().add("ADmemberOf");
> resCtx.resolveAttributes(custom);
>
> // Check for an attribute that authorizes use of first
> factor.
> attribute =
> resCtx.getResolvedIdPAttributes().get("ADmemberOf");
> valueType =
> Java.type("net.shibboleth.idp.attribute.StringAttributeValue");
> if (attribute != null &&
> attribute.getValues().contains(new
> valueType("CN=duoActiveUsers,OU=are,OU=here,O=uncg"))) {
> nextFlow = "authn/Duo";
> }
>
> input.removeSubcontext(resCtx); // cleanup
> }
>
> nextFlow; // pass control to second factor or end with
> the first
> ]]>
> </value>
> </constructor-arg>
> </bean>
>
>
> Based on it's behavior, it looks like it's making a non-proceed decision
> after the first factor without proceeding to the checkSecondFactor(where
> the MFA magic happens). I can provide more configs if it helps.
>
>
>
> On Tue, Sep 17, 2019 at 12:58 PM Jeffrey Williams <jfwillia at uncg.edu>
> wrote:
>
> I'm looking for guidance on the best approach to a request.
>
> We're currently running 3.3.3 using the native Duo plugin and the IDP has
> only one flow. It's scripted to check to see if the user is enrolled in MFA
> before presenting authn/Duo.
>
> We have a vendor using Shibboleth SP that we're looking to integrate with
> and one of the requirements is that authorized users must MFA into the
> service. My first thought was to have the SP configured their
> authnContextClassRef to our MFA value ("https://refeds.org/profile/mfa").
> However, it seems that the IdP's authentication flow short-circuits after
> 1FA and sends an error back to the SP saying:
>
>
> SAML response reported an IdP error.
> Error from identity provider:
> *Sub-Status:* urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext
> *Message:* An error occurred.
>
> *Status:* urn:oasis:names:tc:SAML:2.0:status:Requester
>
> With the following in the IdP logs:
>
> 2019-09-16 19:21:30,180 - INFO
> [net.shibboleth.idp.authn.impl.ValidateUsernamePasswordAgainstLDAP:152] -
> Profile Action ValidateUsernamePasswordAgainstLDAP: Login by 'jfwillia'
> succeeded
> 2019-09-16 19:21:30,191 - DEBUG
> [net.shibboleth.idp.session.impl.DetectIdentitySwitch:148] - Profile Action
> DetectIdentitySwitch: No previous session found, nothing to do
> 2019-09-16 19:21:30,191 - WARN
> [net.shibboleth.idp.authn.impl.FinalizeAuthentication:179] - Profile Action
> FinalizeAuthentication: Authentication result for flow authn/MFA did not
> satisfy the request
> 2019-09-16 19:21:30,195 - WARN
> [org.opensaml.profile.action.impl.LogEvent:105] - A non-proceed event
> occurred while processing the request: RequestUnsupported
>
> This is regardless of MFA enrollment.
>
> I checked through the docs and didn't find anything that seemed to answer
> the question. Is there a way to maintain the single authentication flow
> and have it only authenticate MFA users for this SP?
>
> --
> Jeffrey Williams
> Identity Engineer
> Identity & Access Services
> https://its.uncg.edu
>
>
>
>
> --
> Jeffrey Williams
> Identity Engineer
> Identity & Access Services
> https://its.uncg.edu
>
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
--
Jeffrey Williams
Identity Engineer
Identity & Access Services
https://its.uncg.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190917/d4ae8028/attachment.html>
More information about the users
mailing list