[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: saml authz request vs request context (Re: [xacml] Issues for thenext delegation draft)
Hi Erik, I've split the email to focus the discussion on the saml authz request vs request context. Erik Rissanen wrote: > ... >> I'm a little confused by some of the wording and conclusions in the >> issue list. >> >> I believe that it has been decided to pass arbitrary attribute sets in >> the xacml-saml authz query interface, but I'm not sure whether that >> would include the request context... >> Also, issue#31 is directly related to that, but I don't see any >> discussion about #31. >> >> Then if you pass arbitrary attribute sets, isn't there a need to >> "know" the primary-keys, i.e. which attributes are identity >> attributes, to be able to construct the new request contexts? >> >> Could you please add some more context of the current state of these >> related issues? >> > > > It was decided that the additional attributes and policies would be > added to the xacml-saml authorization query interface, but _not_ to the > request context. The request context is not a transport format. It is an > abstract model for describing the processing model. It was reused as a > transport format in the current saml profile because that was an easy > and quick solution, but since the addition of additional attributes in > the request context does not fit the request context from the processing > point of view, it was decided to instead redo the saml authz request. > > The saml authz request would contain mechanisms for passing additional > attributes as well as indicating the primary keys among them. The > attributes would migrate from the saml request to the context handler in > an implementation specific manner. From the context handler, they will > become available in the request context in the same form as "normal" > attributes that were not coming from "outside". > > The F2F minutes are a bit confusing, as you say, since we did not know > for sure exactly what your requirements are. I suppose what would be > good is if you could propose concrete syntax for the saml authz request. > Could you comment on issue# 31? It discusses the problem of not having the attributes available in the nested eval calls without some global knowledge. Personally I'd like to see the request context as a "functional" interface that you pass all the information that can be used in the evaluation. Note that a call-back like "findAttribute(URI)" doesn't break that functional paradigm (for me it's kind of a hack that allows lazy attribute fetching ;-) ) Furthermore, such a call-back only works if you can name the attribute through the URI, which consists of a path through the current request context - the latter, however, changes when you recursively call the eval function...which would imply that the findAttribute() has to work in a context of the last caller. Actually, I don't even understand how an implementation would work if you do not pass all the attribute sets through the request context... could you walk me through that? Lastly, what is the argument against passing all the arguments in the request context and by having the saml-xacml authz call use the identical request context? Thanks, Frank. -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]