Shibboleth IdP 4, SAML proxying and SimpleSAMLphp proxy breakage?

Peter Schober peter.schober at univie.ac.at
Tue Feb 23 16:54:50 UTC 2021


* Robert Bradley <robert.bradley at it.ox.ac.uk> [2021-02-23 16:50]:
> I'm not sure if this is a bug in upstream SimpleSAMLphp or simply an issue
> with the GÉANT SAML proxy, but I thought it would be worth noting here in
> case anyone else running Shibboleth IdPs with Azure AD for authentication
> runs into similar issues.

FWIW, the way those attributes are constructed suggests use of the
"SmartID" authproc filter (a bit like the Shib SP's REMOTE_USER
precedence list), with its somewhat weird default of
add_candidate == True, i.e., it adds the /name/ of the used attribute
to the resulting /value/ string of the generated attribute:
https://simplesamlphp.org/docs/stable/smartattributes:smartattributes
Code at
https://github.com/simplesamlphp/simplesamlphp-module-smartattributes/blob/master/lib/Auth/Process/SmartID.php

> However, the proxy IdP in this case appears to ignore the issuer
> entirely and uses the first <AuthenticatingAuthority> element to
> generate the "eptid" attribute, i.e.
> "eduPersonTargetedID:${eduPersonTargetedID}!${AzureIdPEntityID}".
> This looks like broken behaviour to me.

The value of an eduPersonTargetedID attribute (and hence of the
"eptid" attribute) in SSP would have come from use of the
saml:NameIDAttribute authproc filter:
https://simplesamlphp.org/docs/stable/saml:nameidattribute
Code at
https://github.com/simplesamlphp/simplesamlphp/blob/master/modules/saml/lib/Auth/Process/NameIDAttribute.php

You'd have to go quite a bit deeper to find the source(s) of the data,
though, I think you'd find it in the simplesamlphp/saml2 repo, maybe
https://github.com/simplesamlphp/saml2/blob/master/src/SAML2/XML/saml/AuthnContext.php

Make sure to report this to the SSP mailing list or issue tracker.

-peter


More information about the users mailing list