The authorisation architecture follows the familiar PEP - PDP paradigm where in our case, a particular service is secured by a Policy Enforcement Point which itself refers authorisation decisions to a Policy Decision Point. The PDP runs as part of an independent authorisation service. This is shown below. A HTTP based client, in this case a NetCDF based OPeNDAP client makes a request to the PyDAP service. At the server, an authorisation filter (PEP) intercepts requests to the underlying PyDAP application. It makes authorisation decision queries over a SAML interface and enforces these allowing or preventing access to the requested URL. (Nb. authentication components are left out for simplicity. See this posting for details).
In the above, both PyDAP application and Authorisation service reside within the same organisation so where is the federated part of all this? Putting that aside for a moment, the standard SAML interface between authorisation filter and authorisation service mean I can interchange different applications and authorisation services and implementations. For example, on the left replace PyDAP with a THREDDS Data Server with ESG servlet authorisation filter, or keep the PyDAP service but secure it with the alternative Authorisation Service packaged with the Java ESG Gateway application.
Returning to the question of the federated aspect, this comes into play with PCMDI's Attribute Service. PCMDI have an overall responsibility across the federation for management and allocation of CMIP5 access roles (attributes) to registered users. Consider a request to the PyDAP service: the authorisation filter protecting PyDAP can push user attributes to the authorisation service but the authorisation service can also pull attributes from outside. If the policy determines that CMIP5 access is required, PCMDI's Attribute Service is queried to check that the user has the required CMIP5 attribute(s). These attributes are pulled into the request context for the PDP to process and make a decision. Following this architecture then has the consequence that PCMDI maintain control over the CMIP5 attribute. They can add or withdraw any users enrolement and this will immediately take affect across the federation.
At this point the contents of the Authorisation Service component above needs some further explanation. To be compliant with ESG, the component must have the outward facing interfaces shown for SAML authorisation decision and attribute query. Within this however, I've chosen to follow a XACML based solution. The Context Handler receives SAML based authorisation decision queries and translates them to XACML based requests and passes these to the PDP. The PDP takes XACML policy file at start up. The policy expresses the restrictions needed for the different datasets served from the PyDAP service. The Policy Information Point serves the PDP with additional user attributes when required by querying Attribute Service(s). In this case it's PCMDI's. The Authorisation Service is written as a Python WSGI application as part of NERC DataGrid Security. The XACML components use the Python XACML implementation ndg_xacml. I want to write more about this in a future post.
Taking a step back then and looking from a user perspective, I can go to the PCMDI Gateway, sign in with an OpenID from any of the trusted IdPs in the federation, register for the CMIP5 access attribute and then potentially go to any site in the federation where CMIP5 data is served and access it.
