glite authorization service: introduction

EGEE-III INFSO-RI-222667

Enabling Grids for E-sciencE

www.eu-egee.org

EGEE and gLite are registered

trademarks

gLite Authorization Service:IntroductionC.Witzig, SWITCH

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



Main Ideas

• Keep it simple• Gradually bring in more components• Identified 6 phases

glite authorization service: introduction

Documents