Claims Come in Many Flavors
As
the quote from Butler Lampson emphasizes, access
control for any valuable resource on a computer must
ultimately be determined at that computer. Sounds
simple enough, but as any IT manager will tell you,
managing access control in such a granular way
across a diverse network environment is expensive
and error prone. However, claims-based authorization
technologies have shown promise in reducing that
complexity and risk. This article describes where IT
is today and how claims technology allows IT to
overcome the limitations of currently deployed
systems.
Most existing access control systems depend on two
steps, authentication of the user and authorization
of access rights. This simple model worked well for
a reasonably large collection of users at any one
enterprise accessing resources within that
enterprise.
Two trends are making this model difficult to
sustain. First, we find an increasing number of
government and enterprise rules on who can access
information, in what location, and at what date.
Second, we find that partnering on projects across
company boundaries is increasingly common. Users
with a legitimate business need to access enterprise
assets do not have a known identity within that
enterprise. The result is that a single user in a
large enterprise belongs to many project-specific
security groups, has multiple credentials at the
various companies whose resources need to be
accessed, and may not even be an actual employee of
any of them. Existing authorization tools don’t
handle this well.
Role-based Access Control (RBAC) was one solution to
this growing problem, allowing the IT administrator
to assign users to roles on a temporary basis.
Implementation has proved to be problematic, though.
At its simplest, the RBAC concepts can be
implemented with security groups. Unfortunately, in
practice, at scale, the resulting list of security
groups grows large. Furthermore, even with RBAC in
place, establishing trust across organizational
boundaries remained a separate problem.
In response to this need, the OASIS security team
created the Security Assertion Markup Language (SAML)
for cross-organizational use. While early
implementations suffered from bloated user tokens
and an overly complex standard, more recent efforts
focus on providing only those claims immediately
useful to a given service or resource. In this
model, the resource owner specifies a policy that
mandates a set of user capabilities. The necessary
claims are packaged inside a token that is small
enough to fit into web URLs and cookies (thereby
supporting RESTful web services, for example). This
token is then signed by a Security Token Service
(STS) that is trusted by the line of business
service and/or its access control solution (see the
following figure).

Typically, claims included in the authorization
token consist of data about the user and the user’s
computer (or mobile device). The claims data are
collected from a variety of sources, including
traditional authentication services provided by
Kerberos, for example, or social identity providers
like Windows Live or Facebook. Each claim in the
token is one datum describing an attribute of the
user or computer that is useful to an access control
process. A user claim will be an attribute such as
the user name, email address, physical address, or a
role that the user is assigned. The resource owner
can specify a list of acceptable identity providers
for the user’s selection as well as a list of
required claims.
JW Secure has built a variety of claims-based
authorization solutions for our customers that
combine requirements policies from resource owners
and identity providers with user’s privacy desires.
These solutions enable users to experience nearly
friction-free access to resources while strictly
enforcing the needs of the resource owners such as:
physical location of the client, specific role of
the user, time-of-day, security setting on the
client computer, two-factor user authentication and
other custom requirements mandated by governance
regulations.
Further reading:
|