But once we move to ABFAB there is a standard way of exposing a local
user identifier attribute to the RP, through a SAML attribute carried in
the Radius attribute. So this can be written up as the standard way of
uniquely identifying the user, without defining the actual attribute
type. Different communities can profile this method by defining the
attribute type they will use in their federation or community.
regards
David
On 28/02/2014 15:03, Cantor, Scott wrote:
> On 2/28/14, 8:11 AM, "David Chadwick" <[log in to unmask]> wrote:
>
>> Isnt there a much simpler solution as follows, which is essentially
>> outside the scope of ABFAB:
>>
>> the IDP returns an identifier attribute for the end user as part of
>> the SAML attribute assertion - this could be email address, EPPN,
>> mobile phone number or anything else that can be used as a correlation
>> handle between the remote IDP and the SP's local LDAP entries - and
>> when the SP gets this attribute, it simply makes a local LDAP call to
>> retrieve additional attributes of the user who has this uniquely
>> identifying attribute in its entry.
>
> Yes, which is exactly what I originally posted.
>
> However, that doesn't fix the real problem: there is no standard way to
> expose a local user identity that isn't the GSS *name* to an application,
> thus making every application a custom hack. That needs to be fixed, or
> GSS is not sufficiently standardized for federated application use.
>
> -- Scott
>
>
>
|