OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: XACML TC Charter Revision - Strawman


I am not suggesting either. SAML (and I) assumes that you know where to go
to get an Authorization Decision and that the PDP you ask knows how to
compute the answer.

I see XACML as currently chartered as a good way to provision a PDP with
policies. This is completely outside the current SAML scope.

I also see XACML as a way of providing a "more complete" Authorization
Decision Assertion, as in case #2 below. I think what will happen in SAML v1
(at least with our product) is that you will get an answer, but not all the
information that was used to make the policy decision will be included in
the response. For example, you will ask "Can Joe access x?" and you will get
the answer "Yes, joe can access X", but the fact of the matter is the same
request would get a different answer 1 sec later. Also perhaps it didn't
even matter that it was Joe. Probably for accountability purposes that is
good enough, but I continue to be concerned that the assertion will be
wrongly construed.

Case #3 came from the fact that we keep punting anything that looks
complicated and saying "XACML will take care of that." Since I have been
prominent among the punters (that's a joke, Phill) I started thinking about
how XACML might help us with our current major struggle -- Requests. It
occured to me that although requests for policies are not the same as
policies, perhaps we could steal some bits of XACML for our purposes. This
would help justify my position of saying "do something simple now and leave
a hook for XACML".

Hal 

> -----Original Message-----
> From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
> Sent: Thursday, June 07, 2001 3:20 PM
> To: 'Hal Lockhart'; 'xacml@lists.oasis-open.org'
> Cc: security-services@lists.oasis-open.org
> Subject: RE: XACML TC Charter Revision - Strawman
> 
> 
> Hal,
> 
> Are you suggesting that there is merit in including
> the capability to identify the right policy
> ("identify" is presumably a service "some" PDP can provide)
> for a specified target (let us assume that we will solve the target
> specification problem in XACML) within the scope of XACML charter? 
> 
> Or are you suggesting that XACML should include syntax that will allow
> interpretation and selection of a single policy from a set of 
> policies?
> Does SAML expect to use XACML in that way?
> 
> -Suresh
> 
> -----Original Message-----
> From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> Sent: Thursday, June 07, 2001 1:15 PM
> To: Damodaran, Suresh; 'xacml@lists.oasis-open.org'
> Cc: security-services@lists.oasis-open.org
> Subject: RE: XACML TC Charter Revision - Strawman
> 
> 
> Sorry to be slow on this, but there is another issue I think 
> we need to
> consider and include or explicitly reject. I will describe 
> this informally
> because it is easier to express that way and I hope will be easier to
> understand. If we get some consensus we can worry about more precise
> expression.
> 
> Since this bears on the use of XACML by SAML, I have cross 
> posted this.
> 
> As I understand it the current scope of the XACML schema is 
> to express:
> 
> 1. Some policy is "this".
> 
> SAML is interested in using XACML as a means of expressing a 
> Authorization
> Policy Decisions. In other words something like:
> 
> 2. The result of evaluating "this" is TRUE (or FALSE)
> 
> It seems to me that under the current charter for XACML, this 
> should work.
> 
> However, in order to do this, SAML needs to be able to make a 
> request for
> this to be done. Presumably, making the request does not 
> require knowing
> what policies apply. Therefore it needs to be possible to say:
> 
> 3. Please evaluate the policies that apply to target X. Here 
> are some inputs
> that may be needed for this decision. [The PDP will fill in 
> any missing
> values, either by observing them for itself (e.g. date/time) 
> or by using
> default values (e.g. unauthenticated subject).]
> 
> It seems to me that XACML could help with this. For example, 
> XACML will
> certainly have to define a generalized syntax for expressing 
> the name of a
> target. 
> 
> Also, if you can say:
> 
> a) True if signinglimit > $5000
> 
> Then similar syntax could be used to express:
> 
> b) Current value of signinglimit = $10,000
> 
> Any opinions?
> 
> Hal 
> 
> > -----Original Message-----
> > From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
> > Sent: Wednesday, June 06, 2001 7:45 PM
> > To: 'xacml@lists.oasis-open.org'
> > Subject: RE: XACML TC Charter Revision - Strawman
> > 
> > 
> > 
> > Here is the revised TC Charter - from the lack of email on 
> this thread
> > in the past few days, I am assuming that all the comments are 
> > already in.
> > 
> > Notes: 
> > 1. Changes from previous version: 
> > 	a) "subject" has been replaced by "target"
> > 	b) "CORBA CSIv2" replaced by "LDAP"
> > 2. Charter is silent on the mechanisms for executing the 
> > policy (PDP and
> > PEP). 
> > 3. Non-goals  of XACML are missing (if any of you want to 
> > take a stab at it,
> > please do)
> > 
> >  Please send your comments.
> > 
> > --------------------------------------------------------------
> > --------------
> > ---------------
> > 
> > Product of TC
> > XACML TC will define a core XML schema for representing
> > entitlement policies, also called XACML
> > 
> > Policy Target
> > The target of a policy (hereafter referred to as "target") 
> > can be any object
> > that can be referenced in XML.
> > 
> > Protocols and bindings
> > XACML TC will define new protocols or identify bindings
> > to existing protocols (e.g., XPath, LDAP) intended as means 
> > of accessing and
> > communicating the policies
> > 
> > Scope
> > XACML is expected to address fine grained control of
> > authorized activities, the effect of characteristics of
> > the access requestor, the authorization protocol over
> > which the request is made, authorization based on classes
> > of activities, and content introspection (i.e. authorization
> > based on both the requestor and potentially attribute
> > values within the target where the values of
> > the attributes may not be known to the policy writer)
> > 
> > Extensibility
> > XACML core schema is extensible for as yet unknown features
> > 
> > Interoperability
> > 
> > XACML TC will define interoperability of XACML core schema
> > with other standards.
> > 
> > 
> > Simon Blackwell
> > Suresh Damodaran
> > Fred Moses
> > 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC