SP requesting MFA login
Jeffrey Williams
jfwillia at uncg.edu
Tue Sep 17 15:20:14 EDT 2019
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190917/bf1c4a2e/attachment.html>
More information about the users
mailing list