RE: Use Case and Requirements Working Group Issue: AuthZ Decision s

["Edwards, Nigel" <Nigel_Edwards@hp.com>]

Hi Darren,
Thanks for taking the time to write this up. I have a couple of points.

I am not sure that we currently have a concrete definition of policy
and this may hamper discussion on the points you raise. In the core
assertion work I have seen examples of assertions which some may
consider to be policy.

Example taken from version 0.3 of Phill Hallam-Baker's vmodel document

<Subject>
 <Account>Alice
  <Resources>
   <string>http://store.carol.test/finance
 

This assertion could be interpreted as granting Alice access to the
resource http://store.carol.test/finance

Is this a statement of policy? I think that depends on your definition
of policy and also the interpretation any relying party makes on the
assertion. 

In Question/issue 8, I think you give some examples of what would be
in a policy language (and hence what could be in a policy
statement). I have not seen examples of assertions in the current
drafts containing all the things you list here.

There are some security pitfalls with some of the options listed for
question 4. If you don't include a reference to the question asked (or
the question asked itself), then you are open to replay
attacks. (Unless you are running over some kind of session protocol
which protects against this.)

Nigel

> -----Original Message-----
> From: Darren Platt [mailto:dplatt@securant.com]
> Sent: 31 March 2001 02:09
> To: Security-Services
> Subject: Use Case and Requirements Working Group Issue: AuthZ 
> Decisions
> 
> 
> During the last call of the leaders TC and its working groups, it was
> decided that the subgroups would bring their major issues to the next
> concall of the TC so that the TC can provide some direction 
> on them.  To
> this end, it was decided by the use case and requirements 
> working group to
> send out emails to the TC about the three issues our group 
> plans to raise
> during the TC concall.  The purpose of these writeups is to level-set
> everyone on the current state of the debate so that we don't 
> have to recap
> during the concall, but rather move forward.  A goal for the 
> writeup is to
> structure the issues such that some decisions can be made 
> that we can build
> upon.
> 
> The use case and requirements working group will be distributing three
> issues to the TC mailing list for review by Monday afternoon.  Hal has
> already sent a writeup of the issue we are calling "AuthN 
> Passthru", and Gil
> Pilz will be sending a writeup about sessions.  Following is 
> a writeup of
> the third issue we'd like to discuss with the TC at large - 
> an oldie, but a
> goodie - AuthZ decisions.  I believe we've made some progress 
> since the last
> telcon, and I've tried to capture the current state of the 
> debate as well as
> possible:
> 
> 
> Question 1: Does a PEP make decisions?
> 
> By definition, a PEP does not make decisions. This is true in 
> an abstract
> sense. In the "real world," a single piece of software may serve the
> responsibility of both PEP and PDP. However, at this level of 
> abstraction,
> we want to define these interfaces as responsibilities.
> 
> Philosophically, a PEP does in fact make decision on policy. 
> The _implicit_
> policy of a PEP is, "I should enforce decisions" (by the 
> definition of PEP).
> We can get recursive on this issue and say that
> there's another implicit policy, namely, "If I have a policy 
> that I should
> enforce decisions, I should enforce decisions." This can 
> recurse infinitely,
> and although it's an interesting logic question, we can 
> probably stop at the
> first step of the chain for this discussion.
> 
> Another implicit policy is about which decisions to enforce 
> -- from which
> PDPs, for what time span, for which resources. Again, this is 
> an implicit
> policy, part of the configuration or implentation of the PEP, 
> and not cogent
> to this discussion.
> 
> 
> Question 2: Does a PEP use security policy?
> 
> Security policy is, by the definition we're using, rules or practices
> specifying access to resource by entities. If the answer to 
> question 1 is
> no, then a PEP does not make decisions.  Therefore, a PEP does not use
> policy.
> 
> 
> Question 3: Does a PEP take policy as input?
> 
> If the answer to question 2 is no, then a PEP does not use 
> security policy.
> While there's no reason that a PEP could not receive policy 
> data, it would
> have nothing to do with the data. It's as useful to send 
> bananas or love
> letters to a PEP as it is to send policy, since the PEP will 
> not act on any
> of these inputs.
> 
> 
> Question 4: What is an Authorization Decision?
> 
> We have defined in the domain model that an AuthZ decision is 
> the data sent
> from a PDP to a PEP.  Another way to think about an AuthZ 
> decision might be
> as a specific application of security policy based on a 
> specific context.
> If we agree that the answer to question 3 is no, then at 
> least we know what
> an Authorization Decision is not, namely, security policy.
> 
> The question still remains, what is an AuthZ decision? An 
> AuthZ decision can
> be thought of as an answer to a particular question about a 
> principal's
> permission to perform an action on a resource. There are 
> several possible
> things that can be included in an AuthZ decision:
> 
> 	 1) A boolean (yes or no) answer.
> 
> 	 2) A 3-valued logic (3VL) answer -- yes, no, and "not 
> applicable" or "not
> handled."
> 
> 	 3) An identifier for the principal, an identifier for 
> the resource, and an
> action.
> 
> 	 4) A reference to the original question.
> 
> 	 5) A "reason" for the decision -- some code that 
> defines how or why the
> decision was reached.  At one point, Nigel suggested adding 
> the following
> requirement:
> 
> [R-AuthzDecisionRefused] Metadata should be provided for 
> denied requests.
> If a request for authorization is denied, optionally metadata 
> indicating why
> the request is denied should be returned. (An example might 
> be "credit card
> expired".) (As an aside, I believe this is already implicitly 
> allowed by the
> S2ML AzData element, because this can contain arbitrary element. I am
> suggesting it might be made an explicit element.)
> 
> 
> Question 5: Is policy ever sent?
> 
> Conceptually, there's no reason that policy cannot be sent.  
> What are the
> scenarios where we want to?
> 
> 
> Question 6: What receives policy?
> 
> PDPs, again by definition, make policy decisions. Therefore, 
> they may take
> security policy as an input.
> 
> In some scenarios, optimizations have been suggested for 
> passing policy to a
> PEP from a PDP. However, this is based on assumptions about 
> implementation.
> At an abstract level, these scenarios are really about an interaction
> between a PDP and a component that is playing roles both as 
> PDP and PEP.
> 
> At a design level, it could make sense for a PDP to send some 
> data package
> containing both policy and decision to a component playing both roles.
> However, it's important to note that the component is not
> receiving policy in its role as PEP, but in its role as PDP. 
> So the question
> is still one of PDPs receiving policy, and not PEPs.
> 
> 
> Question 7: Should SAML define a format for transferring policy?
> 
> The scenario described above defines a case in which policy 
> would be passed
> from PDP to PDP. Are there others where this would occur?
> 
> 
> Question 8: Should SAML define a format for policy?
> 
> A format for security policy rules would at the least have to 
> define a rules
> language -- if-then, combinations of boolean logic, etc. By 
> definition,
> policy is rules. In addition, the format would have to
> encompass the many factors used to make security decisions -- 
> for example,
> attributes of a user, attributes of a resource, context like time and
> location, etc.
> 
> This is a significant effort. The consensus at the face to 
> face meeting was
> that defining a format for policy is the work of the XACML effort, and
> outside the scope of SAML.
> 
> 
> Regards,
> 
> Darren
> 
> 
> Darren Platt
> Principal Technical Evangelist
> Securant Technologies
> 345 California St., 23rd Floor
> San Francisco, CA 94104
> tel - (415) 263-4976
> fax - (415) 764-4949
> http://www.securant.com/
> -----------------------------
> 
> 
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: 
> security-services-request@lists.oasis-open.org
>