EGEE-III INFSO-RI Enabling Grids for E-sciencE EGEE and gLite are registered trademarks gLite Authorization Service: Technical Overview Chad La Joie, SWITCH EGEE '08, Istanbul, Turkey

Enabling Grids for E-sciencE EGEE-III INFSO-RI Agenda Service Components Component Interactions

Enabling Grids for E-sciencE EGEE-III INFSO-RI 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

Enabling Grids for E-sciencE EGEE-III INFSO-RI Service Components

Enabling Grids for E-sciencE EGEE-III INFSO-RI 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. PAPs do not attempt to filter the effective policy set based on information within an authorization request –It is possible that this may lead to performance issues. The spec details how to do filtering but it is complex and will not be implemented until a need is determined. 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

Enabling Grids for E-sciencE EGEE-III INFSO-RI 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

Enabling Grids for E-sciencE EGEE-III INFSO-RI 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

Enabling Grids for E-sciencE EGEE-III INFSO-RI 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.

Enabling Grids for E-sciencE EGEE-III INFSO-RI 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