[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: schema 16 comments: autn assertion and attribute authority
I'd like to pursue this topic a bit more, if I may. By way of introduction, I'm helping with the Shibboleth technical design process, particularly the low-level aspects, and just joined the list as an additional observer/liason along with 'RL' Bob and Marlena. My background is primarily in web development and distributed computing, with some dabbling in application-level security. Simon Godik wrote: >It's been pointed out by Shibboleth design that authentication >authority can front several attribute authorities. After authentication >assertion is received how do we know which attribute authority to use? I'd go a bit further in that we also need to know what protocol should be used to exchange any subsequent messages (in Shibboleth's case, attribute request and assertion response messages). We expect to adopt the SAML HTTP binding for this (in whole or in part) in our initial pilot, but of course there may be others eventually, and SAML itself has tentatively defined a pair, HTTP and SOAP. It would seem logical at minimum to tag these with URIs, just as the authentication methods have been, and include that URI in the locality information you're proposing. It's also, I think, self-evident, that having an endpoint address and port are not sufficient to specify a binding over HTTP or SOAP, since you need the URI (unless you define a well-known endpoint, which seems unnecessary). The (very) preliminary idea in Shibboleth was to model the binding information as a string that would be parsed in accordance with the binding method/protocol. For example, if a directly TCP-based protocol was used, we might encode it as host:port, or if HTTP or SOAP was used, the string would be a URI. So this might look like: <complexType name="LocalityType"> <attribute name="Protocol" type="anyURI"/> <attribute name="Binding" type="string"> </complexType> Obviously, structuring the Binding string is fine also, perhaps with an abstract type that is extended for each protocol people develop. I've only just begun to really digest a lot of what's in SAML, although I've looked a lot at the binding side, on which I have a bit more to say separately, but this is a particular aspect we would definitely like to see included. -------- Scott Cantor So long, and thanks for all the fish. cantor.2@osu.edu -- Douglas Adams, 1952-2001 Office of Info Tech PGP KeyID F22E 64BB 7D0D 0907 837E The Ohio State Univ 0x779BE2CE 6137 D0BE 1EFA 779B E2CE
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC