| [higgins-dev] Changing AuthNSelfIssuedMaterials |
|
The current implementation of this takes a single byte[] value and assumes the attribute name is http://www.eclipse.org/higgins/ontologies/2006/higgins#cardKey
The caller had to build this byte[] by concatenating (from values in the RST) the ppid, public key modulus, and public key exponent.
The way the LDAP CP implemented this was to simply search for that value, and if a single identity is found then that was the point of authentication.
It turns out that at least one LDAP server doesn't allow searching for a binary value (which is what the byte[] caused to be in the search filter), so we had to re-think our implementation.
After long deliberations, we decided it would be best to make this authN materials be more abstract, and built using the constituent data parts that make up the materials (ppid, public key modulus, and public key exponent). This way the underlying CP can do what's right in terms of it's backing store (we shouldn't write the contract between the CP and it's backing store.
So, we're proposing to make AuthNSelfIssuedMaterials be made up of these three parts, and the LDAP CP can store and search for the concatenated value as a base64 string.
The next step (on the subject of proper abstraction) would be to introduce an analogous abstraction for the updating of authN materials. Because we allow any object to be used as authN materials during context.open, it makes sense to provide an API which can be used to set/update those authN materials. Previously, I had thought it would be "good enough" to make IdAS consumers use traditional attribute update methods, but it's clear now that this is insufficient. Some AuthN materials may have a completely different, or even no representation as attributes in the store, and it may be impossible to even represent them as attributes such that traditional attribute update methods may be used. Plus, introducing an the authN materials update mechanism decouples the IdAS consumer from any intimate knowledge of how any CP implements support for any given AuthN materials.
I'm not proposing to check in anything yet for this next step right now, just the changes that will allow us to switch to using strings on the back-end store.
We've already done the first part locally and integrated the three relevant components (STS, IdAS, LDAP CP), we just haven't committed anything yet.
Jim
|