My bad, there was a later email. Everything is better explained in that
one, so please forget my question.
Regards,
Alejandro
El 10/02/16 a las 13:13, Alejandro Pérez Méndez escribió:
> In the last email from Rhys about these identifiers that I've been
> able to find, they are defined as:
>
> 1) AAA attribute of moonshot-service-targetedid.
> * A persistent identifier per user, per service
> * Value a hash of Gss-Acceptor-Service-Name, NAI, salt.
> * Representation: [log in to unmask] [log in to unmask]
>
> 2) AAA attribute of moonshot-realm-targetedid.
> * A persistent identifier per user, common across all services within
> a particular RP realm
> * Value a hash of Gss-Acceptor-Realm-Name, NAI, salt.
> * Representation: [log in to unmask] [log in to unmask]
>
> 3) AAA attribute of moonshot-tr-coi-targetedid.
> * A persistent identifier per user, common across all services within
> a particular COI.
> * Value a hash of CoI-Identifier, NAI, salt.
> * Represented as [log in to unmask] [log in to unmask]
>
>
> Although, for option 1, the value of Gss-Acceptor-Service-Name seems
> that might not be unique if Gss-Acceptor-Host-Name is not
> concatenated. For instance, when using mod_auth_gssapi,
> Gss-Acceptor-Service-Name would be just "HTTP", shared amongst every
> Moonshot-enabled HTTP server.
>
> If I'm right, then I guess 1) should actually be something like:
>
> * Value a hash of Gss-Acceptor-Service-Name, Gss-Acceptor-Host-Name,
> NAI, salt.
>
> Regards,
> Alejandro
>
>
>
> El 09/02/16 a las 19:28, Sam Hartman escribió:
>>>>>>> "Alejandro" == Alejandro Pérez Méndez <[log in to unmask]> writes:
>> Alejandro> El 09/02/16 a las 16:13, Sam Hartman escribió:
>> >>>>>>> "Alejandro" == Alejandro Pérez Méndez <[log in to unmask]> writes:
>> >>> If not, they should be done on the IdP and then released. It is
>> >>> then up to the Moonshot RP Proxy to do something with them.
>> Alejandro> Since they are representing the end user's identity, I
>> Alejandro> was expecting that it would be somehow the identifier
>> Alejandro> passed to the Application, instead of the useless
>> Alejandro> "@realm" anonymous identifier. Ej. if scoped ID is
>> found
>> Alejandro> by the mech_eap, use that as the name exported by the
>> Alejandro> GSS-API layer, overriding the value of the User-Name
>> Alejandro> attribute. In this way, legacy GSS-API applications that
>> Alejandro> do not ask for additinal naming attributes might work
>> Alejandro> with these pseudonyms in a transparent way. Nonetheless,
>> Alejandro> updated applications might scan for the presence of
>> these
>> Alejandro> identifiers and use them. But, as said, they need to
>> know
>> Alejandro> they are being used. Regards, Alejandro
>> >>
>> >> I don't think it would be a great idea for mech_eap to do
>> this by
>> >> default. Those IDs are I think fairly scoped to the
>> >> education/research community and mech_eap tries to be broader.
>> >> If I were deploying, I'd do what Stefan says and remap to
>> >> username in the RP proxy if that's what my application needed.
>>
>> Alejandro> That's doable, right.
>>
>> Yes. If an RP proxy sends back a username in the reply, that will be
>> used.
>
|