OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] Using XACML Policies to Express Scope in OAuth



Hi Hal,

On 21/06/2013 5:33 AM, Hal Lockhart wrote:
Hal:
In my scheme, the Authorization Server will provide a complete
Request Context in the (Requested) Scope parameter. The Authorization
Server will use the actual Subject Attributes of the authenticated
party (typically the Resource Owner) and fill in values for Resource,
Action and Environment which would be typical for an access using the
Authorization Token. In most cases, environmental values will not
matter, so the default of "right now" will be fine. In rare cases, the
might have to be some tweaking between the Policies and the Request
Context to get the policies desired, but usually if the intent is to
allow all access to Joe's files it will be sufficient to ask to write
one file in Joe's folder.


Steven:
I think it is dangerous to base all access within the requested scope
on the result of one specific case. Suppose there is some other file in
Joe's folder that Joe is not permitted to write and that there is an
XACML policy that denies write access to this file by Joe. This policy
won't be applicable for the request context that was used and so will
be left out of the issued scope. This means that the bearer of the
access token will be able to write the file that Joe cannot.

The intent has also gone missing here. If the intent were to allow only
write access to Joe's files, or if the intent were to allow any access
to any of Joe's resources (i.e., not just his files), then the same
request context is a valid specific case and the issued scope would
still be the same. Clearly it shouldn't be. The requested scope has to
get factored into the issued scope in some form.

First I would say that pathological cases like the one you mentioned can be avoided by careful coding of the policy. For example, the negative policy could appear within a different Rule in the same Policy or within a Condition in the same Rule.

I am not claiming that you can just do the procedure I outlined over any existing set of policies and it will just work right. For now at least, I am only claiming that a) you can use XACML policies to express scope and b) that you can use an XACML request context and a PDP to tell you what policies to use.

I think in many cases, there may be a single policy which covers all the OAuth sub cases, which would allow the AS to use the PDP merely to determine if any Token can be issued. Then it would only be necessary to decapitate the policy.

At the other end of the scale, the AS could use a multi-decision request to cover most or all of the individual situations and then collect all the policies applicable to all the decisions.

Steven:
Policies can contain sensitive information in the form of user and
resource identifiers, among other things, that shouldn't be made
public though a decapitated policy. We would probably need to be
explicit about how the request context is incomplete so that
sensitive expressions that are irrelevant to the requested scope get
removed.
Maybe we would need to encrypt the decapitated policies for the
intended authorization server just to be safe.

Hal:
This is a valuable point. However the situation is much the same as
when some sort of Attribute Assertion is used as a Scope.

Steven:
More serious I think. Attribute assertions will be about the specific
entities involved in particular access attempts. If we're not careful,
the information that leaks out in the issued scope of an access token
could be about entities that are not, and never will be, involved in
accesses using that token.

Generally there are two subjects involved, the Resource Owner and the Client. The Client presents the Token, so its Identity, if it appears, is appropriate. The Attributes of the Resource Owner are the ones which are made constant by the decapitation process. In cases like my first example, the expression containing the Resource Owner's Subject Attributes will be completely removed by decapitation. In my second example, an Attribute value remains, but it is needed to specifically identify the Resources access is permitted. For example, if Mary is giving John access to her files, the policy has to specify what constitutes "Mary's files". This will typically involve Mary's username, which is not particularly privacy sensitive. I assert without proof that Privacy sensitive Attributes will tend to disappear under optimization since they will usually be employed in a direct Boolean test. Do you have a counter example in mind?

The attribute identifiers of the Resource Owner disappear but the values
can linger on. Suppose there is a rule like this:

	Permit if ... and (access.subject.clearance = resource.classification)

This will reduce to:

	Permit if ... and ("Secret" = resource.classification)

giving away Joe's clearance level. Any comparison between an access-subject
attribute and an attribute in another category has the potential to reveal
access-subject information that isn't relevant to the requested scope. You
would have to ban such comparisons in expressions in your solution if the
tokens aren't encrypted or if the Resource Server can't be trusted with the
information.

However, I was thinking more of something like this:

	Permit if ... and (access-subject.id = "Joe")
	              and (resource.id = "Plan to Outsource the Call Center to India")

which reduces to:

	Permit if ... and (resource.id = "Plan to Outsource the Call Center to India")

giving away the existence of such a plan (which isn't one of Joe's files).
The rule could instead be:

	Deny if ... and not (access.subject.subject-role = "Board Member")
	            and (resource.id = "Plan to Outsource the Call Center to India")

which reduces to:

	Deny if ... and (resource.id = "Plan to Outsource the Call Center to India")

if Joe isn't a board member, giving away the existence of a plan that even Joe
doesn't know about.

Even if privacy isn't an issue, stripping out the irrelevant stuff is still desirable
from the point of view of minimizing the token size.

Regards,
Steven


Hal:
  > The Attribute values may sensitive for privacy or other reasons. I
think this is better dealt with by protecting i.e. encrypting,
sensitive data rather than trying to architect it out of existence. The
OAuth specs will permit encryption using JOSE (JWE). I think this
should simply be a deployment option.


Steven:
It depends on how much the Authorization Server trusts the Resource
Server.
Encryption prevents the bearer seeing stuff they shouldn't, but not the
Resource Server. Stripping out irrelevant stuff limits how much the
Resource Server sees.

Most current deployments of OAuth 2.0 not only assume the Authorization Server and the Resource Server are in the same Security Domain but even that they communicate via unspecified back channels, so I don't think they worry about privacy distinctions between them. However, my intent is that the decapitation and optimization steps are sufficient to remove all the attributes of the Resource Owner, except those necessary to identify the permitted access.

Hal




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]