On 06/02/13 10:49, Sam Hartman wrote: > I don't see why a radius server couldn't communicate the state attri > ute to an idp. Does the idp understand this attribute? I mean, the idp could understand the user-name, but I'm not sure if the state attribute....
regards, Gabi. > 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 o f 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 attr ibute 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 abfab@ietf .org > 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
