Title: Explanation - Capability model
-----Original Message-----
From: Tim Moses
[mailto:]
Sent: Tuesday, October 16, 2001 10:59
AM
To: 'XACML'
Subject: [xacml] Explanation - Capability
model
Colleagues - A decision request contains (as a minimum) the
subject, the resource and the action. Job one for the PDP is to locate,
retrieve and verify the policy appropriate to the decision request. By
"policy" I mean the complete set of rules that must be considered when
formulating the decision.
From
an XACML perspective, I think we need to first determine the inputs and the
model structure and then determine what items must be present. Everyone is tired
of hearing me say subject is not required, certainly it could be argued that
action is not required, for example, consider a application protocol with only
one operation. (http is almost that way since any given page is usually only
accessed with a particular operation (e.g. GET) and all operations can perform
reads and writes.)
Not
withstanding that, I agree with your use of the term policy.
Certainly the PDP must IDENTIFY the policies that apply
to any given decision. It seems to me that whether it must locate, retrieve and
verify them seems to me to be implementation specific and not necessarily the
concern of XACML.
We need a way of identifying policies, for two reasons.
Firstly, most mechanisms for locating and retrieving policy will be based on
the policy's "name". I am thinking of LDAP, "The Web", ODBC, etc..
In addition, for security reasons, the PDP must verify that it has retrieved
the correct policy for the decision request. So, it must be verifiable,
by examining the policy and the decision request, that it is the right policy
for the request. One way (perhaps the best way) is to name the policies
according to the situations to which they apply. The PDP has to assure
itself that the policy was issued by an authority (or authorities) that is
(are) competent to set policy for the situation and that it has not been
altered, and (furthermore) that the policy's name identifies it with some
aspect of the decision request.
I
don't understand why you introduce the concept of "naming" policies. My view is
that XACML should say, these inputs are used to determine which policies apply.
If you want to (for example) concatenate the values, hash the result and use
that to create an LDAP query, fine. If you have all the policies hard coded in
your PDP, that is fine too.
The
means by which a PDP decides to trust a PRP also seems outside of XACML.
Certainly we could provide the optional ability to sign policies using XMLdsig,
but in many cases other means will be used. For example, the PRP and PDP may
share an address space.
When policies are identified with the subject, the model is
called a "capability" model.
Capabilities specifically mean the use of a bearer
token that specifies the right to do something. See for example: http://www.garlic.com/~lynn/secure.htm which
cites both RFC2828 and the National Security Decision
Directive:
"(I) A
token, usually an unforgeable data value (sometimes called a 'ticket') that
gives the bearer or holder the right to access a system resource. Possession of
the token is accepted by a system as proof that the holder has been authorized
to access the resource named or indicated by the token. (C) This concept can be
implemented as a digital certificate. [RFC2828 ] A protected identifier that
both identifies the object and specifies the access rights to be allowed to the
accessor who possesses the capability. In a capability-based system, access to
protected objects such as files is granted if the would-be accessor possesses a
capability for the object. [AJP][NCSC/TG004"
I
consider capabilities infeasable in medium and large scale environments because
they create to close a coupling between the user repositories and the resources
protected by the PEPs. Either the capabilities must be so coarse grained that
they are not useful (whole web site) or the administrative coodination required
is impractical (if I add a single page to my web application, I have to inform
the capability issuing point).
When a
policy layer is interposed between the "capabilities" and the actual policy
decision, essentially you end up with user attributes, as in the SAML/XACML
domain model. If you want to call a SAML Attribute Assertion a capability, then
I guess we don't have any fundamental disagreement, but that is different from
how the term has been used in the literature.
When policies are identified with resource and action, the model is
called an "access control" model.
At least in theory, policies could be identified with
ancillary parameters (e.g. time of day). But, this doesn't seem to be an
especially helpful option.
In the capability model, policies are located and retrieved
based on the subject's name, and in the access control model, policies are
located and retrieved based on the name of the resource and action.
We'll have to decide whether to support both capability and
access control models. Personally, I would be quite happy to ignore the
capability model. Perhaps, the group could consider taking this
position, and seeing if anyone complains. If someone were to complain,
then we would have to define a general model that accommodates both capability
and access control approaches.
Perhaps this is only an issue of definition. I
believe strongly that the domain model, with potentially multiple authorities is
the right kind of approach. As long as your notion of capabilties fits in that
framework, I have no problems with it.
Hal
