Sv: Shibboleth 4.2.x and ADFS/Azure

[Mårtensson, Roger]

Hello!

> It (Azure AD IdP) seems to _always_ return the authn methods in an 
> attribute (claim):
>
> <Attribute 
> Name="http://schemas.microsoft.com/claims/authnmethodsreferences">
> 
> <AttributeValue>http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password</AttributeValue>
> 
> <AttributeValue>http://schemas.microsoft.com/claims/multipleauthn</AttributeValue>
> </Attribute>

This is what I noticed too.

> The note at the end of the howto will map the incoming REFEDS request 
> and the outgoing response to/from "multipleauthn". Have you done both 
> PrincipalProxyRequestMappings and PrincipalProxyResponseMappings parts 
> and definitely enabled SAML2AuthnContextClassRef in the 
> supportedPrincipals property? If so, is the REFEDS MFA profile 
> definitely being requested by the target SP?

> ... or are you hoping to _always_ return the MFA AuthnContextClassRef if 
> that's what was used upstream regardless of what the SP asked for?

I do have the mappings set in authn-comparison.xml. If I request a login through in an application with no need for MFA then I get a standard login.
If I use an application that requests REFEDS MFA (a test-application in this case) I get the ADFS MFA flow with login and subsequent MFA input.
So I believe our IDP is sending the right signals.
And no. I do not want to _always_ return the MFA AuthnContext, only when requested by an SP. (using REFEDS MFA signaling)

I have noticed that I get different AuthnContext from the ADFS if I login in using name/password than when the login is though windows authentication (SSO with windows logged in user).
(but that has probably nothing to do with my problem)

It may be that I have missed setting up something in our ADFS-server but I'm no ADFS-expert so I wonder what that could be. Since I get the MFA flow going and get the multipleauth in authnmethodsreferences then I must do something right. 

The end results is that our shibboleth returns NoAuthContext and I believe that it is because of the ADFS returning the right value in the wrong place.

> We've occasionally seen issues where the user has a pre-existing session 
> at the Azure IdP with some other (Kerberos based, I think) authn method 
>- the Azure IdP sometimes refuses to respond moaning about incompatible 
> methods.

-----Ursprungligt meddelande-----
Från: users <users-bounces at shibboleth.net> För Matthew Slowe via users
Skickat: den 21 oktober 2022 09:26
Till: users at shibboleth.net
Kopia: Matthew Slowe <matthew.slowe at jisc.ac.uk>
Ämne: Re: Shibboleth 4.2.x and ADFS/Azure

On 20/10/2022 14:30, Mårtensson, Roger via users wrote:
> Hej!
> 
> I’m am trying to implement REFEDS MFA using Shibboleth IDP v4.2 using 
> this url. (Shibboleth IDP SAML proxy to an ADFS  with MFA support)
> 
> https://shibboleth.atlassian.net/wiki/spaces/KB/pages/1467056889/Using+SAML+Proxying+in+the+Shibboleth+IdP+to+connect+with+Azure+AD <https://shibboleth.atlassian.net/wiki/spaces/KB/pages/1467056889/Using+SAML+Proxying+in+the+Shibboleth+IdP+to+connect+with+Azure+AD>
> 
> After some tweeking to get it working with our ADFS service I got it to 
> work.. almost.
> 
> I can login in, get the required MFA-input. The problems start after 
> successfully logged in.
> 
> It’s nothing new and I’ve found many references to it on the Web. ADFS 
> (and Azure) do not return the correct strings in the AuthnContext. It is 
> returned in a as an attribute(claim).

It (Azure AD IdP) seems to _always_ return the authn methods in an 
attribute (claim):

<Attribute 
Name="http://schemas.microsoft.com/claims/authnmethodsreferences">
 
<AttributeValue>http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password</AttributeValue>
 
<AttributeValue>http://schemas.microsoft.com/claims/multipleauthn</AttributeValue>
</Attribute>

but will only return the multipleauthn value as the (single valued?) 
AuthnContextClassRef when it's been specifically requested by the 
[proxying IDP] SP.

The note at the end of the howto will map the incoming REFEDS request 
and the outgoing response to/from "multipleauthn". Have you done both 
PrincipalProxyRequestMappings and PrincipalProxyResponseMappings parts 
and definitely enabled SAML2AuthnContextClassRef in the 
supportedPrincipals property? If so, is the REFEDS MFA profile 
definitely being requested by the target SP?

... or are you hoping to _always_ return the MFA AuthnContextClassRef if 
that's what was used upstream regardless of what the SP asked for?

We've occasionally seen issues where the user has a pre-existing session 
at the Azure IdP with some other (Kerberos based, I think) authn method 
- the Azure IdP sometimes refuses to respond moaning about incompatible 
methods.

Hope that helps,
-- 
Matthew Slowe [he/him] (GPG: 0x6BE0CF7D04600314)
Senior Technical Consultant and Support specialist, Jisc
Team: 01235 822185
Lumen House, Library Avenue, Harwell Oxford, Didcot, OX11 0SG