~Re: Storing persistentId using an HTTP DataConnector

[Peter Schober]

* spf via users <users at shibboleth.net> [2022-11-04 14:37]:
> As I was asked to provide high availability too, I need to use some
> kind of clustered database. Then I had the idea to try something
> else than MariaDB, say Rqlite we recently heard good things about
> from our devs. But no JDBC driver is provided, so I was trying to
> figure out if I could use another kind of DataSource.

I suspected rqlite was the reason for that question. ;)
While there's some basic Java code unfortunately noone has contributed
JDBC support yet, https://github.com/rqlite/rqlite-java/issues/15 

> As far I can see, some mechansime was setup to provide an
> "eduPersonTargetedID" attribute as persistentID, but I have no clues
> about any NameID.

A NameID of format "persistent" (section 8.3.7 in SAML Core, PDF p.86,
https://www.oasis-open.org/committees/download.php/56776/sstc-saml-core-errata-2.0-wd-07.pdf)
is what the (deprecated, see
https://wiki.refeds.org/display/STAN/eduPerson+2020-01#eduPerson202001-ChangeLog)
eduPersonTargetedID attribute requires for its value.

Some SPs will be able to make use of "proper" persistent NameIDs,
i.e. those sent in the Subject element of the SAML Assertion (the
standard place since SAML 2.0 came out in 2005 CE) instead of as
attribute values of the eduPersonTargetedID attribute.
You'd configure support for those using conf/saml-nameid.properties
and conf/saml-nameid.xml

> If I understand good, given a certain peer entity and a principal
> name, the algorithm behind ComputedIDs will always provide the same
> computed id if the salt is the same ?

Yes. Though it's function is more clearly described by focussing on
the fact that for the same principal (and salt) the values will differ
for each peer entity. ;)

> So maybe I have no need for a database stored persistentId ?

That certainly works and many are using it that way. The only thing
you lose without a database is the ability to make "changes", e.g.:
Computed value xyz123 was a some point issued for subject A but
subject A is now identified by a different principal name B. Using a
database you could map previously asserted (output) values to a
different input value. I.e., even though the userid for the subject
changed the resulting NameID does not.
Or you could "expire" previously asserted values so that if the same
principal name comes along now a different/new value would be
generated, e.g. when the (input) principal name was recycled is now
being used by a different subject/person. You'd need to make sure then
that the same input still produces a different output, as SAML core
mandates that "A given value, once associated with a principal, MUST
NOT be assigned to a different principal at any time in the future.")

Whether you actually *need* to support these use cases (re-mapping or
disabling of previously generated values) only you can know.
If you don't, well, you still need to decide whether or not you will
support thise going forward or not.

> The support team of one of the federations we are linked to told me
> about two attributes which could be relevant in the future and I
> added the configuration for them

Sure, those are the immediate (you can start using them right now) to
long-term (i.e., some services will take years to move over or will
never do) replacement for persistent NameIDs, eduPersonTargetedID,
eduPersonUniqueID and also (to some degree) eduPersonPrincipalName.

Also note that both SubjectID and PairwiseID come with the same
non-reassignment requirement as persistent NameIDs (see quote above).
So if you're re-assigning "uid" (which you seem to be using as basis
for SubjectID) you already have no database to "fix" algorithmmic
mappings from (uid) input to (SubjectID) output value.
Probably that means you won't need one for persistent NameIDs /
eduPersonTargetedIDs, either!

> Is it also possible to generate "eduPersonTargetedID" the same way
> (reusing the computed id) but with the same format as before, as a
> "EntityID!hPeerID!PersistentID" string ? I think this is what you
> call putting a NameID in an AttributeValue. Maybe it will not be
> useful in the future, but as some SPs I have seen in the federation
> require it, better provide it.

Sure, e.g.:

  <!-- Deprecated persistent NameID wrapped in a deprecated SAML Attribute value -->
  <AttributeDefinition id="eduPersonTargetedID" xsi:type="SAML2NameID" nameIdFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
    <InputDataConnector ref="computed" attributeNames="computedId" />
  </AttributeDefinition>

If you add this you'll also note the following warning in your logs:

  WARN [DEPRECATED:125] - xsi:type 'SAML2NameID', (file
  [/opt/shibboleth-idp/conf/attribute-resolver.xml]): This will be
  removed in the next major version of this software; replacement is (none)

Also, your old configuration will likely have been using
BASE64-encoded values and your new configuration would have to match
this for persistent NameIDs/eduPersonTargetedID in order to keep all
values the same.
But for new deployments BASE32-encoding is recommended.

So I'd suggest to define 2 different DataConnectors of type
ComputedId: Once with encoding="BASE64" (only to be used for your
legacy eduPersonTargetedID attribute support; you'd also set
idp.persistentId.encoding=BASE64 in conf/saml-nameid.properties if you
needed to support proper persistent NameIDs with those same old
values) and another one with encoding="BASE32" to be used as the basis
for your new PairwiseIDs.

HTH,
-peter