PersistentNameIDGenerationConfiguration: Type 4 UUID

[Peter Schober]

* Hugo Slavia <hugoslavia101 at gmail.com> [2018-01-24 02:32]:
> However, per an org decision, we need the Stored IDs in UUID v4
> ----- how best to create UUID 4 type Stored IDs going forward --
> i.e. new user authenticated to Goggle; subsequent Stored ID for the
> user is UUID v4 (not base64)?

The IDP already generates them that way (type 4 UUIDs) *if* they are
not the first value for a given principal and relying party. That's
the migration tool Scott mentioned.

See this quote from the old IDPv2 docs:

  "This connector creates and persists unique identifiers. The first
  ID created for a given requester is always the same as those created
  by the computed ID data connector in order to provide a migration
  path from that data connector. Every subsequently generated ID for a
  given user/IdP/SP triple, if the first one is revoked, is a Type 4
  UUID."
  https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverStoredIDDataConnector

AFAIR there is (or was) a setting to disable the generation of the
old-style values and jump straight to generating new values, even if
no prior value existed and was revoked/expired, at least in IDPv2.

*But* the resulting NameID string value is /not/ a type4 UUID itself,
because those would be randrom (as per the spec), whereas a NameID
string value is produced from hashting it together with a salt and
with the name qualifiers.

Also I don't see the relevance for an existing deployment with
persisted existing NameID values that might be in use at federated
services as primary key for a subject -- would you re-key all subjects
(and risk breaking their access or access to their data at federated
services services) simply to satisfy a (nonsensical, AFAICT)
management request how a software should store opaque (!) data
internally?

-peter