On 22 May 2014, at 19:15, Sam Hartman <[log in to unmask]> wrote:
> I think for RADIUS, separate attributes will fit their model better.
> But this is something to consider.
So we have two options for an opaque identifier:
1) The two attribute option:
a) moonshot-realm-targetedid. Value a hash of Gss-Acceptor-Realm, NAI, salt. Representation: [log in to unmask] e.g. [log in to unmask]
b) moonshot-tr-coi-targetedid. Value a hash of CoI-Identifier, NAI, salt. Represented as [log in to unmask] e.g. [log in to unmask]
IdPs would release coi-based, or realm-based, or neither, based on policy. Could release both, of course, though not sure what the point of that would be.
or 2) SAML persistant-id-alike single attribute:
a) moonshot-targetedid. Value a hash of Gss-Acceptor-Realm OR CoI-Identifier, NAI,salt. Represented as {idp-realm}!{audience}!{value}.
e.g. when the audience is the CoI - camford.ac.uk!pilot.communities.moonshot.ja.net!asdfghjkl
e.g. when the audience is a gss-acceptor-realm - camford.ac.uk!someservicerealm.com!asdfghjkl
IdPs would release it or not, and choose which option to use, based on policy.
Some considerations that spring to mind:
In the first (two attribute) case:
* recipients would check User-Name, then moonshot-tr-coi-targetedid, then moonshot-realm-targetedid, otherwise anonymous. More complex logic (more attributes to iterate through), but whether the ID is targeted at the CoI or at the realm is very explicit and easy to figure out.
* Representation matches the way RADIUS normally does things.
* IdPs have a simple attribute definition which generates the values for both attributes, and the policy lives at the point of release - which CoIs get to see the coi-targetedid, and which don’t. Those that don’t just get to see realm-targetedid, or nothing.
In the second (one attribute) case:
* recipients would check User-Name, then moonshot-targetedid, otherwise anonymous. Simpler logic, but if you want to know whether you have an ID that is targeted at the CoI or at your realm, you have to do some work looking at the audience value to figure that out.
* Representation matches the way SAML normally does things.
* IdPs have a more complex attribute definition as the policy now lives on the point of attribute creation, but the release policy is probably simpler (either release it or nothing).
Also, if we’re then going to use these identifiers as a nameid when sending subsequent SAML assertion requests (as per what Josh said), in the first case we either have to define our own custom SAML name id format, or convert from the RADIUS representation to the SAML triple and use the persistent name-id format. In the second case we could just use it directly. (All potentially subject to mapping AAA names to SAML names? I’m still not clear on that bit of the puzzle yet...).
Are there any other considerations or reasons to use one option over the other?
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
|