cantor.2 at osu.edu
Fri Feb 23 11:04:08 EST 2018
> 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.
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.
> I can't change the encoding in saml-nameid.properties to BASE32
> without killing all computed persistent NameIDs released to SPs.
Yes, that's a "it's just a problem, it's not like we can give people a great solution" situation, all we can do is get the code out there to support the fix. I was lucky, I only just had to add it here.
> 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.
> 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.
More information about the users