The Community Authorization Service: Status and Future

1
The Community Authorization Service Status and
Future

• Ian Foster1,2, Carl Kesselman3, Laura Pearlman3,
  Steven Tuecke1, Von Welch2
• 1Argonne National Laboratory, Argonne, IL
• 2University of Chicago, Chicago, IL
• 3USC Information Sciences Institute, Marina del
  Rey, CA

2
Outline

• Classic Globus Authorization
• CAS Concepts
• CAS Implementations (Prototypes and Planned
  Release Version)
• CAS and the Globus Toolkit
• Future Work

3
Classic Globus Authorization

• Unix accounts and gridmap file entries.
• The operating system acts as a sandbox services
  themselves (e.g. gridftp, gram) do not make their
  own authorization checks.
• Easy for site administrators to understand and
  verify.

4
Limitations of Classic Globus Authorization

• Scalability each personnel or policy change
  requires changing policy at each participating
  site.
• Expressivity native OS methods may not be
  expressive enough to support VO policies.
• Consistency native OS methods at different sites
  may not support the same kinds of policies.

5
CAS Concepts

• Policy Management
• Policy Enforcement
• Operations and Deployment

6
CAS Policy Management

• Sites maintain site policies communities
  maintain community policies.
• Site policies are maintained using existing
  methods (e.g., gridmap files and unix accounts).
• Community policies are maintained using the CAS
  server and CAS administrative protocol.
• Sites are not required to manage policy for
  individual community users or groups.

7
CAS Policy Management the Resource Providers
View

• The resource provider grants access to a block of
  resources to a community, using their existing
  access-control mechanism for that resource (e.g.,
  grid-mapfile entries, file permissions, etc.).
• The resource provider uses native mechanisms
  (e.g. quotas) to set additional policy for the
  community as a whole.
• The resource provider then installs servers
  modified to enforce the policy in the CAS
  credentials.

8
CAS Policy Management the Communitys View

• CAS administrative requests are used to maintain
  the CAS community policy database, which
• controls what rights the CAS server will grant to
  which users.
• controls the CAS servers own access control
  policies, and thus can be used to delegate the
  ability to grant rights, maintain groups, etc.
• maintains the list of community members

9
CAS Policy Enforcement

• Sites enforce site policies and community
  policies.
• A resource server (e.g., gridftp, gram) may
  recognize several CAS servers.
• A resource server may accept CAS authorization
  for some resources but not others.
• Resource servers (and clients) do not need to
  contact the CAS server for each request but
  they do need fairly recent CAS information.

10
A Typical CAS Authorization Sequence

• A client requests credentials from a CAS server.
• The CAS server replies with credentials, based on
  the communitys policy for that client.
• The client presents the CAS credentials to the
  resource server, which uses them in making policy
  decisions. This step may be repeated many times
  using the same credentials.
• This slide intentionally left vague.

11
Two Typical Client Scenarios

• A community user can
• Run a client program to get CAS credentials, then
• Use a simple wrapper script to run unmodified
  (gsi) client applications.
• An application can be modified to interface
  directly with the CAS, with no change to the
  users behavior.

12
CAS Implementations

• Initial CAS Prototype
• Based on restricted proxies
• Second CAS prototype
• Based on signed policy assertions
• Upcoming Release Version
• Conceptually similar to second prototype, but new
  code base, protocol, and assertion formats.

13
Initial CAS Prototype

• Based on restricted proxy certificates.
• A restricted proxy certificate grants a subset of
  the issuers rights to whoever holds the
  certificate.
• The end-users identity is not part of the
  restricted proxy.
• Servers that dont understand restricted proxies
  reject them.

14
Restricted Proxy Certificate
Subject /OGrid/CNVO CAS Server Valid 3/25/03
1300 3/25/03 1500
Restricted
Proxy Certificate conveys the VOs rights to the
bearer, for the certificates validity period
ProxyRestrictions (critical extension) Only these
actions are allowed Read gridftp//myhost/mydir/
Write gridftp//myhost/myfile
subject to the proxy restrictions
Signature (of all above, by the VO CAS Server)
15
A Typical CAS-alpha1 Request


CAS Server



CAS-maintained community policy database
User proxy
What rights does the community grant to this
user?


Community proxy



Proxy restrictions

Client

Resource Server


Local policy information

Is this request authorized for the community?
Community proxy

Proxy restrictions

Do the proxy restrictions authorize this request?



16
Effective Policy in CAS-alpha1
Effective access
17
Second CAS Prototype

• Based on policy assertions signed by the CAS
  server.
• The policy assertions associate a set of access
  rights with the users identity.
• Servers that dont understand policy assertions
  ignore them and base authorization decisions on
  the users identity alone.
• Servers can implement an additional level of
  policy enforcement based on users identity, if
  desired.

18
Signed Authorization Assertions
Subject /OGrid/CNLaura Valid 3/25/03 1100
3/26/03 1100
The authorization assertion is signed by the VOs
CAS server. It delegates a subset of the VOs
rights to a user, during a validity time.
AuthorizationAssertion (non-critical
extension) Target Subject /OGrid/CNLaura Valid
3/25/03 1300 1500 These actions are
allowed Read gridftp//myhost/mydir/ Signature
(of assertion, by the VO CAS server)
It is only valid when used along with the target
users authentication credentials.
Signature (of all above, by the user)
19
A Typical CAS-alpha2 Request

CAS Server



CAS-maintained community policy database
User proxy

What rights does the community grant to this
user?






Resource Server
Client



What local policy applies to this user?

User proxy
Local policy information

Policy statement
Does the policy statement authorize the request?
Community Signature


Is this request authorized for the community?


20
Effective Policy in CAS-alpha2
Access Granted by site To community
Access Granted by community To user
Maximum Access Granted by site To user (e.g., via
blacklists, whitelists)
21
CAS Release Version

• Conceptually similar to CAS-alpha2
• New code base (java)
• OGSA service based on GT3
• Will use SAML for policy assertion format.

22
CAS and the Globus Toolkit

• Production version will include
• CAS server (GT3/OGSI Service)
• CAS client, java client API, and (maybe) C client
  API
• CAS-aware gridftp server
• APIs to facilitate CAS-ifying other services.
• To be released with or following GT3 in June
• An upcoming GT2 release will include a CAS-aware
  gridftp server.

23
Future Work Scalability

• Caching Server
• Acts as a lightweight partial mirror of a CAS
  server
• Accepts requests for what to mirror (e.g., policy
  for a particular user) and periodically requests
  new signed policy statements from a CAS server
• Distributed community policy database

24
Future Work CAS Operation

• Support request-server-pull model (request
  server, rather than client, contacts CAS server)
  in addition to current model
• Can be combined with caching server for
  performance and reliability

25
Future Work Policy Enforcement

• Local Authorization Server accept authorization
  queries from request servers, applies all
  applicable local and community policies, and
  returns yes or no.
• Increased support for authorization in GT3
  hosting environments.

26
For More Information

• CAS web page http//www.globus.org/Security/CAS