shibboleth.SAML2PersistentGenerator question

[Peter Schober]

* Les LaCroix via users <users at shibboleth.net> [2021-02-20 01:27]:
> I have verified that saml-nameid.properties contains the same values
> for idp.persistentId.sourceAttribute, idp.persistentId.algorithm,
> and idp.persistentId.salt, and that the bean reference for
> shibboleth.SAML2PersistentGenerator is present (not commented out).  I even
> tried adding "idp.persistentId.encoding = BASE64" to
> saml-nameid.properties, even though the newly generated value looked to be
> base64 anyway (contained both upper and lower case).

IDPv4 comes with "idp.persistentId.encoding = BASE32" set in
conf/saml-nameid.properties so the only explanation I'd have for the
new code to be using BASE64 without you setting this anywhere yourself
would be when using previously stored/persisted values.
But then you said "newly generated value" so that doesn't apply here
either.
Still, what is idp.persistentId.generator set to in both your old and
new systems?

> my SAML2PersistentGenerator nameid generator isn't producing the
> same results as reported by aacli.sh.

Are you saying calling aacli for a given subject and entityID produces
different persistent NameID values on the command line from those the
IDP releases for that same subject to the same SP -- and based on
what, the IDP's audit log? During transmission (in the
browser, assuming unencrypted Assertion/Reponse)? From the SP-side?

> I also added the source attribute to the filter for the relying
> party I'm testing against, and verified that it has the value I
> expect.

You may have done this solely for debugging purposes but I'll still
note that releasing the source attribute for a persistent NameID is
neither required or suggested: Doing this totally undermines the
purpose of generating and releasing only derived, opaque, SP-specific
values to the SP.

-peter