SAML flow within MFA flow - possible c14n problem

[John Watt]

I am having some trouble with what I think may be c14n when using the SAML flow within an MFA flow. I have an MFA flow set as the only flow in idp.authn.flows which renders a selection screen that allows a user to select either the Password/LDAP flow (for a minority of users) or Azure through the SAML flow using buttons.  The SAML flow is working in "hybrid" mode, with Azure only sending the same value of MYUSERID in NameID and an additional attribute (internally, azureMailnickname) which I use for c14n/attribute, with our local LDAP doing the main attribute resolution post-authN based on this principal.

I've been trying to exploit the separate lifetimes of each constituent flow to control the number of times the selection screen appears based on the login method, the MFA flow script calls getActiveResults from the MFAContext to see if there is an existing result to use and terminates the flow at that point to reuse the result if it exists. This works fine at all times for the Password flow, after selecting the LDAP login, getResults() for AuthN and MFA contexts for the next service visit shows (MYUSERID is the unique identifier common across LDAP and Azure):

2022-09-09 10:56:09,177 - XX.XX.XX.XX - INFO [net.shibboleth.idp.attribute:5] - [MFA] AuthContext Results: {authn/MFA=AuthenticationResult{authenticationFlowId=authn/MFA, authenticatedPrincipal=MYUSERID, authenticationInstant=2022-09-09T09:56:05.221Z, lastActivityInstant=2022-09-09T09:56:05.221Z, previousResult=true}}
2022-09-09 10:56:09,178 - XX.XX.XX.XX - INFO [net.shibboleth.idp.attribute:6] - [MFA] MFAContext Results: {authn/Password=AuthenticationResult{authenticationFlowId=authn/Password, authenticatedPrincipal=MYUSERID, authenticationInstant=2022-09-09T09:56:05.216Z, lastActivityInstant=2022-09-09T09:56:05.221Z, previousResult=true}}

With the SAML flow it only seems to work in a cleared-cache browser up until the point the lifetime is reached (or Jetty is restarted). Then it gets stuck returning no results on this context query so the selection screen appears every time. getResults on the second service visit is quite different from the Password flow:

2022-09-09 11:11:23,723 - XX.XX.XX.XX - INFO [net.shibboleth.idp.attribute:5] - [MFA] AuthContext Results: {authn/MFA=AuthenticationResult{authenticationFlowId=authn/MFA, authenticatedPrincipal=authn/SAML, authenticationInstant=2022-09-09T10:11:18.590Z, lastActivityInstant=2022-09-09T10:11:18.590Z, previousResult=true}}
2022-09-09 11:11:23,724 - XX.XX.XX.XX - INFO [net.shibboleth.idp.attribute:6] - [MFA] MFAContext Results: {authn/SAML=AuthenticationResult{authenticationFlowId=authn/SAML, authenticatedPrincipal=<?xml version="1.0" encoding="UTF-8"?><saml2:NameID xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">MYUSERID</saml2:NameID>, authenticationInstant=2022-09-09T10:11:18.249Z, lastActivityInstant=2022-09-09T10:11:18.590Z, previousResult=true}}

So MYUSERID appears, based on the surrounding XML, to be coming from the NameID even though I have c14n/attribute (and properties) set according to the docs and c14n/SAML2ProxyTransform commented out. The logs hint that the principal is extracted from the c14n/attribute, and attribute resolution is always fine afterwards. Also, "authn/SAML" as the authenticatedPrincipal in the AuthContext feels wrong to me!

Am I missing something additional to set the authenticatedPrincipal of the SAML flow with the c14n/attribute result within the MFA flow script (or the fairly lightweight selection page), or does this look like a general c14n or SAML flow misconfiguration? (or maybe what I'm seeing is expected and I'll need to rethink the MFA script).

Thanks in advance, this list was a great help in getting this set up in the first place!

Thanks,
John


----------------------------------------------------------------------

Dr. John Watt

IT Services, Room 1006, Library

University of Glasgow, Glasgow G12 8QQ

T 0141 330 8647 | M 07545 500579

The University of Glasgow, charity number SC004401
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20220909/f12aa41d/attachment.htm>