MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Notes from OGSA/XACML SAML Req/Resp discussion
Items marked "*" reflect notes taken during the meeting on 21
August 2003. They are inserted into appropriate places in the
agenda outline.
Anne
--
Anne H. Anderson Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel: 781/442-0928
Burlington, MA 01803-0902 USA Fax: 781/442-1692
I use "attribute" to mean the same thing (I hope) as
"credential". [x] indicates a proposed solution at the bottom.
- decision push mode: any changes needed to support this?
* XACML' proposal include request in response.
* XACML 2.0 work item to include a partially evaluated policy
as "Conditions" in the SAML Response.
* May be good to include in the XACML response, rather than
depending on SAML.
- attribute pull mode (PDP pulls initiator's attributes from
some other authority)
o Way for client to provide pointer to the authorization
service, giving it a hint where to find attributes
- Multi-step authorization
o Way for a set of attributes to be collected for a given
subject and re-used in a sequence of subsequent
AuthorizationDecisionQueries. Where is this state
maintained?
* Von is more on "attribute request" side.
* David is more on "establish context" with PDP side.
Saves retrieving and parsing attributes over again on each
request.
* XACML proposal allows PDP to return all information or all
attributes used in evaluating this request. Issues about
whether attributes are still valid on a subsequent request.
Lack of mechanism for returning validity period, etc.
Problems with a very dynamic environment, but useful if
fairly static.
* CORBA has a "setup" mode.
* XACML assumes attributes in Request Context have been
validated. Front-end might do the validation, and might
construct the Request Context from a bag of authenticated
SAML Attribute Assertions.
* Frank proposes expanding "issuer" to include the entire trust
chain. Would like to do the trust validation in XACML,
cryptographic validation outside XACML. Doesn't make sense
to put this information into XACML unless in SAML. Shouldn't
this go into X.509 NameConstraints in signing certificate?
Orthogonal issues to be resolved. X.509 is trusting
identity, need other way to trust authority to issue certain
attributes. Use XACML policies in X.509 Attribute
Certificates to indicate who is trusted to issue which
attributes? **POSSIBLE WORK ITEM**
* Way to express policies about what chains you trust in XACML?
SPKI uses KeyNote for this.
o Format for such a collection of attributes (a skeleton XACML
Request?)
- Linking an AuthorizationDecision to the set of information
contained in the Query to which it is a response.
o Is XACML proposal option for including the entire Request in
the AuthzDecision sufficient? Does the unique ID in the SAML
AuthorizationDecisionQuery need to be included in the
AuthzDecision? Does each XACML Request need its own unique
ID?
* Current SAML returns request info with response, but it isn't
sufficient. Subject, Target, Actions returned. Good to have
a way to return a simple Decision without the other
information. Optionally! Used in pull mode.
* A simple decision will never have conditions. It will have
the simple identifier of the request.
- Decision values
* SAML respondWith is deprecated. Better to use specific flags
in the request to indicate information options on what to be
returned.
* Use of Indeterminate, how to specify a decision subject to
Conditions has been returned. "Indeterminate" = "Deny unless
<Conditions>".
* Richer return value syntax: grant, deny, grant subject to
conditions, not applicable, unable to evaluate due to error.
Simple PEP's may be unable to deal with anything except "yes"
and "no". Requester should be able to specify type of
response: richer or yes/no. SAML currently uses respondWith,
but that is deprecated because semantics fuzzy. Alternative
is unknown. OGSA uses respondWith to specify simple/complex
decision as well as single-step/multi-step.
* NotApplicable: nice to do on a per-association basis, not on
a per-request basis. Returned "Conditions" might include
that information - involves partially evaluated policies.
XACML can also return Obligations.
* XACML proposal uses two flags: "InputContextOnly (use only
the attributes contained in the request in making the
evaluation; used for "what if" mode). "ReturnContext"
(return minimally all information used in making the
decision; may return more information).
* Environmental attributes requirement handled satisfactorily by
XACML Request Context
* Reference statement: credential pull model. Part of XACML 2.0
work items.
* Separate semantic requirements from proposed syntactic changes;
next meeting will be on 28 August during XACML Focus Group
time; prior to that, participants should submit semantic
requirements to e-mail list.
- Multiple actions in a single request. [1,2]
o Is Decision all-or-nothing? or a separate decision for each
action? If separate, how do decisions specify action to
which they pertain?
- Multiple resources in a single request. [1,2]
o Is Decision all-or-nothing? or a separate decision for each
resource? If separate, how do decisions specify action to
which they pertain? (XACML already supports multiple
resources in a decision, but not in a Request).
- Decisions where not all information was available. How to
indicate that SAML Decision contains Conditions that must also
be satisfied. Format for those Conditions (XACML Policy?) [3]
- #X509SubjectName DataType: will XACML support this as a base
DataType? If so, will it replace the current XACML x500Name
DataType? Are comparison semantics the same?
- Returning subject's rights to all resources of which the PDP is
aware (wildcard resource URI).
- Returning subject's rights to take all actions that apply to a
specified resource.
Possible solutions:
[1] Multiple Actions, Associate Actions with Resource: It might be
useful for the XACML Request to be of the form
Subject Attributes
Requested Permission 1
Resource
Resource Attributes
Action
Action Attributes
Requested Permission 2
...
where each Requested Permission contains a resource and an
action, along with their attributes. The XACML Response
should then be modified to return a Decision for each
"Requested Permission", identifying the "Requested
Permission". This would meet the need that various users have
expressed for multiple actions, or for getting multiple
decisions per Request. [It does not solve the Hierarchical
Resource problems, but certainly does not make them worse :-)]
The evaluation model would be to run the current evaluation
model once for each Requested Permission.
[2] Semantics for multiple resources and/or actions might be
specified as: PDP runs the current evaluation engine once for
each resource/action pair. Depending on a flag set by the PEP,
either a single decision is returned ("Permit" only if every
resource/action pair evaluated to "Permit") or a separate
decision is returned for each, using existing XACML Response
multiple-decision format, but specifying action-id as well as
resource-id to which each decision applies.
[3] Partial Evaluation: It might be useful to define "partial
evaluation" for XACML, both for debugging purposes and for
applications such as returning "Conditions". By "partial
evaluation", I mean using all available attributes to resolve
and factor out predicates that can be eliminated, leaving a
Policy that that contains only predicates that depend on
unavailable attributes. For example, if the Rule is:
<Rule Effect="Permit">
<Condition FunctionId="and">
<Apply FunctionId="string-equals">
<AttributeValue>X</AttributeValue>
<SubjectAttributeDesignator AttrId="subject-id">
</Apply>
<Apply FunctionId="string-equals">
<AttributeValue>Y</AttributeValue>
<ResourceAttributeDesignator AttrId="resource-id">
</Apply>
</Condition>
</Rule>
and a Resource Attribute for resource-id with value "Y" is
supplied, but there is no subject-id attribute available, then
the Rule, given the input Context, simplifies to
<Rule Effect="Permit">
<Condition FunctionId="string-equals">
<AttributeValue>X</AttributeValue>
<SubjectAttributeDesignator AttrId="subject-id">
</Condition>
</Rule>
I can think of lots of problems in defining useful "partial
evaluation" rules, but I can also think of lots of useful
cases.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]