Shib v4 hybrid proxying via Azure AD

[Nate Klingenstein]

Patrick,

I haven't yet done this with Azure specifically, but you'll want to compare this complete list of attributes available to the proxy engine:

> 2021-03-01 12:37:13,960 - 143.200.128.40 - INFO [Shibboleth-Audit.SSO:282] - 143.200.128.40||2021-03-01T18:37:13.960349500Z||https://sts.windows.net/7fc34f9d-1f75-4f96-b5b3-3cdcxxxxxxxx/|_d92d198a-ea74-4517-babe-37533dae0200|password|2021-03-01T18:37:04.031Z|azureObjectidentifier,azureIdentityprovider,azureGivenname,azureAuthnmethodsreferences,azureDisplayname,azureTenantid,azureEmailaddress,azureSurname|samltest@uwgb.edu|emailAddress||false||Redirect|POST||Success|||Mozilla/5.0
 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.190 Safari/537.36

to the attributes that you have configured for resolution and usage in /conf/c14n/attribute-sourced-subject-c14n-config.xml as well as the attribute resolver.

It's failing to find a canonical Subject name from whatever you've got; azureName is conspicuously absent.  I don't think you could pull in pieces of a name from the upstream IdP, assemble them in another attribute, and then use that for Subject canonicalization, since you need that Subject in the first place to pull any Subject Derived attributes from it.

I would make azureObjectidentifier or azureEmailaddress the Subject for canonicalization, but then make the LDAP search filter use the compound generated attribute to pull from your local data stores.

> 2021-03-01 12:37:13,975 - 143.200.128.40 - ERROR [net.shibboleth.idp.authn.impl.SelectSubjectCanonicalizationFlow:78] - Profile Action SelectSubjectCanonicalizationFlow: No potential flows left to choose
 from, canonicalization will fail

Know that this will all change considerably when 4.1 is released.

Hope this helps,
Nate.