The Community Authorization Service:

Status and Future

Ian Foster1,2, Carl Kesselman3, Laura Pearlman3, Steven Tuecke1, Von Welch2

1Argonne National Laboratory, Argonne, IL2University of Chicago, Chicago, IL3USC Information Sciences Institute, Marina del Rey, CA

March 24, 2003 CHEP03 2

Outline

Classic Globus Authorization CAS Concepts CAS Implementations (Prototypes and

Planned Release Version) CAS and the Globus Toolkit Future Work

March 24, 2003 CHEP03 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.

March 24, 2003 CHEP03 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.

March 24, 2003 CHEP03 5

CAS Concepts

Policy Management Policy Enforcement Operations and Deployment

March 24, 2003 CHEP03 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.

March 24, 2003 CHEP03 7

CAS Policy Management: the Resource Provider’s 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.

March 24, 2003 CHEP03 8

CAS Policy Management: the Community’s 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 server’s 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

March 24, 2003 CHEP03 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.

March 24, 2003 CHEP03 10

A Typical CAS Authorization Sequence

A client requests credentials from a CAS server. The CAS server replies with credentials, based on

the community’s 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.

March 24, 2003 CHEP03 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 user’s behavior.

March 24, 2003 CHEP03 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.

March 24, 2003 CHEP03 13

Initial CAS Prototype

Based on restricted proxy certificates. A restricted proxy certificate grants a

subset of the issuer’s rights to whoever holds the certificate.

The end-user’s identity is not part of the restricted proxy.

Servers that don’t understand restricted proxies reject them.

March 24, 2003 CHEP03 14

Restricted Proxy Certificate

Subject: /O=Grid/CN=VO CAS Server

Valid: 3/25/03 13:00 – 3/25/03 15:00

Proxy Certificate conveys the VO’s

rights to the bearer, for the

certificate’s validity period

ProxyRestrictions (critical extension)

Only these actions are allowed:

Read gridftp://myhost/mydir/*

Write gridftp://myhost/myfile

Signature (of all above, by the VO CAS Server)

Restricted

subject to the proxy restrictions

March 24, 2003 CHEP03 15

A Typical CAS-alpha1 Request

CAS Server

What rights does the communitygrant to this user?

Client

Resource Server

Do the proxy restrictions authorize this request?

CAS-maintainedcommunity policy

database

User proxy

Community proxy

Community proxy Local policyinformation

Proxy restrictions

Proxy restrictions

Is this request authorized for the community?

March 24, 2003 CHEP03 16

Effective Policy in CAS-alpha1

AccessGranted byCommunity

To user

AccessGranted by siteTo community

Effective access

March 24, 2003 CHEP03 17

Second CAS Prototype

Based on policy assertions signed by the CAS server.

The policy assertions associate a set of access rights with the user’s identity.

Servers that don’t understand policy assertions ignore them and base authorization decisions on the user’s identity alone.

Servers can implement an additional level of policy enforcement based on user’s identity, if desired.

March 24, 2003 CHEP03 18

Signed Authorization Assertions

Subject: /O=Grid/CN=Laura

Valid: 3/25/03 11:00 – 3/26/03 11:00

AuthorizationAssertion (non-critical extension):

Target Subject: /O=Grid/CN=Laura

Valid: 3/25/03 13:00 –15:00

These actions are allowed:

Read gridftp://myhost/mydir/*

Signature (of assertion, by the VO CAS server)

Signature (of all above, by the user)

It is only valid when used along with the target

user’s authentication

credentials.

The authorization assertion is signed

by the VO’s CAS server. It

delegates a subset of the VO’s rights to a user, during a

validity time.

March 24, 2003 CHEP03 19

A Typical CAS-alpha2 Request

CAS Server

What rights does the community

grant to this user?

Client

Resource Server

CAS-maintainedcommunity policy

database

User proxy

Local policyinformation

User proxy

Does the policy statement authorize the request?

What local policy applies to this user?

Is this request authorized for the community?

Policy statementCommunitySignature

Policy statementCommunitySignature

March 24, 2003 CHEP03 20

Effective Policy in CAS-alpha2

AccessGranted by siteTo community

AccessGranted by community

To user

Maximum AccessGranted by site

To user (e.g., via blacklists, whitelists)

March 24, 2003 CHEP03 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.

March 24, 2003 CHEP03 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.

March 24, 2003 CHEP03 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

March 24, 2003 CHEP03 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

March 24, 2003 CHEP03 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.

March 24, 2003 CHEP03 26

For More Information

CAS web page : “http://www.globus.org/Security/CAS”