-----Original Message-----
From: Anthony Nadalin [mailto:tonynad@microsoft.com]
Sent: Wednesday, June 19, 2013 11:06 AM
To: Steven Legg; Hal Lockhart
Cc: xacml@lists.oasis-open.org
Subject: RE: [xacml] Using XACML Policies to Express Scope in OAuth
This seems a little much as scopes are to be simple, not complex,
scopes will also have to be understood/recognized by the client/user
agent in addition to the authorization server that mints the tokens
and refresh tokens, which makes this more complex
-----Original Message-----
From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org]
On Behalf Of Steven Legg
Sent: Tuesday, June 18, 2013 10:54 PM
To: Hal Lockhart
Cc: xacml@lists.oasis-open.org
Subject: Re: [xacml] Using XACML Policies to Express Scope in OAuth
Hi Hal,
On 19/06/2013 4:52 AM, Hal Lockhart wrote:
Thanks for taking a look at what I wrote.
Hal:
"The good news is we can use an XACML PDP to select the
policies for us. Normally we call the PDP,
providing Attribute values and it tells us if the access is
permitted or not. In XACML 3.0 a feature was
added which allows the PEP to optionally request the
Identifiers
of the policies that were applicable to
the decision. We can then obtain these policies from the
policy repository and use them as the Issued
Scope."
Steven:
I don't believe this will work as you expect. At this point we have
an incomplete request context. Some attributes of the eventual
resource access aren't necessarily known, such as the action or the
time of day.
If we leave out the unknown attributes we may get from the PDP a
different result with a different list of applicable policies and
policy sets than what we would get from the PDP using the full
request context with the actual values of the unknown attributes
applying at the time the resource access actually occurs.
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.
I did realize there is one additional step I omitted. If any of the
Policy Sets among those which are Applicable contain Policy References
to Policies which are not Applicable, it will be necessary to
eliminate these references.
Steven:
The XACMLPolicyQuery from the SAML profile is closer to what's
needed, since it takes a request context and returns policies and
policy sets, but it will only work if the implementation operates
on the assumption that the request context may not be complete.
Hal:
The policy query is a source of some embarrassment to me. Originally
it contained stipulations which cannot be met, such as comparing two
targets to see if they are equal. Now it can work but is intended for
a usecase I now believe is non-existent, namely a PDP which does not
have enough volatile or non-volatile storage to hold all the policies
currently in effect (Active Cohort) and has to obtain them over the
network for each decision. The original intent was that the repository
would check only Targets, thus returning a set of possibly applicable
policies. As written the Profile lets you do that or even have the
repository fully evaluate the policies. This would result in a double
evaluation and a message exchange for every decision.
Given that regardless of the format used to represent policies, it
is
hard to see how even a large set of policies could be large than a MB
or two, which these days is a trivial amount of space even for a cell
phone. In any event, the query would need a complete Request Context
just as the normal decision does.
Steven:
I think it would be appropriate to define a new PDP operation that
takes an incomplete request context and returns a set of
"decapitated"
policies and policy sets, perhaps best wrapped up in a single
policy set.
Hal:
This may make sense when we understand the details better. I suspect
that not only the Request Context contents, but also the specific
Attribute Categories which get made constant may vary a bit, depending
on the precise OAuth flow being used and perhaps other factors as
well. For starters I think it will be better for the required
additional functionality to exist in the Authorization Server which
calls an off-the-shelf PDP.
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.
> 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.
Regards,
Steven
Steven:
On page five you say:
"Currently XACML PDPs do not support the input of policies with
decision requests except in the
context of the Admin/Delegation Profile. This will need to be
relaxed."
Of course that should be "in the context of the SAML Profile".
Hal:
Our assumption (in specifying 3.0) was that just in time policies
would be supported by imbedded PDPs. We just did not see the need to
standardize how they were presented to the PDP. In particular, it was
not clear what format the policies should be in. (XML, JSON, internal
binary) I believe all the processing to prepare the scope will need to
happen locally, so this needs to be added to the OpenAz interface.
I am trying to strike a balance between using existing pieces as is
and defining a solution which has reasonable performance. I may get it
wrong, so I welcome comments.
Hal
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php