MHonArc v2.5.0b2 -->
xacml message
[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]