I don't see why a radius server couldn't communicate the state attri ute to an
idp.
The same attribute may apply to user and machine with different values.z
Gabriel Lopez <[email protected]> wrote:
>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
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity._______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
