Josh, I am not sure why you think that the RADIUS state variable needs to be put into the SAML and not just in the RADIUS message that is carrying the SAML request. Can you elaborate?
Jim > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Josh Howlett > Sent: Tuesday, February 05, 2013 10:33 AM > To: [email protected] > Subject: [abfab] Proposal for post-authentication attribute request > > 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 > (2) whether the response should include attributes describing the user or > machine. > > 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
