xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [xacml] New Issue#61: WS-XACML: How are the contents of XACMLAuthzAssertions represented in the base XACML Policies
- From: "Abbie Barbir" <abbieb@nortel.com>
- To: "Anthony Nadalin" <drsecure@us.ibm.com>, <Anne.Anderson@sun.com>
- Date: Wed, 20 Dec 2006 10:33:47 -0500
+1
abbie
One thing that bothers me (well I have several),
1) is why is this
called WS ? as I'm not seeing a tie to web services, just to WS-Policy
2)
missing the tie to WS-Security, as SAML is not the only assertions that are
used, this effort should be able to tie into the claims used in
WS-Security
3) there are 2 sides the requestor and receiver, each should be
able to represent policy, not seeing this clearly in this proposal
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Anne Anderson - Sun
Microsystems <Anne.Anderson@sun.com>
Anne Anderson - Sun Microsystems
<Anne.Anderson@sun.com>
12/20/2006 08:23 AM
Please respond
to Anne.Anderson@sun.com | |
|
Hi
Rich,
The problem to me with having WS-XACML policies integrated with
other
policies is that it is not possible in general to extract an isolated
<Apply> statement from a normal policy - that <Apply> might be
in the
middle of an "...:and" function, for example, that requires it to be
associated with other constraints. Or it might be in an "...:or" such
that it is not necessarily required to be true.
That was why I
suggested that WS-XACML policies be contained in a
top-level separate
PolicySet. The policies in that set can be "AND"ed
with the remaining
policies using an appropriate combining algorithm.
Then during evaluation of
the remaining policies, if you know the
WS-XACML policies have already
evaluated to "true", then you don't have
to re-evaluate the WS-XACML
PolicySet.
<PolicySet PolicySetId="all:policies"
PolicyCombiningAlg="ordered-deny-overrides">
<PolicySet PolicySetId="ws-xacml:policies"
PolicyCombiningAlg="deny-overrides">
<!-- These don't have to be re-evaluated if you know
they
must have been
satisfied in order to get this far -->
...
WS-XACML Assertion Requirements,
written as <Policy> elements ...
</PolicySet>
<PolicySet
PolicySetId="other:policies"
PolicyCombiningAlg="deny-overrides">
...
Remaining policies, which can assume
the WS-XACML Assertions have already
evaluated to "true"/"permit" ...
</PolicySet>
</PolicySet>
Another idea is to use the
WS-XACML policy constraints to partially
evaluate the remaining policies.
For example, if you know that a
WS-XACML policy requiring "role" to be
a subset of {"manager",
"auditor"} must evaluate to "true" before other
policies are evaluated,
then you can go through the remaining policies and
replace any
predicates that require "role" to be a subset of {"manager",
"auditor"}
with "True". But I don't think it is worthwhile pursuing
this: when
there are multiple WS-XACML policy alternatives, you don't know
which
one will be the one that evaluated to "True", the cost of determining
the intersections with every predicate in the other policies is high,
and in many cases the intersections can't be fully evaluated (e.g. a
predicate that says "role" must be a subset of {"manager", "individual
contributor"}).
I misspoke yesterday when I said the Capabilities
could be included in
the overall XACML policies as "or"ed constraints.
The "Capabilities"
are things the issuer of a policy is willing and
able to do for the
other party and, as such, play the role of an XACML
Request to the other
party, and not an XACML Policy that the other party
must satisfy. So
above I said to write the only the Requirements as
Policy elements in
the WS-XACML
PolicySet.
Regards,
Anne
Rich Levinson wrote On 12/19/06
19:46,:
> Hi Anne,
>
> I guess I have not been thinking along
the lines of "WS-XACML" policies
> as being a distinct class of
xacml Policy, but that the info in this
> profile would
> be worked
into existing xacml Policy structures, but maybe the analysis
> below
might be interpreted from either perspective.
>
> Basically, the
point of view I am looking at this from is that I see
> that web
>
service access is now effectively a 2 step process, whereas before
>
WS-Policy
> was introduced, it was essentially a 1 step process where one
just
> submitted one's
> request, for example using WS-Security,
and hoped for the best.
>
> It is clear the 2 step process has the
advantage that in step 1, the
> client is
> now formally told in
advance, what the reqts are to successfully submit
> the request. Then, in
step 2, based on the input from step 1, the client
> can construct a
request that should be in compliance with the policy
> requirements that
will be applied by service infrastructure when the
> request is
submitted.
>
> So, from my view, step 2 doesn't change that much
from what currently
> exists today (except for new features such as the
privacy obligations
> that are currently being included in this profile -
I think the
> "Capabilities"
> are also new, but I see them more
relevant in step 1 than step 2 - i.e.
> if the client doesn't like the
service capabilities, then it probably never
> gets to step 2).
>
> Bottom line is that my expectation is that many XACMLAuthzAssertions
that
> are supplied to the client will, in general, reflect aspects of
existing
> policies
> that are in current operation. For example,
maybe a service requires
> that a client
> submit a valid "gold
club member number" in some element of the request
> and this
>
element is evaluated as part of authorization.
>
> Now, in order to
make the service more readily accessible by users, the
> service
>
provider decides to put a XACMLAuthzAssertion in the WSDL that will
specify
> this constraint.
>
> If you agree that the above is
a possible or typical az type of
> scenario, ...,
> then it appears
to me the next logical concern is that: somehow, in the
> Policy
>
that contains the "gold card member number" constraint, a "flag" of
some
> sort would be appropriate to apply to that constraint in order that
a
> service
> provider would know by reading the Policy for that
resource (presumably
> thru some TBD policy access/distribution
mechanism). Possibly the
> constraint
> could be a
VariableDefinition that could be referenced in the main az
>
policy
> and a separate Policy segment for use in constructing
XACMLAuthzAssertions.
>
> My sense is that something would be
useful in the WS-XACML profile that
> would advise on how to construct new
policies and adapt existing policies
> to address this issue (i.e. issue
61).
>
> I think the profile identifies 3 major classes of
info:
>
> Requirements of the az type - i.e.
constraints that are typically
> found in
existing policies.
>
> Requirements of the privacy
type - i.e. constraints that bind the
> user as
>
to how the resource is used once acquired (these may be
considered
> just another az type in general,
but they are "new" in the sense
> that
>
they are things the user has to "agree to" and as such the user
>
needs
> to know what is being agreed to, and
how in the request to represent
> the fact that
the agreement is accepted). As such these reqts
>
may lend themselves to be separable off in a separate Policy or
>
PolicySet.
>
>
Capabilities in general - the service is simply adding info to be
>
presented
> to users indicating things the
service is willing to commit to,
> and as such
>
would seem to be properly considered part of the Policy governing
> the
> publication and use of this
service by the Provider organization.
>
> Another path that might
make sense would be to model these XACMLAssertions
> as xacml:Obligations,
whereby the "obligation" would be to inform the user
> of this Policy
info, which could be presented directly thru PEP access,
> if,
for
> example, the request was denied because something was missing that
might
> be in this category of info (i.e. this would allow the info to
provided
> either
> in advance via WS-Policy or on the spot in a
"1-step" manner).
>
> I think the above or parts of it might be
considered guidelines for a
> possible
> proposal and explanatory
context for what might be considered to be added
> to the profile, but it
probably needs to be shaken out a bit, assuming that
> you and/or others
think it's valid subject matter for this profile.
>
> Also, I think
it is possibly in synch with your proposal. i.e. it looks
> to me like we
are
> generally on the same path - ex. where you pointed out section 3.2
for
> containing
> Apply elements, I was considering those to be
the az-type requirements,
> and your
> site-specific naming
convention looks like it might be similar to the
> "flag" I
suggested
> to apply to items in existing policies.
>
>
Thanks,
> Rich
>
> Anne Anderson
- Sun Microsystems wrote:
>
>> Hi Rich,
>>
>>
Thanks for the endorsement.
>>
>> As for identifying WS-XACML
policies, I had not considered the
>> problem, but it sounds like
proposals might be useful.
>>
>> What occurs to me is to have
all WS-XACML policies collected into a
>> special PolicySet that is
combined with other internal
>> PolicySets/Policies so all are
evaluated if necessary to reach a result.
>>
>> The WS-XACML
PolicySet could have an identifier that uses a special
>>
site-specific naming convention: e.g.
>>
urn:somecompany:...:xacmlauthzassertion:policyset:20
>>
>>
Isolated <Apply> elements don't occur in normal XACML, so for
>>
Requirements, they should be expressed as a Policy in the form
>>
described in Section 3.2. For Capabilities, they should be expressed
>> as a similar Policy, except using ...:function:or rather than
>> ...:function:and to combine the <Apply> elements (I will add
this
>> equivalence to the next Revision). Again, a
site-specific naming
>> convention could be used to notify the
XACML...Assertion builder that
>> the <Apply> elements from that
policy MAY be extracted: e.g.
>>
urn:somecompany:...:xacmlauthzassertion:requirements:25
>>
urn:somecompany:...:xacmlauthzassertion:capabilities:25
>>
>>
Requirements and Capabilities that "go together" could be put into
>>
individual PolicySet instances inside the "WS-XACML
PolicySet".
>>
>> That certainly isn't a complete solution,
and I need to think more
>> about using Capabilities in a standard
XACML policy, but maybe this is
>> a start.
>>
>>
Regards,
>> Anne
>>
>> Rich Levinson wrote On
12/15/06 16:57,:
>>
>>> Hi
Anne,
>>>
>>> I just want to mention that I think the
profile is a great document
>>> and a really valuable example of how
XACML can be applied.
>>>
>>> I quickly looked over your
suggestion and I think I must not have
>>> expressed my point
clearly.
>>>
>>> What I am thinking is that these
XACMLAssertions, both the
>>> XACMLAuthzAssertion and the
XACMLPrivacyAssertions are
>>> elements that can be included in a
ws:Policy elements and used
>>> in wsdl and other policy containers
to express the requirements
>>> to clients as to what they need to
do to successfully access the
>>> web service. I think we probably
agree on that, and, if so, then
>>> I can get to what the issue is
that I am considering.
>>>
>>> I would expect (correct
me if I am wrong, but this is what I am
>>> thinking) that it is
perfectly reasonable, if not likely, that these
>>> XACMLAssertions
will be part of an overall xacml architecture
>>> in various
enterprise environments. As such, it is likely that
>>> there are
one or mores PDP out there in the enterprise that are the
>>> home
of a collection of xacml policies, as well as being the decision
>>>
points handling PEP requests.
>>>
>>> It is also my
expectation that this PDP (or at least the people who
>>> adminster
the PDP) will likely consider the Web Services to be
>>> Resources
that its policies in general will cover.
>>>
>>> So, I
put myself in the position of one of these PDP admins and
>>> ask
myself, how do I create a XACML Policy that will contain all
>>> the
info I want to govern the access to this web service Resource
>>>
(as suggested by the para 2 in section 4, etc.). What I am
thinking
>>> is that only a subset of this info should go to the
XACMLAssertions,
>>> which will end up in the wsdl, but the rest of
the info I want to keep
>>> private and just use at runtime to
validate and authorize requests and
>>> produce Responses
etc.
>>>
>>> So, the question is: how do I flag the
subset of XACML Policy info
>>> that is targeted for the
XACMLAssertions - I guess I am also assuming
>>> that the WebService
Manager, in whatever form it will take, will in
>>> general make a
XACMLRequest to the PDP to get the Policy or
>>> Policies governing
this Resource. That Manager would then need to
>>> be able to select
from the XACML Policy (as opposed to the WS Policy,
>>> which, on
the other hand, the Manager is populating for setup etc.) the
>>>
elements:
>>>
>>> <element
ref="*xacml:Policy*" minOccurs="*0*" maxOccurs="*1*" />
>>>
<element ref="*xacml:PolicySet*" minOccurs="*0*"
>>> maxOccurs="*1*" />
>>>
<element ref="*xacml:Apply*" minOccurs="*0*"
>>>
maxOccurs="*unbounded*" />
>>> <element
ref="*xacml-context:Request*" minOccurs="*0*"
>>> maxOccurs="*1*"
/>
>>>
>>> that can be moved from the xacml:Policy
data to the Capabilities and
>>> Resources
>>> elements
of the XACML*Assertion.
>>>
>>> So, I am wondering what
the original xacml:Policy, which I assume can
>>>
contain
>>> the source elements for these XACML*Assertions, will
look like and
>>> how one
>>> would go about selecting
the appropriate info therefrom.
>>>
>>> Bottom line is
that the examples you suggested below, appear to me to
>>> be
the
>>> final step of this process: i.e. some entity has put these
ws:Policy
>>> blocks as
>>> part of the wsdl or other
that the client encounters before making
>>> the
actual
>>> access. To use your first
example:
>>>
>>>
<Requirements>
>>> Has signed
license agreement
>>>
</Requirements>
>>>
>>> I would expect that
somewhere in the PDP policy store that a
>>>
xacml:Attribute
>>> might exist with an AttributeValue: "Has signed
license agreement",
>>> and that
>>> when one queries
the PDP for this xacml:Policy that they are able to
>>> obtain
this
>>> AttributeValue and put it in the Requirements element of
the ws:Policy.
>>>
>>> OK, so now hopefully that
explains how I am looking at this and maybe
>>>
there
>>> is some complete aspect to this that I am missing, that
will help
>>> explain it all.
>>>
>>>
Thanks,
>>>
Rich
>>>
>>>
>>>
>>>
>>>
Anne Anderson - Sun Microsystems wrote:
>>>
>>>> Hi
Rich,
>>>>
>>>> Thanks for the
feedback.
>>>>
>>>> Rich Levinson wrote On
12/15/06
14:05,:
>>>>
>>>>>
>>>>>
61. WS-XACML: How are the contents of
XACMLAuthzAssertions
>>>>>
represented in the base XACML
Policies
>>>>>
>>>>> (Submitted by:
*Rich*)
>>>>>
>>>>> Reading the spec, it
appeared to me that an important piece of info
>>>>> might be
missing (or either I missed it or it intentionally is not
>>>>> there, but that's the point of this issue). As an entry
point to
>>>>> this potential issue, consider statement in
Section 4, p 23, para
>>>>> 2, that
says
>>>>>
>>>>> "For security reasons, many
entities are unwilling to publish their
>>>>> complete
authorization and access control policies. Therefore, an
>>>>> XACMLAuthzAssertion </xacml/AuthzAssertion> MAY
not be a complete
>>>>> specification of an entity's
authorization and access control
>>>>> policy. A service MAY
choose to publish all or a subset of the
>>>>>
XACMLauthorization or access control policy it will apply with
>>>>> respect to particular policy
targets."
>>>>>
>>>>> How are the subsets of
the core xacml policies identified as to
>>>>> what should
and should not be made
public?
>>>>
>>>>
>>>>
>>>>
>>>>
It is completely site-dependent as to what is published and what
>>>> isn't. Particular trade/service communities (on-line
bookstores,
>>>> etc.) might standardize policy vocabularies to
be used in stating
>>>> XACMLAuthzAssertions or
XACMLPrivacyAssertions for their sites.
>>>>
>>>>
As an example, Sun certainly isn't going to publish its enterprise
>>>> policy. But consider some fictitious software
download site
>>>> maintained by Sun; for this site, Sun might
publish the following:
>>>>
>>>>
<wsp:exactlyOne>
>>>>
<XACMLAuthzAssertion>
>>>>
<Requirements>
>>>> Has signed
license agreement
>>>>
</Requirements>
>>>>
<Capabilities>
>>>> Provide
trial version
>>>>
</Capabilities>
>>>>
</XACMLAuthzAssertion>
>>>>
<XACMLAuthzAssertion>
>>>>
<Requirements>
>>>> Has signed license
agreement
>>>> Has paid for Level 3
support
>>>>
</Requirements>
>>>>
<Capabilities>
>>>> Provide current
production version
>>>>
</Capabilities>
>>>>
</XACMLAuthzAssertion>
>>>>
</wsp:exactlyOne>
>>>>
>>>> Would it help to
include an example like this?
>>>>
>>>> Also, it
would be of interest to
>>>>
>>>>> see some
example policies that contained entities that end up in
>>>>>
the Capabilities and Requirements sections of the Assertions. I am
>>>>> particularly interested in how privacy requirements
might be set up
>>>>> in the original policy since these are
generally not part of the
>>>>> authorization process, per
se', but possibly could be considered to
>>>>> be modelled as
XACML Obligations. Any guidance on this in reply to
>>>>>
issue or changes to doc would be much
appreciated.
>>>>
>>>>
>>>>
>>>>
Consider a service policy saying the service will provide a copy of
>>>> its current price list if the client agrees to retain it no
longer
>>>> than 30 days and not to disclose it to 3rd parties.
The service
>>>> also says it will not disclose the
client's personal information to
>>>> 3rd
parties.
>>>>
>>>>
<XACMLPrivacyAssertion>
>>>>
<Requirements>
>>>>
max-data-retention-days <= 30
>>>>
data-disclosure == "ours" }
>>>>
</Requirements>
>>>>
<Capabilities>
>>>>
resource-id="current-price-list"
>>>>
//p3p10full/POLICIES/POLICY/RECIPIENT/* subset-of { "ours"
}
>>>> </Capabilities>
>>>>
</XACMLPrivacyAssertion>
>>>>
>>>> A
client policy might say:
>>>>
>>>>
<XACMLPrivacyAssertion>
>>>>
<Requirements>
>>>>
resource-id="current-price-list"
>>>>
//p3p10full/POLICIES/POLICY/RECIPIENT/* subset-of { "ours"
}
>>>> </Requirements>
>>>>
<Capabilities>
>>>>
max-data-retention-days <= 30
>>>>
data-disclosure == "ours" }
>>>>
</Capabilities>
>>>>
</XACMLPrivacyAssertion>
>>>>
>>>> There is
another example using XACML's XML syntax in Section 6 of WD
8.
>>>>
>>>> Is this what you are looking for?
If you could describe ways in
>>>> which the examples in
Section 6 are inadequate, I could provide more
>>>> examples or
better
examples.
>>>>
>>>>>
>>>>>
Status: *OPEN*
>>>>>
>>>>
>>
--
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]