Fun with proxying to AzureAD

[Jeffrey Williams]

We've been proxying to Azure for a bit and are handling REFEDS MFA requests
with it as well.  I put the code snippet we use in the How-To article:

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

It's the same mechanism Tony described, but using values that'll have
meaning in Azure.

-Jeff

On Mon, Jun 7, 2021 at 3:29 PM mat houser <mhouser at uwm.edu> wrote:

> It looks like the initial thing that breaks is that AzureAD doesn't
> recognize the https://refeds.org/profile/mfa context as a valid
> authentication method at all. Error text is:
>
> AADSTS50130: The claim value(s) 'https://refeds.org/profile/mfa' cannot
> be interpreted as known auth method(s).
>
> I'm not entirely sure what the potentially known auth methods are in the
> Azure tenant, since I only have access to the Shib IdP. I can verify
> that putting the MFA profile in the ignored contexts will at least allow
> the user to authenticate successfully, but the response will of course
> just have the Password context.
>
> I'm prototyping this in 4.1 at the moment, and it looks like some of how
> that would be handled is different now, but that definitely gives me a
> better sense of what to look for.
>
> Thank you!
>
> -mat
>
> --
> -------------
> mat:houser
> mhouser at uwm.edu
> uwm:uits:iam-support
> -------------
>
> On Mon, 7 Jun 2021, Tony Skalski via users wrote:
>
> Are you referring to the fact that the SP is requesting the
> https://refeds.org/profile/mfa AuthnContextClassRef but Azure is returning
> something like "urn:oasis:names:tc:SAML:2.0:ac:classes:Password"?
>
> I dealt with a similar situation with proxying to Google - whose IdP only
> returns "urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified". See my email
> to the list from Feb 24 subject: "addDefaultPrincipals vs
> PrincipalProxyResponseMappings". I solved it by adjusting
> the PrincipalProxyResponseMappings in conf/authn/authn-comparison.xml -
> basically telling the IdP
> that urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified is as good
> as urn:oasis:names:tc:SAML:2.0:ac:classes:Password.
>
> If there is a way to get Azure to implement https://refeds.org/profile/mfa
> that would be preferable. IIRC someone on one of the Shib NIH MFA calls
> mentioned that Microsoft was working on this, but I could be misremembering
> things. My solution is not optimal as it somewhat misrepresents the
> authentication (in our case MFA is enforced by Google for all accounts),
> but I had no hope that Google was going to fix it anytime soon.
>
> ajs
>
> On Fri, Jun 4, 2021 at 2:45 PM mat houser <mhouser at uwm.edu> wrote:
>
> > Hello all,
> >
> > We're working on proxying our Shib IdP to Azure mostly to get our
> > student population enrolled in an MFA solution. Everything appears to be
> > working properly except for the https://refeds.org/profile/mfa business
> > breaking things when the user hits the Azure login page.
> >
> > I saw that there was a thread around January on this topic, but is there
> > any documentation around on what we would need to do to proxy requests
> > from SPs that are requiring the MFA context, or does anybody have any
> > examples of how other institutions have addressed this issue?
> >
> > Thanks in advance,
> >
> > -Mat
> >
> > --
> > -------------
> > mat:houser
> > mhouser at uwm.edu
> > uwm:uits:iam-support
> > -------------
> > --
> > For Consortium Member technical support, see
> > https://wiki.shibboleth.net/confluence/x/coFAAg
> > To unsubscribe from this list send an email to
> > users-unsubscribe at shibboleth.net
> >
>
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>


-- 
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/20210607/1188d852/attachment.htm>