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.

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