1. DGC Paris 4.03.02 Community Authorization Service (CAS) and EDG Presentation by the Globus CAS team & Peter Kunszt, WP2

2. DGC Paris 4.03.02 2 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

3. DGC Paris 4.03.02 3 X.509 Proxy Certificates A proxy certificate is used by an entity to delegate all or part of its own authority. –A proxy certificate is a special type of X.509 certificate that is signed by a normal end entity cert (or by another proxy). –A proxy certificate grants the bearer (whoever knows the private key) some or all of the issuing entity’s authority.

4. DGC Paris 4.03.02 4 Unrestricted Proxies An unrestricted proxy certificate delegates all of the issuer’s authority. –Supports single sign-on & delegation through “impersonation” –Relying parties grant the same rights to an unrestricted proxy certificate that they would to the entity that issued the proxy (subject to any additional local policy) –“grid-proxy-init” creates an unrestricted proxy certificate –This is what is in current (2.0) Globus software.

5. DGC Paris 4.03.02 5 Restricted Proxies A restricted proxy delegates a subset of the issuer’s authority. –A restricted proxy cert contains a policy statement limiting what that cert can be used for. –Relying parties authorize requests only if the request would have been granted for the proxy’s issuer, and the request is consistent with the policy embedded in the cert, and any additional local policy requirements are met. –Thus, a restricted proxy grants (at most) the intersection of the issuer’s rights as granted by the local policy and the rights granted by the proxy’s embedded policy.

6. DGC Paris 4.03.02 6 Community Authorization Service 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.

7. DGC Paris 4.03.02 7 A Typical CAS Request 2.CAS reply, including restricted proxy cred: CAS Server What rights does the community grant to this user? User 1.CAS request, authenticated with Resource Server Do the proxy restrictions authorize this request? 3. Resource request, authenticated with CAS proxy 4. Resource reply CAS-maintained community policy database User credential Community subject name Is this request authorized for the community? Local policy information Policy restrictions

8. DGC Paris 4.03.02 8 CAS Policy Management: the Resource Provider’s View The resource provider grants access to a block of resources to the community, using their existing access-control mechanism for that resource(e.g., grid- mapfile entries, file permissions, Akenti, etc.). The resource provider uses normal local mechanisms (e.g. quotas) to set policy for the community as a whole. The resource provider can grant access to different resources to CAS servers representing different communities. The resource provider then installs servers modified to enforce the policy in the CAS restricted proxies.

9. DGC Paris 4.03.02 9 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

10. DGC Paris 4.03.02 10 Policy Language Restricted proxies can use any policy language (the format consists of an identifying OID and an opaque policy field). We currently use a very simple policy language –Resource (e.g. host and filename) –Positive rights (e.g. read, write, create) –Can specify subtrees (/home/user/*) Policy language need only be understood by CAS and end resources –Opaque to users and protocol –Allows for more advanced languages Need deployment and feedback to understand what is needed in more advanced language.

11. DGC Paris 4.03.02 11 Spitfire Security Mechanism Servlet Container SSLServletSocketFactory TrustManager Security Servlet Does user specify role? Map role to connection id Authorization Module HTTP + SSL Request + client certificate Yes Role Trusted CAs Is certificate signed by a trusted CA? No Has certificate been revoked? Revoked Certs repository Find default No Role repository Role ok? Connection mappings Translator Servlet RDBMS Request and connection ID Connection Pool

12. DGC Paris 4.03.02 12 Service CAS Request 3.CAS reply, including restricted proxy cred: CAS Server What rights does the community grant to this user? User 1.CAS request, authenticated with 2. Resource request, authenticated with User credentials 4. Resource reply CAS-maintained community policy database User credential Community subject name Resource Server Do the proxy restrictions authorize this request? Is this request authorized for the community? Local policy information Policy restrictions User credential