ForceAuthn and RemoteUser handler

Matthew Slowe M.Slowe at
Mon Oct 30 08:05:27 EDT 2017

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

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

Also happy to take other suggestions?


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 | @UnikentUnseenIT | @UKCLibraryIt

More information about the users mailing list