Authentication failed with my Password/SPNEGO MFA configuration

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Authentication failed with my Password/SPNEGO MFA configuration

Wessel, Keith William
Hi, all,

I mentioned a few weeks back that I created an MFA flow that used SPNEGO and intelligently failed back to Password before proceeding to Duo if SPNEGO failed. Turns out that my configuration only worked when p:reuseCondition was set to true for the authn/MFA bean. When set to false, authentication worked for the first authentication of a browser session. Subsequent attempts result in the IdP reporting authentication failed and returning a failed SAML authn response to the SP.

For what it's worth, I'm including my MFA flow below. But I don't think that's the problem. We need to have reuseCondition set to false to make step-up authentication work, or at least that's the only way I can think of to make it work. Given that constraint, is there any way to make the below function properly? Or perhaps I should start with can anyone tell me why it might be failing? I'm wondering if the event coming out of the SPNEGO flow might be a proceed event on subsequent authentications for some reason, though I can't figure out why.

Any thoughts appreciated.

Keith

    <util:map id="shibboleth.authn.MFA.TransitionMap">
        <entry key="">
            <bean parent="shibboleth.authn.MFA.Transition" p:nextFlow="authn/SPNEGO" />
        </entry>

        <entry key="authn/SPNEGO">
            <bean parent="shibboleth.authn.MFA.Transition">
                <property name="nextFlowStrategyMap">
                    <map>
                        <entry key="proceed" value-ref="checkSecondFactor" />
                        <entry key="*" value="authn/Password" />
                    </map>
                </property>
            </bean>
        </entry>

        <entry key="authn/Password">
            <bean parent="shibboleth.authn.MFA.Transition" p:nextFlowStrategy-ref="checkSecondFactor" />
        </entry>
    </util:map>


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Authentication failed with my Password/SPNEGO MFA configuration

Cantor, Scott E.
On 11/12/19, 6:04 PM, "users on behalf of Wessel, Keith" <[hidden email] on behalf of [hidden email]> wrote:

> I'm wondering if the event coming out of the SPNEGO flow might be a proceed event on subsequent authentications for
> some reason, though I can't figure out why.

I can't really diagnose anything without evidence of what the failure is in response to, but I would assume it's probably doing that. Not reusing the MFA result doesn't prevent the subflows its running from being reused. The active subresults are unpacked and saved off and may be reused any time those flows are run by the MFA rules, so a previous SPNEGO result would be potentially reused when you "run" it, as would Password.

If things are failing, usually its because of a screwed up set of supportedPrincipals in the relevant places and an MFA script that's not taking into consideration what the end result its producing actually supports.

The examples that run the isAcceptable() checks show how to prevent a second factor from running when it's not needed, but that doesn't prevent a final result from being unacceptable if the final result just doesn't satisfy the request.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Authentication failed with my Password/SPNEGO MFA configuration

Wessel, Keith William
Hi, Scott,

The resue of the component flow results was what I suspected, but I've tinkered with that and still haven't gotten anywhere. Furthermore, it makes no sense to me why that's an issue for authn requests against existing IdP sessions but not for newly created ones. After all, before adding SPNEGO to the mix (before, I just had authn/Password leading to the checkSecondFactor bean), this was working fine for subsequent logins.

The log isn't helping me, but maybe it'll give you or someone else a clue. For some reason, the authn/Password flow isn't leading to a cached result on the Duo flow. In fact, it doesn't even seem to be running the Duo flow which tells me my checkSecondFactor bean may or may not be getting called at all. But that bean and included script is identical with and without the SPNEGO piece added in.

Any thoughts?

Thanks,
Keith
2019-11-13 08:35:11,103 - DEBUG [net.shibboleth.idp.authn.impl.PopulateAuthenticationContext:221] - Profile Action PopulateAuthenticationContext: Installed 2 potential authentication flows into AuthenticationContext - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]
2019-11-13 08:35:11,204 - DEBUG [net.shibboleth.idp.authn.impl.InitializeRequestedPrincipalContext:152] - Profile Action InitializeRequestedPrincipalContext: Profile configuration did not supply any default authentication methods - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]
2019-11-13 08:35:11,205 - DEBUG [net.shibboleth.idp.authn.impl.FilterFlowsByForcedAuthn:53] - Profile Action FilterFlowsByForcedAuthn: Request does not have forced authentication requirement, nothing to do - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]
2019-11-13 08:35:11,206 - DEBUG [net.shibboleth.idp.authn.impl.FilterFlowsByNonBrowserSupport:53] - Profile Action FilterFlowsByNonBrowserSupport: Request does not have non-browser requirement, nothing to do - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]
2019-11-13 08:35:11,211 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:264] - Profile Action SelectAuthenticationFlow: No specific Principals requested - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]
2019-11-13 08:35:11,212 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:309] - Profile Action SelectAuthenticationFlow: No usable active results available, selecting an inactive flow - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]
2019-11-13 08:35:11,212 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:363] - Profile Action SelectAuthenticationFlow: Selecting inactive authentication flow authn/SPNEGO - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]
2019-11-13 08:35:11,214 - INFO [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:138] - Profile Action SelectAuthenticationFlow: Moving incomplete flow authn/SPNEGO to intermediate set - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]
2019-11-13 08:35:11,215 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:264] - Profile Action SelectAuthenticationFlow: No specific Principals requested - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]
2019-11-13 08:35:11,215 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:309] - Profile Action SelectAuthenticationFlow: No usable active results available, selecting an inactive flow - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]
2019-11-13 08:35:11,215 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:363] - Profile Action SelectAuthenticationFlow: Selecting inactive authentication flow authn/MFA - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]
2019-11-13 08:35:11,222 - DEBUG [net.shibboleth.idp.authn.impl.PopulateMultiFactorAuthenticationContext:164] - Profile Action PopulateMultiFactorAuthenticationContext: 2 active result(s) extracted for possible reuse - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]
2019-11-13 08:35:11,229 - DEBUG [net.shibboleth.idp.authn.impl.TransitionMultiFactorAuthentication:207] - Profile Action TransitionMultiFactorAuthentication: Applying MFA transition rule to determine initial state - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]
2019-11-13 08:35:11,230 - DEBUG [net.shibboleth.idp.authn.impl.TransitionMultiFactorAuthentication:221] - Profile Action TransitionMultiFactorAuthentication: MFA flow transition after 'proceed' event to 'authn/SPNEGO' flow - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]
2019-11-13 08:35:11,231 - DEBUG [net.shibboleth.idp.authn.impl.TransitionMultiFactorAuthentication:209] - Profile Action TransitionMultiFactorAuthentication: Applying MFA transition rule to exit state 'authn/SPNEGO' - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]
2019-11-13 08:35:11,231 - DEBUG [net.shibboleth.idp.authn.impl.TransitionMultiFactorAuthentication:221] - Profile Action TransitionMultiFactorAuthentication: MFA flow transition after 'ReselectFlow' event to 'authn/Password' flow - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]
2019-11-13 08:35:11,232 - DEBUG [net.shibboleth.idp.authn.impl.TransitionMultiFactorAuthentication:271] - Profile Action TransitionMultiFactorAuthentication: Reusing active result for 'authn/Password' flow - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]
2019-11-13 08:35:11,232 - DEBUG [net.shibboleth.idp.authn.impl.TransitionMultiFactorAuthentication:209] - Profile Action TransitionMultiFactorAuthentication: Applying MFA transition rule to exit state 'authn/Password' - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]
2019-11-13 08:35:11,234 - DEBUG [net.shibboleth.idp.authn.impl.TransitionMultiFactorAuthentication:226] - Profile Action TransitionMultiFactorAuthentication: MFA flow completing with event 'ReselectFlow' - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]
2019-11-13 08:35:11,237 - INFO [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:138] - Profile Action SelectAuthenticationFlow: Moving incomplete flow authn/MFA to intermediate set - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]
2019-11-13 08:35:11,237 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:264] - Profile Action SelectAuthenticationFlow: No specific Principals requested - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]
2019-11-13 08:35:11,238 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:309] - Profile Action SelectAuthenticationFlow: No usable active results available, selecting an inactive flow - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]
2019-11-13 08:35:11,238 - INFO [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:313] - Profile Action SelectAuthenticationFlow: No potential flows left to choose from, authentication failed - [session=node0884dne262pwm1mlj0fi6yk63c4] [ip=10.193.6.152]

-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Tuesday, November 12, 2019 5:12 PM
To: Shib Users <[hidden email]>
Subject: Re: Authentication failed with my Password/SPNEGO MFA configuration

On 11/12/19, 6:04 PM, "users on behalf of Wessel, Keith" <[hidden email] on behalf of [hidden email]> wrote:

> I'm wondering if the event coming out of the SPNEGO flow might be a proceed event on subsequent authentications for
> some reason, though I can't figure out why.

I can't really diagnose anything without evidence of what the failure is in response to, but I would assume it's probably doing that. Not reusing the MFA result doesn't prevent the subflows its running from being reused. The active subresults are unpacked and saved off and may be reused any time those flows are run by the MFA rules, so a previous SPNEGO result would be potentially reused when you "run" it, as would Password.

If things are failing, usually its because of a screwed up set of supportedPrincipals in the relevant places and an MFA script that's not taking into consideration what the end result its producing actually supports.

The examples that run the isAcceptable() checks show how to prevent a second factor from running when it's not needed, but that doesn't prevent a final result from being unacceptable if the final result just doesn't satisfy the request.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Authentication failed with my Password/SPNEGO MFA configuration

Cantor, Scott E.
You're running SPNEGO both outside MFA and inside MFA. If nothing else, that's going to be very hard to get proper behavior from, and it won't do what you think it should, but I think the problem here is a bug. I think it's returning a previously saved off error event from the SPNEGO attempt instead of returning the result of the authn/Password flow (which in the case of reuse would just be a success). The bug comes up when you have this case of flows that constantly fail (SPNEGO) in the middle of things.

Normally the MFA rules would tend to be more like "do thing, if thing fails, abort, otherwise keep doing more things". That works. The bug affects sequences like "do thing, if thing fails, try other thing instead".

I think in this kind of case, using SPNEGO outside of the MFA rules only might be the best workaround, not to mention easier to manage. Something that's just as weird and unreliable as that probably should be off by itself perhaps.

But...if you wanted to keep it all inside MFA (and you'd need to stop enabling SPNEGO by itself to do that), the bug fix I think you would need is to insert a scripting step that handles the failure from SPNEGO and overwrites a field to clear it. Calling MultiFactorAuthenticationContext.setEvent(null) should reset things so that if Password succeeds it doesn't accidentally return the old event string. "ReselectFlow" is the thing it's returning and saving off, that's the usual "it failed but try something else" event in the system.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Authentication failed with my Password/SPNEGO MFA configuration

Cantor, Scott E.
On 11/13/19, 10:25 AM, "users on behalf of Cantor, Scott" <[hidden email] on behalf of [hidden email]> wrote:

> But...if you wanted to keep it all inside MFA (and you'd need to stop enabling SPNEGO by itself to do that), the bug fix I
> think you would need is to insert a scripting step that handles the failure from SPNEGO and overwrites a field to clear it.

Actually, I don't think that will work around it, I think the bug runs deeper and the event it's returning is probably an actual event from elsewhere in the state of the request, not that particular slot.

I'll file a bug but I'll have to come up with some reproduction strategy for it to be sure I'm understanding what's wrong.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Authentication failed with my Password/SPNEGO MFA configuration

Wessel, Keith William
Thanks, Scott. I actually didn't want to run SPNEGO outside of MFA at all, but I couldn't get the flow to show up as a button on my login.vm without enabling the flow in idp.properties.

Is there a way to get it to show up as an extended flow listed in the password authn config without also listing it as an active flow?

Regardless, we still do need it as part of our MFA flow as we don't want folks getting in on SPNEGO alone without Duo. It sounds like I hope no hope of that until this bug is addressed. Is that correct?

Thanks,
Keith


-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Wednesday, November 13, 2019 9:35 AM
To: Shib Users <[hidden email]>
Subject: Re: Authentication failed with my Password/SPNEGO MFA configuration

On 11/13/19, 10:25 AM, "users on behalf of Cantor, Scott" <[hidden email] on behalf of [hidden email]> wrote:

> But...if you wanted to keep it all inside MFA (and you'd need to stop
> enabling SPNEGO by itself to do that), the bug fix I think you would need is to insert a scripting step that handles the failure from SPNEGO and overwrites a field to clear it.

Actually, I don't think that will work around it, I think the bug runs deeper and the event it's returning is probably an actual event from elsewhere in the state of the request, not that particular slot.

I'll file a bug but I'll have to come up with some reproduction strategy for it to be sure I'm understanding what's wrong.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Authentication failed with my Password/SPNEGO MFA configuration

Cantor, Scott E.
On 11/13/19, 10:42 AM, "users on behalf of Wessel, Keith" <[hidden email] on behalf of [hidden email]> wrote:

> Is there a way to get it to show up as an extended flow listed in the password authn config without also listing it as an
> active flow?

That extended flows thing is deprecated without being officially planned for removal yet. If not for the bug here, the answer would to be avoid it, and not use the existing Password/SPNEGO stuff, you should script all that from the MFA flow. Buttons can trigger events, and the MFA rules can respond to events, etc. That's all doable without any of the older features. The problem is the handling of the failure right now.
 
> Regardless, we still do need it as part of our MFA flow as we don't want folks getting in on SPNEGO alone without Duo.
> It sounds like I hope no hope of that until this bug is addressed. Is that correct?

Until I know what's really going on I can't really even envision what would work as a fix. Perhaps some kind of dummy subflow to run just to clear the state of the system, so that could be run as a consequence of the failure event from SPNEGO. I think it might be fixable just with a script, but I have to see it first.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Authentication failed with my Password/SPNEGO MFA configuration

Wessel, Keith William
Thanks, Scott. Didn't even think about triggering the events to run a subflow within the MFA framework. That makes perfect sense.

I'd offer to file a bug on this issue, but I'm not even sure how to describe it. It sounds like you've got it covered, though. If there's a scriptable solution or workaround, I'd be eager to know when you find out.

Thanks again,
Keith


-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Wednesday, November 13, 2019 9:56 AM
To: Shib Users <[hidden email]>
Subject: Re: Authentication failed with my Password/SPNEGO MFA configuration

On 11/13/19, 10:42 AM, "users on behalf of Wessel, Keith" <[hidden email] on behalf of [hidden email]> wrote:

> Is there a way to get it to show up as an extended flow listed in the password authn config without also listing it as an
> active flow?

That extended flows thing is deprecated without being officially planned for removal yet. If not for the bug here, the answer would to be avoid it, and not use the existing Password/SPNEGO stuff, you should script all that from the MFA flow. Buttons can trigger events, and the MFA rules can respond to events, etc. That's all doable without any of the older features. The problem is the handling of the failure right now.
 
> Regardless, we still do need it as part of our MFA flow as we don't want folks getting in on SPNEGO alone without Duo.
> It sounds like I hope no hope of that until this bug is addressed. Is that correct?

Until I know what's really going on I can't really even envision what would work as a fix. Perhaps some kind of dummy subflow to run just to clear the state of the system, so that could be run as a consequence of the failure event from SPNEGO. I think it might be fixable just with a script, but I have to see it first.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Authentication failed with my Password/SPNEGO MFA configuration

Cantor, Scott E.
On 11/13/19, 11:05 AM, "users on behalf of Wessel, Keith" <[hidden email] on behalf of [hidden email]> wrote:

> I'd offer to file a bug on this issue, but I'm not even sure how to describe it. It sounds like you've got it covered, though.
> If there's a scriptable solution or workaround, I'd be eager to know when you find out.

I filed it, it's https://issues.shibboleth.net/jira/browse/IDP-1519

I need to reproduce with something that's not SPNEGO for sanity, but I don't think it's specific to SPNEGO.

The actual bug fix I think will be to bypass looking at the system's "previous event state" but I'll see if I can workaround it with something in a script before I change any code.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Authentication failed with my Password/SPNEGO MFA configuration

Wessel, Keith William
Thanks, Scott. I'll keep an eye on that issue.

Keith


-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Wednesday, November 13, 2019 10:09 AM
To: Shib Users <[hidden email]>
Subject: Re: Authentication failed with my Password/SPNEGO MFA configuration

On 11/13/19, 11:05 AM, "users on behalf of Wessel, Keith" <[hidden email] on behalf of [hidden email]> wrote:

> I'd offer to file a bug on this issue, but I'm not even sure how to describe it. It sounds like you've got it covered, though.
> If there's a scriptable solution or workaround, I'd be eager to know when you find out.

I filed it, it's https://issues.shibboleth.net/jira/browse/IDP-1519

I need to reproduce with something that's not SPNEGO for sanity, but I don't think it's specific to SPNEGO.

The actual bug fix I think will be to bypass looking at the system's "previous event state" but I'll see if I can workaround it with something in a script before I change any code.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Authentication failed with my Password/SPNEGO MFA configuration

Losen, Stephen C (scl)
In reply to this post by Wessel, Keith William
Hi,
I don't know if this applies or not, but we are using a button in login.vm to let the user select a x509 client certificate login instead of username/password. The client cert stuff is handled by our F5 load balancer and we are using RemoteUser to fetch the username from a HTTP header passed by the F5. But that's not really the point here. The button on our login.vm causes the Password flow to return with a custom event (UseCert). In our MFA config, if Password returns this event, then MFA launches RemoteUser. If Password returns "proceed" or RemoteUser returns "proceed" then MFA launches Duo. So the user sees the login page and can either enter username/password or click the "Use Cert" button.  If either succeeds, then they go to Duo. Perhaps you could have a similar button for SPNEGO, which I know nothing about, so this approach may not work. By the way, MFA is the only flow enabled in our idp.properties.

Steve Losen
Research Computing
University of Virginia
[hidden email]   434-924-0640

´╗┐On 11/13/19, 10:42 AM, "users on behalf of Wessel, Keith" <[hidden email] on behalf of [hidden email]> wrote:

    Thanks, Scott. I actually didn't want to run SPNEGO outside of MFA at all, but I couldn't get the flow to show up as a button on my login.vm without enabling the flow in idp.properties.
   
    Is there a way to get it to show up as an extended flow listed in the password authn config without also listing it as an active flow?
   
    Regardless, we still do need it as part of our MFA flow as we don't want folks getting in on SPNEGO alone without Duo. It sounds like I hope no hope of that until this bug is addressed. Is that correct?
   
    Thanks,
    Keith
   
   
    -----Original Message-----
    From: users <[hidden email]> On Behalf Of Cantor, Scott
    Sent: Wednesday, November 13, 2019 9:35 AM
    To: Shib Users <[hidden email]>
    Subject: Re: Authentication failed with my Password/SPNEGO MFA configuration
   
    On 11/13/19, 10:25 AM, "users on behalf of Cantor, Scott" <[hidden email] on behalf of [hidden email]> wrote:
   
    > But...if you wanted to keep it all inside MFA (and you'd need to stop
    > enabling SPNEGO by itself to do that), the bug fix I think you would need is to insert a scripting step that handles the failure from SPNEGO and overwrites a field to clear it.
   
    Actually, I don't think that will work around it, I think the bug runs deeper and the event it's returning is probably an actual event from elsewhere in the state of the request, not that particular slot.
   
    I'll file a bug but I'll have to come up with some reproduction strategy for it to be sure I'm understanding what's wrong.
   
    -- Scott
   
   
    --
    For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
    To unsubscribe from this list send an email to [hidden email]
    --
    For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
    To unsubscribe from this list send an email to [hidden email]
   

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Authentication failed with my Password/SPNEGO MFA configuration

Cantor, Scott E.
On 11/13/19, 12:41 PM, "users on behalf of Losen, Stephen C (scl)" <[hidden email] on behalf of [hidden email]> wrote:

> I don't know if this applies or not, but we are using a button in login.vm to let the user select a x509 client certificate
> login instead of username/password. The client cert stuff is handled by our F5 load balancer and we are using
> RemoteUser to fetch the username from a HTTP header passed by the F5. But that's not really the point here. The
> button on our login.vm causes the Password flow to return with a custom event (UseCert). In our MFA config, if
> Password returns this event, then MFA launches RemoteUser.

That's exactly the sort of thing I was referring to. The old extended flow thing was a rudimentary way of doing that without the open-endedness. I will probably think about redoing the templates and some of the SPNEGO examples around this at some point.

> If Password returns "proceed" or RemoteUser returns "proceed" then MFA launches Duo. So the user sees the login
> page and can either enter username/password or click the "Use Cert" button.  If either succeeds, then they go to Duo.
> Perhaps you could have a similar button for SPNEGO, which I know nothing about, so this approach may not work. By
> the way, MFA is the only flow enabled in our idp.properties.

It's essentially the same, yes.

The problem with the bug is the notion of "failure, then success", where as "success, then success or failure" works ok.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Authentication failed with my Password/SPNEGO MFA configuration

Cantor, Scott E.
In reply to this post by Cantor, Scott E.
Keith, I added the workaround I came up with in the bug comment, it wasn't too horrible.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Authentication failed with my Password/SPNEGO MFA configuration

Wessel, Keith William
Thanks, Scott. Yes, I added the dummyflow and incorporated it into my MFA flow, and it now works. I haven't confirmed that step-up still works as it should, but I don't see how this could have broken that. So, this works. Assuming this is a workaround, not a long-term fix, and that eventually the old way I had this will work. Is that correct?

Thanks again for the speedy and helpful fix,
Keith


-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Wednesday, November 13, 2019 12:52 PM
To: Shib Users <[hidden email]>
Subject: Re: Authentication failed with my Password/SPNEGO MFA configuration

Keith, I added the workaround I came up with in the bug comment, it wasn't too horrible.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Authentication failed with my Password/SPNEGO MFA configuration

Cantor, Scott E.
On 11/13/19, 3:10 PM, "users on behalf of Wessel, Keith" <[hidden email] on behalf of [hidden email]> wrote:

> Thanks, Scott. Yes, I added the dummyflow and incorporated it into my MFA flow, and it now works. I haven't confirmed
> that step-up still works as it should, but I don't see how this could have broken that.

I don't think doing this should be a problem, but more to the point anything it breaks is probably also at risk from my code fix, so it's best to find any problems now.

> So, this works. Assuming this is a workaround, not a long-term fix, and that eventually the old way I had this will work. Is
> that correct?

Yes, I believe so.
 
> Thanks again for the speedy and helpful fix,

Thank you for exposing the bug.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Authentication failed with my Password/SPNEGO MFA configuration

Wessel, Keith William
Just FYI, I tested step-up authentication, and it works. The SP not requiring 2FA lets me in with password, and the SP that I then access that requires 2FA causes the IdP to go straight to a Duo prompt.

Thanks again, Scott.

Keith


-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Wednesday, November 13, 2019 2:20 PM
To: Shib Users <[hidden email]>
Subject: Re: Authentication failed with my Password/SPNEGO MFA configuration

On 11/13/19, 3:10 PM, "users on behalf of Wessel, Keith" <[hidden email] on behalf of [hidden email]> wrote:

> Thanks, Scott. Yes, I added the dummyflow and incorporated it into my MFA flow, and it now works. I haven't confirmed
> that step-up still works as it should, but I don't see how this could have broken that.

I don't think doing this should be a problem, but more to the point anything it breaks is probably also at risk from my code fix, so it's best to find any problems now.

> So, this works. Assuming this is a workaround, not a long-term fix, and that eventually the old way I had this will work. Is
> that correct?

Yes, I believe so.
 
> Thanks again for the speedy and helpful fix,

Thank you for exposing the bug.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]