[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] Changing AuthNSelfIssuedMaterials
|
The cardKeyHash is a claim? I thought it was just AuthN materials. I'd like clarification of the requirement ... THEN a use case.
Tom
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 02/07/07 10:31 AM >>>
Oh, we haven't seen/thought of this requirement yet -- can you give us the use case?
We would need a way for the catagorization string to be created while storing the value, and that string would need to be a fourth value fed into AuthNSelfIssuedMaterials by the STS.
>>> Anthony Nadalin <drsecure@xxxxxxxxxx> 2/7/07 8:24 AM >>>
No this value can be very very important to be read by REAL humans, please note that this value it self does not have to be human readable but there should be a human readable "friendly name" that one can display or use to categorize PPIDs with
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Jim Sermersheim" <jimse@xxxxxxxxxx>
"Jim Sermersheim" <jimse@xxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx
02/07/2007 09:12 AM Please respond to
"Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx>
To
"'Higgins (Trust Framework) Project developer discussions'" <higgins-dev@xxxxxxxxxxx>
cc
Subject
Re: [higgins-dev] Changing AuthNSelfIssuedMaterials
No, this particular value isn't meant to be read by humans --although as base64-encoded values go, this one tends to be pretty cute, so while not readable, it's not bad to gaze upon.
>>> Anthony Nadalin <drsecure@xxxxxxxxxx> 2/6/07 11:34 PM >>>
Its more than the issue about an LDAP server doesn't allow searching for a binary value, its about how we would also represent this for human readable consumption
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Jim Sermersheim" <jimse@xxxxxxxxxx>
"Jim Sermersheim" <jimse@xxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx
02/07/2007 12:03 AM
Please respond to
"Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx>
To
"'Higgins (Trust Framework) Project developer discussions'" <higgins-dev@xxxxxxxxxxx>
cc
Subject
[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_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
