PersistentNameIDGenerationConfiguration

[Peter Schober]

* Cantor, Scott <cantor.2 at osu.edu> [2018-02-23 17:05]:
> > Indeed. Wrt generation strategies (and capturing this thread a bit):
> > Is there a way to generate valid pairwiseIDs (per the new OASIS
> > Attribute Profile) using the Computed strategy, while at the same time
> > keeping support for existing "computed" persistent NameIDs?
> 
> You mean having multiple discrete computed IDs? Undoubtedly, but the
> wiring that's built in may make that troublesome without referencing
> some impl classes. It wasn't baked into the default wiring that's
> hiding all the details and tunneling the properties into the config.

Yeah. I'm not in any hurry to implement support for pairwise but had
begun to tease out how this would work in an IDP with existing support
for persistent NameIDs. (My own toy IDP uses storedIDs but with the
default strategy generating identical values to the "computed" ones,
meaning unless I actually have to revoke or remap an ID I can lose or
truncate the entire DB at any time without losing something.)

> Doing two separate things in the NameID generation config and the
> attribute resolver (the latter of which will essentially be back to
> necessary to make the pairwise-id Atribute work) is certainly *a*
> way, so that might be the simplest answer for the moment. It's
> shared code, but it's separate in a Java object sense at runtime,
> they're really not connected at all.

That's what I was looking into.

> > I can't add a definition for pairwise to the attribute resolver (using
> > the ComputedId type DataConnector, v2-style, and a Scoped attribute
> > definition) as the old strategy doesn't satisfy the syntactic
> > requirements of the new attribute.
> 
> Not sure I follow. The computed strategy in either place using
> base32 encoding should be legal. We explicitly made base64 not legal
> of course.

Yeah but I can't change the encoding to 32 without changing the values
being computed (ignore that I actually persist values in an RDBMS for
the sake of the argument; most of our deployes don't persist them, if
they even support persistent NameIDs) and released in the wild, too,
unless I'm misunderstanding.

> > For (omni-directional) subjectID itself I'm currently creating salted
> > sha256 hashes in a ScriptedAttribute attribute definition. I guess I
> > could do the same for pairwise but would have to dig deeper to also
> > get the SP's entityID from the context tree to put into the hash.
> 
> Not hard to do of course, but I'm not sure I understand the
> concern. If the computed ID code isn't "right" somehow, we have a
> bug I think.

Maybe I haven't been clear. I use sourceAttribute and salt in
saml-nameid.properties and uncomment the generator in the XML.
idp.persistentId.computed uses the default
ComputedPersistentIdGenerator, so backwards-compatible values, which
are deployed and in use in the wild.
Those values are base64 and contain characters not legal for
SubjectID/PairwiseID.

So in order to keep those (and persistent NameIDs) unmodified I had
the impression the easiest way to also support Pairwise was by doing
it in the resolver. Just using a DataConector like below (and pulling
into a Scoped attr def) would simply re-create the same values (als
LHS of a scoped attribute) I use for persistent NameIDs but those are
not legal for Pairwise:

  <DataConnector id="computedID" xsi:type="ComputedId" generatedAttributeID="computedID"
    sourceAttributeID="%{idp.persistentId.sourceAttribute}" salt="%{idp.persistentId.salt}">
    <Dependency ref="whereverSourceAttrComesFrom" />
  </DataConnector>

Is there simply another type I should be using? Otherwise I see no
alternative to scripting the whole thing from scratch, by hashing the
3-tuple myself.

-peter