On 9 Dec 2011, at 09:23 , Josh Howlett wrote: >> 1. The data is carried in a RADIUS attribute. > . . . > I'm not aware of any standardised semantics to convey this either. It > could always be defined, of course, either within the standard or > vendor-specific RADIUS namespaces. > >> 2. The data could be carried in a SAML request. > . . . > This is certainly reasonable as SAML allows the RP to specify conditions > to authentication requests. Any modern RADIUS implementation would support > this for the RADIUS attribute case today (we have a FreeRADIUS module for > processing SAML requests that could be extended to cover the SAML case > that you describe without much difficulty I believe). > > You also have a third option, which is to infer the LoA from the source of > the request. This obviously doesn't help in the case where an RP needs >1 > LoA for a particular IdP.
I don't think these options are mutually exclusive. The AAA server can have some local policy requiring a particular LoA for specific RPs. If there is no matching local policy rule on this, it can look for a value of a particular RADIUS attribute. If the attribute is not present, or even set to a value explicitly indicating to use the SAML assertion, it can go that way. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D e-mail: [email protected] Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
