Shib Authn Proxy to Azure and Asserting REFEDS

[Chris Phillips]

Hi Jeffrey..

Thanks for the feedback on the KB article!

 

One way to look at the MFA approach is that *all* accounts from Azure AD require MFA to go through the Shib IdP Proxy. Therefore, all accounts are MFA by default. If this is true for your Azure tenant, you can work on attesting an AuthNContext as REFEDS MFA. I don’t have precise settings for that for the KB article however.  If you go this route, let me know and will work it into the article..

 

While it sounds like an easy win, it only works for 100% MFA coverage  -- or at least 100% coverage of the _users_  through that proxy instance – ie an MFA only IdP. I cringe more than a bit though – it doesn’t scale well and may not be very palatable (or allowed?) for the same scopes inside a given federation.

 

Scott’s comments about using the technique in v4.1 is, to me,  the best pathway to pursue. 

It can handle a diverse account base of both MFA and non MFA accounts status and is something for the next iteration of that KB article that we’re early days on working through the step by step recipe..

 

All that said, if Services command (REFEDS) MFA be used  for sign on, it should be that transaction and every time it’s asked for. If it isn’t offered, the transaction should fail-secure. Fail-secure means the user sign on should not achieve sufficiency for MFA but Single Factor Authentication (SFA), password transport, or simply not logon.   This has nothing to do with Shibboleth and everything to do with practices on and around  MFA usage and policies in front of or upstream of the IdP  itself like in the proxy case.

 

Services commanding MFA expect it each and every time, not sometime in the last 30 days, the last 7 days, or even in the last 48hrs. They expect it for that sign on. I strongly encourage disabling/ignoring these ‘remember the token’  abilities as it’s not really truthful to the Service for MFA if those policies are in effect and applied. This will feel painful but when MFA is asked for the consequences are too high to fudge this aspect.

 

 

Chris.

 

From: "users-bounces at shibboleth.net" <users-bounces at shibboleth.net> on behalf of SHIB-USERS <users at shibboleth.net>
Reply-To: SHIB-USERS <users at shibboleth.net>
Date: Friday, January 22, 2021 at 5:03 PM
To: SHIB-USERS <users at shibboleth.net>
Cc: Jeffrey Williams <jfwillia at uncg.edu>
Subject: Shib Authn Proxy to Azure and Asserting REFEDS

 

Hi All,

 

I'm trying to configure Shibboelth v4.0.1 to assert https://refeds.org/profile/mfa after a user MFA's via proxy to Azure and am running into some interesting questions.

 

I have a semi-working instance of running in development that is doing proxying to Azure using the instructions given at:

 

https://wiki.shibboleth.net/confluence/display/KB/Using+SAML+Proxying+in+the+Shibboleth+IdP+to+connect+with+Azure+AD

 

(note, some additional work to the Azure metadata and subject-c14n.xml were needed, but not much)

The issue I'm currently dealing with is that Azure AD doesn't have it clearly documented what AuthnContexts one can request from it aside from 
http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod/password

What Azure seems to do instead is return the above AuthnContext and include an attribute http://schemas.microsoft.com/claims/authnmethodsreferences which returns the various authn's the user performed.  

The example code in authn-comparison.xml seems to indicate that it'll happily convert between AuthnContexts using shibboleth.PrincipalProxyResponseMappings.  Will it also allow AuthnContextClassRef to be influenced by a value returned in the attribute statement?

For example, if  within the AttributeStatement, an attribute http://schemas.microsoft.com/claims/authnmethodsreferences contained a value http://schemas.microsoft.com/claims/multipleauthn, could one map that to a https://refeds.org/profile/mfa authnContextClassRef in the AuthnStatement? Or is the mapping more simple than that?
 

If that's not possible, would it be possible to run a script after the authn/SAML flow that would do the attribute check and update the AuthnContext accordingly?  I've done scripting for determining when to present the Duo iFrame, but I'm not sure if it's possible to replace the AuthnContextClassRef value from a script or not.  

 

Thanks!

-- 

Jeffrey Williams 

Identity & Access Engineer
Identity & Access Services
https://its.uncg.edu

 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20210125/12588d7d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4340 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20210125/12588d7d/attachment.p7s>