Shibboleth Idp 4+ MFA: is Azure MFA possible? If so, how?

[Robert Bradley]

On 16/11/2020 08:25, Vincent Feyaerts wrote:
> Hi,
> 
> Currently we have a Shibboleth IdP 3.x running with Microsoft ADFS as 
> slave for Microsoft Products like Office 365. We’re upgrading to Shib 
> IdP 4 soon. Since we are an educational institution, I don’t think it’s 
> realistic to have it reversed, where Shibboleth is the slave and ADFS is 
> the master. We’ve done some extensive finetuning for SP’s that have 
> special requirements, and we are part of a number of federations with 
> their own requirements, I don’t think we can emulate that IdP behaviour 
> with ADFS.
> 
> So now we are looking into MFA. Duo is, from a Shibboleth perspective, 
> by far the easiest to implement. It’s already there. But since we use a 
> lot of Microsoft products, Azure MFA has been mentioned as well. This 
> question has been asked before, but this information is old, and to be 
> honest, the answers are not 100% clear. So, is there any realistic 
> approach to integrating Azure MFA with a Shibboleth 4 IdP? This would be 
> custom code I guess, to be developed by somebody we pay. But does Azure 
> MFA even expose an API these days to make that possible? And more 
> importantly, can we assume that they will continue to provide this API? 
> Is anyone looking to implement such a solution?
> 

The Azure MFA SDK was removed, so the only way to implement Azure MFA 
with Shibboleth today is to use it as an upstream IdP and then use the 
IdP v4 SAML proxying support.  (You can do it with earlier versions by 
using the RemoteUser flow and protecting that with a Shibboleth SP 
install, but you lose things like forcing reauth or selecting 
authentication methods unless you clone the authentication flow several 
times.  It's doable but tedious.)

Having recently performed a similar migration, the SAML proxying is 
straightforward enough to set up, but there are some things that can 
catch you out.  For example, guest/external Azure AD users in your 
tenancy will be allowed to access the Shibboleth IdP SAML application* 
by default.  They will probably fail to resolve attributes, but that can 
cause headaches.  You also need to make sure your UPNs in Azure AD are 
what you expect them to be, and set up suitable subject canonicalization 
rules (c14n/subject-c14n.xml) to map between IdP and Azure usernames. 
You're unlikely to need to accept any additional attributes from the 
Azure IdP apart from the automatically-extracted name ID since you have 
your existing Shibboleth attribute resolver configuration.

Another thing to watch out for is that the SAML POST response from Azure 
AD to the Shibboleth IdP will trigger SameSite=Lax behaviour (in other 
words, cookies without SameSite=None will be withheld by recent Chrome 
releases).  The Shibboleth IdP has settings to override this, but you'll 
also want to check for issues with servlet container cookies 
(Tomcat/Jetty's JSESSIONID) and load balancer cookies if you use 
multiple servers.

I'd also add authnContextClassRef mappings to convert between the 
MS-supported authentication method names and the equivalent standard 
SAML names.  This needs to be done for both the 
"shibboleth.PrincipalProxyRequestMappings" (IdP->Azure) and 
"shibboleth.PrincipalProxyResponseMappings" (Azure->IdP) beans in 
authn/authn-comparison.xml.  I'd note that Azure AD can't do anything 
other than exact class matching, but in practice, those cases appear 
rare with most SPs not caring at all.  The important one to add is 
mapping the ADFS/Azure http://schemas.microsoft.com/claims/multipleauthn 
method to https://refeds.org/profile/mfa or another suitable method 
(TimeSyncToken?) so SPs can actively require MFA.

(* Azure terminology.)

-- 
Dr Robert Bradley
Identity and Access Management Team, IT Services, University of Oxford
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x9461A7CA76AFE3BE.asc
Type: application/pgp-keys
Size: 16768 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20201117/d0d2ed6d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://shibboleth.net/pipermail/users/attachments/20201117/d0d2ed6d/attachment.sig>