most significant development in access control
recently is the OAuth family of protocols. Classic
ABAC brings all the attribute values and policies
together and makes one decision at a time whether
proposed requests should be allowed. In contrast,
OAuth creates a software token which contains
information about what the party presenting the token
is allowed to do. Initially this was used for explicit
delegation from one person to another, with a manual
approval in the middle. Since then, OAuth this has
been extended to cover delegation to hardware or
software components, such as an App or smart phone
acting on behalf of a user. It is also used to encode
in the token the rights to perform a number of
different requests which can then be approved one by
one without repeating the initial authorization steps.
offers potential benefits of enabling explicit
delegation, the ability to deal with multiple
components which are controlled by different entities
with potentially adverse interests (e.g. user, phone,
app and web service), the ability to approve multiple
requests from the same token, the ability to hide user
identity information from parties who don’t need it
and various kinds of performance benefits.
OAuth as it stands today does not address several key
issues. First, it is silent on how the authorization
server decides what permissions should be put in the
token. The format of the Scope, which is that part of
the token which says what is allowed, is unspecified.
This means a) that there has to be close cooperation
between an authorization server and the resource
servers it generates tokens for, and b) there is no
standard for code to interpret the Scope. This forces
applications back to all the bad practices of pre-ABAC
days. Authorization code is written in a high level
language and often intertwined with non-policy code.
Typically the allowed functionality is very limited.
OpenAz project examined OAuth and its potential
relationships to XACML from several angles. Rich
Levinson built a demonstration of how the OAuth
protocol logic can be drive entirely by XACML policies
which guard the different OAuth handshakes.
made proposed a scheme where XACML policies themselves
(in a more compact JSON format) could be used to
express OAuth Scope, but omitting the Subject
information. This could be done either by having
simple rules for providing certain policies for
certain users, or perhaps by using an XACML PDP to
evaluate policy and then tell us what policies were
used. In either case, the resource server can pass the
policies from the Scope to a PDP rather than have to
invent some new scheme.
believe work like the above and other future efforts
will lead to a deeper understanding of the ABAC and
token models and what their relationships are. I see a
need to have systems which allow consistent policy
_expression_ and governance across the enterprise,
regardless of the handshake used.