Attribute Registry vs Attribute Resolver - best practice?

[Mark Cairney]

Hi,

We're now looking at moving our IdP from being standalone (behind a 
REMOTE_USER variable for authentication) to using the new SAML proxy 
functionality provided in V4+.

Having gone through the procedure on our Dev IdP it seems to me like 
using the attribute-registry.xml is the documented method for handling 
attributes coming upstream from Azure AD. [1],[2]

To do this without changing how I handle the existing attributes getting 
looked up from LDAP I uncommented the 
'shibboleth.AttributeRegistryResources' block in services.xml but in 
attributes/default-rules.xml I've commented out everything except the 
new azureClaims.xml file e.g.

<!-- Comment out everything but the additional azureClaims.xml -->

<!--    <import resource="inetOrgPerson.xml" />
     <import resource="eduPerson.xml" />
     <import resource="eduCourse.xml" />
     <import resource="samlSubject.xml" /> -->
     <import resource="azureClaims.xml" />


Is this a sensible approach for systems that have been upgraded from V3 
->V4 ->V5 and will there any issues going forward? My 
attribute-resolver.xml is relatively standard but does have some custom 
mappings for handing Windows-style claims (pre-Azure integration) and 
some mapped attributes for eduGAIN assurance purposes.


[1] 
https://shibboleth.atlassian.net/wiki/spaces/KB/pages/1467056889/Using+SAML+Proxying+in+the+V4+Shibboleth+IdP+to+connect+with+Azure+AD

[2] 
https://shibboleth.atlassian.net/wiki/spaces/KB/pages/2783936889/SAML+Proxying+EntraID+Azure+with+the+Shibboleth+IdP

-- 
/****************************

Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh

Tel: 0131 650 6565
Email: Mark.Cairney at ed.ac.uk

*******************************/

The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.