gLite Authorization Service: Introduction

1. C.Witzig, SWITCH gLite Authorization Service:Introduction

2. Outline Non-technical section Technical section Plans within EGEE-III

3. What's a Policy Simple policies Allow ATLAS jobs to run here. Do not allow CMS to submit job to this WMS. Do not allow Christoph to submit jobs as member of Higgs analysis group. More complex policy Do not accept jobs into the CERN site CEs between 8am and 5pm unless the user is from ATLAS, the job is a SAM job, or the submitting user employed a credential issued by CERN. Only allow jobs from people on this sites white list or where the user is from the Bio grid VO, created their initial proxy certificate less than 8 hours ago, and is not banned by OCST. All jobs started by a pilot job must use a credential associated with the same VO that issued the pilot job.

4. Goals of the Service Accurate, consistent authorization grid policies Individuals responsible for a policy create and maintain those policies VO admins write policies dealing with VO matters, site admins write policies dealing with site matters Policies are in effect across the grid in a timely manner Measured in hours, not months Policies are evaluated exactly the same by every service at any point in time The same policy used when running a job is used when matching a job to a resource Provide detailed audit logs What were the exact conditions that resulted in a decision

5. Goals for the Service Provide good tools to admins Output should be meaningful, precise, and intelligible Usage of tool should be simple and straight forward Resistance to failure and simple means for scaling Make the client component very lightweight small amount of code few dependencies – no conflicts with jobs or other components portability – very low barrier to use on other OSes, in other software, and other languages Flexible deployment model Allow deployers to balance latency, complexity, resource costs, privacy requirements, etc. Minimize configuration synchronization

6. Benefits of the Service All the benefits derived from meeting the goals of the service Appropriate locus of control for policies Enables/eases various authorization tasks: Banning of users (VO, WMS, site, or grid wide) Composition of policies – CERN policy + experiment policy + CE policy + OCST policy + NGI policy=> Effective policy Support for authorization based on more detailed information about the job, action, and execution environment Support for authorization based on attributes other than FQAN Support for multiple credential formats (not just X.509) Support for multiple types of execution environments static POSIX accounts, pool accounts, virtual machines, workspaces, ...

7. Technical Section

8. Service Components • Policy Administration Point (PAP) • The repository for store, curating, and composing policies • Policy Decision Point (PDP) • Given a request, evaluate the appropriate policy, retrieve execution environment, and return result • Policy Enforcement Point (PEP) • Makes request to PDP, may operate on execution environment data • Execution Environment Service (EES) • Given a request, an effective policy, and a decision it determines the appropriate execution environment

9. Service Components

10. Component Interactions: PAP/PAP • A PAP may mark policies as private or public • In order to compose policies a PAP may pull in public policies from other PAPs • Uses the SAML 2 profile for XACML 2 to make the request • Policies may be combined in multiple ways • local policy overrides, deny overrides, permit overrides, etc. • XACML is a complex language and difficult to author • A simplified policy language will be available for use with the PAP CLI and then compiled down in to XACML

11. Component Interaction: PDP/PAP • PDP uses the same protocol for policy queries as in the PAP/PAP interaction • The PAP serves a “close” cache for the effective policy • It is expected that a PDP will be deployed with a PAP • Doing otherwise introduces latency • Especially complex policies may result in long response times • For the policies currently under discussion this is not an issue

12. Component Interaction: PDP/PEP • PEP uses same XACML/SAML protocol to make authorization decision requests • PDPs are stateless and so any number may be deployed to ensure scalability and failure resistance • PEPs can be configured with any of PDPs and will try each in turn if one does not respond • It is expected that a PDP will be deployed within the same site as PEP-enabled software • Doing otherwise will increase latency • Some situations could result in a significant number of identical authorization requests being made • PEP could batch the requests if it was aware of this - this moves the burden to the PDP • PEP could cache the result of requests – difficult to implement

13. Component Interaction: PDP/EES • PDP uses the same XACML/SAML protocol to contact the EES. • EES has access to all original request, policy, and decision information.

14. Component Interaction: PEP • PEP contains two types of plugins • Information points – gather information about the resource, environment, user, and action • Obligation handler – deals with obligations sent back by the EES • PEP will actually be made up of two components: • A daemon that does all the communication with the PDP • A thin client with no required dependencies that talks to the daemon using a binary protocol (Hessian) over HTTP • This model has the following benefits • No chance that the PEP conflicts with worker-node/job software • PEP daemon can keep persistent SSL connections to the PDP thus minimized latency caused by connection startup/shutdown • PEP does not need to be re-initialized for every request made • Makes writing a PEP in other languages trivial

15. Plans Within EGEE-III

16. Main Ideas • Keep it simple • Gradually bring in more components • Identified 6 phases