ForceAuthn and RemoteUser handler

[Liam Hoekenga]

What SSO are you using to provide the REMOTE_USER information.  Do it have
a means for forcing reauthentication?

We're using some code we got from U-W that implements a forceAuthn capable
RemoteUser login handler, but the SSO you're tying it to has to support it.

Liam

On Mon, Oct 30, 2017 at 7:05 AM, Matthew Slowe <M.Slowe at kent.ac.uk> wrote:

> Good day!
>
> This is possibly in relation to the recent "Office 365 + Shibboleth ?"
> thread and has come about because we have Mac users who are unable to
> Activate their Office installations because Microsoft seem to have
> started requesting ForceAuthn in the requests for this.
>
>
> We're using the RemoteUserInternal authentication flow (in this case to
> facilitate using another SAML2 IDP as the Authentication source -
> modmellon is configured as part of Apache and handles the
> Authentication, passing in the REMOTE_USER variable based on the
> returned assertion from upstream).
>
> This was working great... until the downstream SP started setting
> ForceAuthn="true" on *some* incoming requests.
>
> Shibboleth is, quite rightly, configured to reject this for RemoteUser*
> authentication flows:
>
> > 2017-10-27 08:11:38,624 - DEBUG [net.shibboleth.idp.authn.
> impl.FilterFlowsByForcedAuthn:?] - Profile Action
> FilterFlowsByForcedAuthn: Removing flow authn/RemoteUserInternal, it does
> not support forced authentication
> > 2017-10-27 08:11:38,624 - INFO [net.shibboleth.idp.authn.
> impl.FilterFlowsByForcedAuthn:?] - Profile Action
> FilterFlowsByForcedAuthn: No potential authentication flows remain after
> filtering
>
> We are pursuing the SP to understand why it's setting ForceAuthn (but
> it's Microsoft/Office365 and is currently being a bit of a black-hole).
>
> I can see three possible ways out of this:
>
> 1) Configure Shibboleth IDP to lie about ForceAuthn
>
> I seem to be able to configure the general-authn.xml file to claim
> support for forced authentication for the RemoteUserInternal. I have not
> tried this and don't know if it will cause issues further down within
> the IDP code. I don't really like this as a solution - it goes against
> the grain somewhat - however it would be a very quick-win way out for now.
>
> Would updating the config in this way work?
>
>
> 2) Configure Shibboleth IDP to use another SAML2 IDP for upstream
> authentication
>
> There seem to be ways to configure the IDP to use CAS etc as an upstream
> authentication provider. Is there a way to do this but over SAML2 instead?
>
> I would need to be able to continue to support RemoteUser requests for
> some endpoints - notably the ECP ones.
>
>
> 3) Reconfigure the IDP to do the AuthN itself to LDAP
>
> Not high on my list of things I'd like to do as it would break the SSO
> model we currently use internally and would require a bunch of comms to
> users to warn them the login screen for some services is going to change
> etc.
>
>
>
> Also happy to take other suggestions?
>
> Thanks,
> foo
>
> --
> Matthew Slowe | Server Infrastructure Officer
> IT Infrastructure, Information Services, University of Kent
> Room S21, Cornwallis South
> Canterbury, Kent, CT2 7NZ, UK
> Tel: +44 (0)1227 824265
>
> www.kent.ac.uk/is | @UnikentUnseenIT | @UKCLibraryIt
> PGP: https://keybase.io/fooflington
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20171030/8d453345/attachment.html>