El 28/02/14 14:11, David Chadwick escribió:
> 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.
Well, I think we are talking about different scenarios.
In your case the SP (or RP) requests an LDAP for attributes.
In my case, the SP receives the end user attributes through the radius
channel, and the idP/AAA is the entity requesting the LDAP.
Is that right?
There is quite a difference when SP and idP belongs to different
organizations.
>
> regards
>
> David
>
> On 28/02/2014 11:47, Gabriel López wrote:
>>
>> Hi,
>>
>> El 26/02/14 16:31, Cantor, Scott escribió:
>>> On 2/26/14, 7:45 AM, "Sami Silén" <[log in to unmask]> wrote:
>>>>
>>>> And yes your thoughts were helpful even it raises many
>>>> questions, should we really consider other ways than eppn.
>>>> Currently eppn just is the only feasible attribute available
>>>> for mapping.
>>>
>>> I would note that the Shibboleth SP can query a second Attribute
>>> Authority using SAML using any attribute you want to build on top
>>> of, so you don't have to link using EPPN if you prefer to use
>>> something else, and you have some kind of web-based portal to
>>> establish the link.
>>>
>>> With respect to a local LDAP, obviously you could stand up a
>>> Shibboleth IdP or other AA implementation to front-end the LDAP
>>> for SAML queries, or alternatively somebody is welcome to build a
>>> resolver plugin for the SP that just does LDAP natively without
>>> the SAML in between. I am not fluent in LDAP, nor do I have any
>>> idea what LDAP library would be the best option to use, or I
>>> would have done one at some point. I'm happy to maintain it going
>>> forward if it's contributed by somebody else.
>>>
>>
>>
>> I have some doubts regarding this workflow.
>>
>> Two models are described in draft-abfab-aaa-saml:
>>
>> 1) RP is able to play the role of a SAMLRequester entity 2) RP does
>> not play the role of a SAMLRequester entity, but it is able to
>> understand and manage a SAML assertion generated by the home
>> radius(idp) once the end user is authenticated. (currently
>> implemented version)
>>
>> The draft points out that if the RP issues an authentication
>> request (SAMLAuthRequest) to the idp, this request must not include
>> a Subject element (to identity the end user). And the idP must make
>> use of the inner RADIUS end user identity (UserName), used to
>> authenticate him, in order to identity the end user associated with
>> the SAMLauthRequest. However, it is not clear for me (maybe I
>> missed something) what value (if applicable) must be present in the
>> Subject element of the SAMLAuthnSt. assertion to be sent back to
>> the RP. Obviously if the idp includes the UserName value then the
>> idp is revealing the end user identity to the RP, which is not
>> desired.
>>
>> The case of an Attribute request it is not explicitly described in
>> the draft. I guess that if the RP issues an SAMLAttributeQuery,
>> this sentences must not include the end user id in the Subject
>> (following the same rules described for the authn request). Again,
>> in this case, the idP must make use of the RADIUS end user identity
>> to obtain the end user attributes and construct the saml attribute
>> statement. As before, it is not clear for me what value (if
>> applicable) must be present in the Subject element of the assertion
>> to be sent back to the RP.
>>
>> Supposing the above text is right. Then the home radius can follow
>> one of the following approaches:
>>
>> a) home radius obtains end user attributes (making use of the
>> RADIUS UserName) from LDAP/DDBB/internal and constructs the
>> SAMLAttributeSt assertion. Home radius server can generate the
>> Subject element (if applicable) to be included in the assertion.
>> Could the home radius use a CUI value like the value of the Subject
>> element?
>>
>> b) home radius queries (AttributeQuery) a new SAMLAttributeSt
>> assertion to a local idp (Shibboleth, simpleSAMLphp, etc.
>> (following something similar to the Roland approach). In this case
>> this query should include the RADIUS UserName to allow the local
>> idp to recognize the end user identity and the associated
>> attributes. Regarding the SAMLAttributeSt assertion generated by
>> the local idp more questions arise. Could the idp make use of a
>> transient-id value in the Subject element of the assertion? (if
>> requested in the query) The home radius receiving that assertion
>> must forward it to the RP (both in 1) and 2)). Could this
>> transient-id be considered a CUI value? (in order to allow the RP
>> to associate the receiving attribute with the right end user)
>>
>> In this case (b), regarding the SAMLAttributeSt assertion, we found
>> that the local idp had to include an Audience Condition element to
>> allow the home radius to manage the assertion, but I'm not sure if
>> it is something related with Shibboleth, or a general SAML issue.
>>
>> Finally, regarding the attribute release policies, in a) this
>> policy should be managed by the home radius (i.e. XAML, etc.).
>>
>> That's all, sorry for this long email.
>>
>> Regards, Gabi.
>>
>>
>>
>>
>>> -- Scott
>>>
>>
>>
>>
>>
>>
--
--------------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [log in to unmask]
|