# Presentation: 439260

## Using CAS to ManageRole-Based VO Sub-Groups

*Shane Canon (LBNL), Steve Chan (LBNL), Doug Olson (LBNL), Laura Pearlman (ISI), Craig Tull (LBNL), Von Welch (ANL)*
**CHEP 2003 - March 25, 2003**
**UCSD - La Jolla, CA**

## Outline

- Introduction and Motivation
- CAS Overview & Architecture
- Rights Granularity
- Prototype Project Description
- Goal of Prototype
- Installation & Setup
- Execution & Use
- Summary, Analysis, and Conclusion
- Suitability of CAS
- Future Plans

## A Quick Refresher

**Grid Security Infrastructure (GSI) =**
**   ****X.509 (PKI certificate format)***
**+ proxy certificates (single sign-on & delegation)**
**+ TLS/SSL (authentication & msg protection)***
**+ delegation protocol (remote delegation)**
*** = Existing IETF standards**
**Others are GGF & IETF drafts**
**A (X.509) proxy certificate is used by an entity to delegate all or part of its own authority.**

## Community Authorization Service

**CAS is authorization product of Globus project.**
**In the CAS model, resource providers grant access to blocks of resources to a community as a whole, and the community uses a CAS server to perform fine-grained access control on those resources.**
**Resource providers grant course-grained access to communities.**
**Communities run CAS servers, which keep track of fine-grained access control information and grant restricted proxies to community members.**
**The result is that a CAS user gets the intersection of the rights granted by resource provider to the community and the rights granted by the community to that user.**

## CAS Architecture in action

- Proxy w/CASassertion

- cas-proxy-init

- gridftp client
- (unmodified)

- gridftp server
- (modified to
- do CAS
- authorization)

- Authorization
- Libraries

- CAS architecture
- in action

- CAS Server

- Gridftp Server

- CAS Server

- Request

- Response

- Assertion

- Assertion

- Assertion

- Query

- Response

- User

**CAS Architecture in action**

## CAS Proxy Format

**CAS Proxy Format**

- Assertion

- DN: /C=US/CN=Some User/Proxy
- Issuer: /C=US/CN=Some User
- Expires: 11am March 26, 2003
- Signature: 76A97....
- ...

- Usual user proxy information

- Non-critical extension:

- Assertion

- Issuer: /C=US/CN=VO CAS
- Signature: 76BE3...
*(List of Object – Right)*
- /VO/Admingroup   Member
- /foo.edu/file   Read

**Notes:**
Assertion has own signature – signed by the CAS that issued it.
Assertion includes CAS certificate for signature verification.
Assertion is really a separate thing from the certificate, it is just carried in the certificate as a matter of convenience

## Rights granularity

**Typical granularity of Grid rights architecture addresses 2 levels:**
**Individual - immutable**
**VO - 100s-1000s of individuals (entire experiment)**
**Experiments have intermediate granularities:**
**Groups - Detector or Physics groups**
**Roles - One or more individuals fulfilling a single role. Individuals may change over time.**
**EG: Release Coordinator, Production Manager, etc.**

## Goal of Project

**PPDG Project to test Globus Community Authorization Service **
**Standard usage of CAS**
**Access to file resources (via GSIFTP)**
**Extension of CAS Resource Authorization**
**Define Roles as Resource**
**Demonstrate 1 individual (1 DN) assuming multiple different roles**
**Demonstrate multiple individuals (different DNs) assuming the same role**
**Demonstrate individual divesting role(s)**

## Policy Granularity:Groups vs Capabilities

- User is in
- group Y

**Policy Granularity:****Groups vs Capabilities**

- Capability assertion:
- Expresses right completely

- User can access resource
- (e.g. file, CPU) X

- Group Assertion:
- Expresses an attribute.
- Must be converted to right
- by local policy.

- Local Policy

- Group Y can access
- resource X

- Local Domain

- Policy
- Enforcement
- point

- Resource
- X

**Notes:**
The point here is that with a capability you don’t have any policy in the local domain. All policy is centralized in CAS.

## Testbed Setup

**Three nodes: pdsfgrid3, globicus, globzilla**
**CAS server: pdsfgrid3**
**Client: globzilla/globicus**
**Grid FTP server with CAS extensions: globicus**
**Ran on alternate port**
**Verified that IP filters and hosts.allow were correct**

- Grid3

- Globzilla

- Globicus

- Client

- CAS server

- GridFTP server

## CAS as a Role Manager	

**Installed patched version of CAS-enabled FTP server**
**Add the action “group” and the service “member” into the CAS database**
**Create objects for the various groups/roles**
**Grant member privileges to members of the various groups/roles**
**User request specific capabilities from the CAS server to determine role**

## CAS Authorization for Groups

**CAS Authorization for Groups**

- Gridftp
- server

- Authorization
- Libraries

- group
- map
- file

- grid-
- mapfile

- Assertion

- List of groups

- 1. Parse assertion

- 2. Map group to local accounts

- Group name

- Account

- CAS DN

- Accounts

- 3. Make sure
- CAS can legally
- map to local account

**Notes:**
First, this slide is a little bit of a lie, what we actually do, is read the group-mapfile and then query the authorization libraries for each group to see if the user is a member. This is because the authz libraries are set up in a query/response semantic and not a “give me all the rights” semantic.
Step 1: Use existing authz libraries to parse assertion. Get list of groups user is a member of.Step 2: Try groups in order, first one that matches (and is legal by step 3) is used.
Step 3: CAS DN must be allowed to map to account as returned by group-mapfile. This maintains grid-mapfile as ultimate authority for account mappings on the system.

## Changes to Gridftp server

**Normal gridftp server checks grid-mapfile to determine local account**
**Modified gridftp server to check for CAS assertion**
**If present, check for group memberships**
**If present, check for group memberships in local mapping file**
**If present, check legality and use group mapping instead of grid-mapfile**

## CASGUI

- Privilege Groups

- User with permissions

## CASGUI

- User List

- User Details
- (eg Cred)

- atlas-data
- Role

- atlas-admin
- Role

## Prototype Experience

**Extends standard CAS installation which is well documented although involved.**
**Installation was straight forward, even without full a GPT package**
**Sample CAS script to create objects would simplify things for first timers.**
**Some minor bugs found in CAS tools.  Correction are being sent to developers.**

## CAS User Session

**Initialize Grid certificate**
**% grid-proxy-init**
**Your identity: /O=doesciencegrid.org/OU=People/CN=Craig E. Tull 49565**
**Enter GRID pass phrase for this identity:**
**Creating proxy .................................................. Done**
**Your proxy is valid until Wed Mar 19 20:30:53 2003**
**Initialize 1 CAS certificate for each Role**
**% cas-proxy-init tull**
**% cas-proxy-init -f admin admin**
**% cas-proxy-init -f data data**
**Use Role Tag to connect**
**% cas-wrap data gsincftp -P 2813 pdsfgrid3**
**NcFTP 3.0.3 (April 15, 2001) by Mike Gleason (ncftp@ncftp.com).**
**Connecting to 128.55.24.28...                                                           **
**pdsfgrid3.nersc.gov FTP server (GridFTP Server 1.0 -- CAS enabled [GSI patch v0.5] wu-2.6.2(2) Wed Mar 5 17:42:41 PST 2003) ready.**

- # file containing Role privileges
- group member atlas/admin wildcard
- file read ftp://pdsfgrid3.nersc.gov/* wildcard

- Role Tag

- Role Tag

- Command to wrap

## Lessons Learned

**Feature in CAS DB to allow for easy definition of different objects and actions works as planned.**
**Current CAS authorization API needs extensions to easily handle mapping of user to local accounts and/or groups**
**Currently allows for queries  of type “Is user in group X?”**
**Need to allow for “What account should user be in?”, “What groups should user be in?”**
**User may also specify an account, leading to query of form “Can user access account Y?” **

## Future Plans

**Mainline CHEP demo code into CAS?**
**Von - This is a question for you.**
**Extend Globus Gatekeeper for Job Submission**
**Similar code extension to that for FTP server.**
**Standardize service assertion format.**
**This would allow single Grid FTP server or Gatekeeper for CAS and other, similar tools (eg VOMS)**
**Exploration of CAS/Akenti cooperation**
**Akenti for local resource authorization**
**CAS for global (eg VO-wide) individual and role-based authorization**

## END OF PRESENTATION