RE: XACML TC Charter Revision - Strawman

[Michiharu Kudoh <KUDO@jp.ibm.com>]

Simon's suggestion could be rephrased as:

1. What is an appropriate set of primitive components for representing
   access control polices?
2. What is an appropriate authorization model?

My opinion is the following:

#1:
XACML should be flexible so that it can represent at least both ACL-based
policies and capability-based policies since the majority of the access
control
policies consist of a tuple <subject, object (or target), action> or its
variations. Moreover most of us are familiar with this notion. I use the
word ACL-based policies as resource-centric policies, and capability-based
policies as principal centric policies, respectively.

I think that an issue would be whether or not XACML should be based on
another primitive components as a starting point.

#2: I also agree with Gilbert on the point that

> I think the best way to proceed is to first agree on our Use
> Cases, and then
> define a minimally constraining authorization model that
> meets the needs of
> those Use Cases. From there we can work on the specifics of the policy
> language . . .

The following is an simple use case I made. It assumes that a PEP is a Web
server that manages XML resources such as patients' medical records
consisting
of e.g. a patient's name and diagnosis information. A PDP is built based on
XACML. Suppose that a doctor submits an update request on the chemotherapy
information. Though this assumes the target resource is XML, the target is
not necessarily the XML as the XACML charter says so.

1. An access requester (a doctor) submits an access request to a PEP.

2. The PEP authenticates the requester and assigns a set of subject
identifiers
such as a user ID (Alice), a set of active role names (doctor in charge),
or a
set of group IDs to which the requester belongs. In my opinion, this
process is
not an authorization process but an authentication process. (I also admit
there
are another opinions.)

3. The PEP calls the PDP with a set of access request parameters like
<subject,
object, action> e.g. <Alice, Bob's chemotherapy element in XML, update>. We
assume that the PEP must know what parameters can be accepted by the PDP.
For
example, if the PDP requires an evidence for the requesting principal, the
PEP
must submit an access request parameters with some signed data for the
requesting
principal. If the PDP only requires a simple text string e.g. "Alice" as an
principal identifier, the PEP does not have to submit any principal
credential.
In other words, what PDP requires depends on how the access control
policies are
specified in the PDP and what kind of trust is built between PDP and PEP.

4. The PDP determines whether or not the requested access is allowed based
on
the access control policy rules. In the XACL language, an authorization
model
is also capable of returning necessary conditions in addition to the
traditional
yes/no response. We called such condition a provision or a provisional
action.
This means that a response from the PDP may include an additional condition
such as "store the access log" and "encryption is necessary." This assumes
that the PEP must know how to handle these additional information returned
from the PDP. Moreover, it also assumes that a security policy programmer
can
determine what additional information should be added to the access control
policies. Returning to the medical example, the decision may be "the
doctor's
update action is allowed, but an access log must be stored in the log
file."
This does not necessarily imply the security vulnerability if the PEP is
implemented to be secure enough. Anyway, I think that the decision for the
policy exposure should be determined by the security policy programmer, not
by XACML language.

5. After receiving the PDP's decision, the PEP enforces the access to the
requested resource. Finally, Bob's chemotherapy element in the target XML
will be securely updated by the PEP.


Again, I think that the first thing we need to do is to prepare several use
cases and next proceed to define a minimally constraining authorization
model.

Michiharu Kudo


From: "Simon Y. Blackwell" <sblackwell@psoom.com> on 2001/06/09 12:20

Please respond to "Simon Y. Blackwell" <sblackwell@psoom.com>

To:   "'xacml@lists.oasis-open.org'" <xacml@lists.oasis-open.org>
cc:   security-services@lists.oasis-open.org
Subject:  RE: XACML TC Charter Revision - Strawman



Hal is on the right track here with what I imagined XACML to be used for
i.e. provision a PDP.

As to what the PDP actually does with the XACML, i.e. return just yes/no
decisions, return policy fragments, return entire policies, or return sets
of policies, I had imagined that such functionality would be determined by
the implementer of the PDP based on the desired behavior. In fact a PDP is
but one possible interface to a policy repository. The policy repository
may
well need a provisioning/administrative interface that makes no policy
decisions.

At Psoom we have a specific need that is not strictly security enforcement
related that requires the exposure of policy detail. As Bill Parducci has
pointed out, the exposure of policy could allow for the circumvention of
policy, this is bad in a strict security sense. On the other hand, the
exposure of policy can allow for the adjustment of behavior such that it is
compliant with policy, which is good from an operational perspective, e.g.
unless you tell me policy requires that I have a $5,000 balance in my bank
account to access certain services, how can I possible comply with the
policy?

Ernesto, Michiharu, and Ken Y. - jump in here, I think you guys have done
the most work so far in actually representing policy as XACML as wells as
issuing decisions based on the policy.

> -----Original Message-----
> From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> Sent: Thursday, June 07, 2001 2:38 PM
> To: 'Damodaran, Suresh'; Hal Lockhart; 'xacml@lists.oasis-open.org'
> Cc: security-services@lists.oasis-open.org
> 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
>