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

> > 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.

> 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.
> 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 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.

> 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.


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