El 28/02/14 17:07, David Chadwick escribió:
> I thought the context was about aggregating attributes from the remote
> IDP with locally held RP ones. So both will (indirectly) contact their
> local LDAP directories
ok, but this scenario aggregates more complexity because, as you says,
RP needs to map received attributes with local ones.
Personally I prefer to clarify (probably to myself) the scenario where
RP receives the attribute (i.e. eduPerson:entitlement:professor) and the
RP is able to allow or deny access based on some kind of simple
authorization policy (if user coming from @um.es and he is a professor,
then give access).
Obviously RP and idP must agree on the use of the eduPerson schema's
types and values.
Regards, Gabi.
>
> David
>
> On 28/02/2014 16:02, Gabriel López wrote:
>> 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]
|