* Jon D Rodder <
jlu...@gmail.com> [2017-09-22 21:51]:
> What's the proper way to base64 encode an attribute being used as NameID
> for an SP (n saml20-sp-remote.php)?
Usually you don't. Unless the value you're using must be encoded
(e.g. because it's binary), as is the case with your attribute, it
seems.
> 'authproc' => array(
> 20 => array(
> 'class' => 'core:PHP',
> 'code' => '
> $guid = $attributes["mS-DS-ConsistencyGuid"][0];
> $attributes["NameID"] = array(base64_encode($guid));
> ',
> ),
> 30 => array(
> 'class' => 'saml:AttributeNameID',
> 'attribute' => 'NameID',
> 'Format' => 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
> ),
It it works it works. But note the first sentence from the SAML spec
about persistent NameIDs:
"Indicates that the content of the element is a persistent opaque
identifier for a principal that is specific to an identity provider
and a service provider or affiliation of service providers. "
SAML core, 8.3.7,
https://www.oasis-open.org/committees/download.php/56776/sstc-saml-core-errata-2.0-wd-07.pdf
I.e., the value should be different for each SP accesses, from the
same IDP and for the same subject. So the above is not really an
appropriate value for SAML2.0 persistent NameIDs.
The Shibboleth wiki also has this to say on the matter:
"It should also be technology-neutral; using a GUID generated by an
Active Directory is a very bad choice that will lead to problems if
you ever change directories."
https://wiki.shibboleth.net/confluence/display/IDP30/PersistentNameIDGenerationConfiguration
All directory-maintained values have this issue, incl. e.g. entryUUID,
which will be recreated (with a different value) when the object is
deleted and created again (e.g. because of a mistake in the IDM system,
or human error).
-peter