On 30 May 2014, at 16:14, Sam Hartman <[log in to unmask]> wrote:
> Looks like a conclusion to me.
> Shall I allocate these from the dict.ukerna space?
During a discussion that Josh, Stefan and I had last week we talked about adding one more into the mix, giving us four levels of targeted ID.
* moonshot-service-targetedid (targeted at a GSS-Acceptor-Service-Name)
* moonshot-host-targetedid (targeted at a GSS-Host-Name, which may contain multiple GSS Services)
* moonshot-realm-targetedid (targeted at a GSS-Realm, which may contain multiple GSS Hostnames)
* moonshot-tr-coi-targetedid (targeted at a Trust Router CoI, which may contain multiple GSS Realms).
So yes, Sam, if you can allocate those in the dict.ukerna space that would be great.
Each of those would be specified simply as a unique, persistent, opaque identifier per user per {whatever level the identifier is targeted at} and when transported over AAA represented as value@idp-realm, thus an NAI. If transported over SAML, then some representation which includes an identifier for the type of persistent identifier that it happens to be to allow for bi-directional transformation between AAA and SAML representations.
One question, Sam - how could one programatically access the CoI name at runtime? If this isn’t something exposed in FR yet, could it be? That’s going to be somewhat necessary for computing the moonshot-tr-coi-targetedid.
In terms of a practical implementation of this, what I’m thinking of doing currently would be as follows (I’m going to try to get a FR mod written (based off of the CUI module as a starting point) when I get a chance to do this in the next couple of weeks):
* Identifiers will be RFC4122 compliant UUIDs, with @idp-realm tacked on.
* Recommended deployment option: Stored identifier. Creates a type 5 UUID (i.e. SHA1 hash based) initially and store in database. Allows for easy linkage back to user by IdP, revocation, etc. After first revocation, instead creates a type 4 UUID (i.e. random) -. Reason for the initial value being type 5 and subsequent being type 4 is so that those who start with the computed option (see next) but later on want to switch to the stored option can do so without the identifiers changing wholesale on switchover.
* Optional for those who don’t want to to do the stored thing: Computed identifier. Creates a type 5 UUID (SHA1 hash based) in a JIT manner.
* Type 5 UUIDs hash together a namespace (UUID) along with a name (string). I’d create four UUIDs that represent the four Moonshot identifiers for the namespaces. The name would be (username + salt + {GSS-Acceptor-Service-Name / GSS-Host-Name / GSS-Realm / CoI Name}).
Can anyone see anything I’m missing?
Rhys.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet, the UK's research and education network
email: [log in to unmask] / [log in to unmask]
GPG: 0x4638C985
