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]