On 05/02/13 17:33, Josh Howlett wrote:
> Jim has previously articulated a requirement for support of
> post-authentication attribute request, and to allow requests for
> attributes of the user and/or machine associated with the authentication.
> In a call before Christmas, Scott suggested a strategy based on the use of
> SAML Subject Confirmation.
>
> The idea is that the SAML Requester can use an attribute request using a
> new SAML Subject Confirmation Method. This Method gives (1) the value of
> the RADIUS State attribute pointing to the RADIUS session in question and
Do we have to take into account the scenario where the idP is not
co-located with the Radius server?
In this case this method is not valid.
> (2) whether the response should include attributes describing the user or
> machine.
Using the current SAML AttributeQuery element the client can specify the
list of desired attributes. Is it not enough to specify the set of
attributes (user/machine) in the same query identified by urn?
Regards, Gabi.
>
> Here's the proposed text:
>
> 8. RADIUS State Confirmation Method
>
> URI: urn:ietf:params:xml:ns:abfab:cm:radius-state
>
> The RADIUS State Confirmation Method indicates that the Subject is
> the system entity associated with a RADIUS Access-Accept message,
> identified by the value of the RADIUS message's State attribute.
>
> There are typically two types of system entity associated with a
> RADIUS authentication: a user or a machine. This Confirmation Method
> uses the Identity-Type TLV defined by
> [I-D.ietf-emu-eap-tunnel-method] to permit disambiguation. This
> allows, for example, a SAML Requester to request attributes for a
> user, even if machine credentials were used in the original RADIUS
> authentication.
>
> Define an XML attribute ("RadiusStateValue") giving the RADIUS State
> attribute value
>
> Define an XML attribute ("RadiusIdentityType") giving the Identity-Type
> TLV value
>
> <SubjectConfirmation
> Method="urn:ietf:params:xml:ns:abfab:cm:radius-state">
> <SubjectConfirmationData RadiusStateValue="ABC123"
> RadiusIdentityType="1" />
> </SubjectConfirmation>
>
>
> While working through this, I spotted a bug in the proposed ABFAB
> Assertion Query Profile in that it needs to specify a value for the RADIUS
> User-Name attribute which MUST accompany the SAML-Message attribute (per
> RFC2865). My view is that the user portion of the NAI in the User-Name
> attribute should take a well-known value for different types of SAML
> endpoints. For example, the attribute authority for RADIUS realm FOO could
> be named as saml2-attribute-authority@foo. SAML tends to use URIs to name
> such things, and so one option to improve consistency (at the expense of
> verbosity) is to use the aaa: and/or aaas: URI schemes defined by Diameter
> (but which also supports naming RADIUS endpoints).
>
> Comments welcome...
>
> Josh.
>
>
>
> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a
> not-for-profit company which is registered in England under No. 2881024
> and whose Registered Office is at Lumen House, Library Avenue,
> Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
>
> _______________________________________________
> abfab mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
