Use Case and Requirements Working Group Issue: AuthZ Decisions

[Darren Platt <dplatt@securant.com>]

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/
-----------------------------