 |
 |
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 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 >>>> >>> >>> >>> >>> >>> > >