GRID: Globus Toolkit 4.0 - Authorization Model
The feature list is
- Support for PDP Chaining
- Policy Combination algorithm Supported: DENY overrides ALLOW (permit overrides can be simulated by having a MasterPDP which will then controll the other PIP &PDP - Will need to specify sequence of the PDP & PIP Separately)
- Supports the concept of PIP which works as Interceptor (like PDP) but does not return decision. It instead returns data which can be used by PDP (More info needed on how)
- ID that will be authorized is extracted from the credential used by client to contact the service.
- A concept of Resource Owner is supported which can be extracted from "resource, service or container depending on availability in that order of precedence"
- Authorization Schemes supported
- self - Caller ID = Owner
- gridmap - Caller ID part of pre-defined list. This sheme also supports user ID mapping to local user id (how does that help or can be leveraged??)
- Identity - Caller ID = Specified ID
- Host - Called's Host ID = specified Host ID. Host ID being a special form of certificate with a common name (CN) corresponding to a name obtained from DNS or some configured service name. (How does this get mapped to caller, is the caller id = host id or is host id like a computer certificate in the Windows system??)
- SAML Call-out - PDP contacts a SAML Authz Service using request/response interface
- userName - Caller ID = JAAS authenticated User (who is authenticating and how is that being passed to PDP?)
- The development involves the following - Please note all the plugins have initialize and close function
- Implement the PDP interface - org.globus.wsrf.security.authorization.PDP :: boolean isPermitted(javax.security.auth.Subject,javax.xml.rpc.handler.MessageContext, javax.xml.namespace.QName operation). This interface also hase capability to get policynames and get/set policy (org.w3c.dom.Node)
- Reference the PDP from a security descriptor - Change $GLOBUS_LOCATION/etc/<service name>/security-config | <service name>-security-descriptor.xml add the <authz value="ascope:class name"/> where ascope is scope which is an authorization scheme "context" used to distinguish different authorization schemes with the same implementing class within the chain.
- Test the PDP - run client
- Implement the PIP interface - org.globus.wsrf.security.authorization.PIP :: collectAttributes(Subject subject,MessageContext ctx,QName operation)
- Reference the PIP from a security descriptor - <authz value="ascope:PIP_Class pdpscope:PDP_CLASS"/>
- Test the PIP - the order of execution of PIPs and PDPs depends on the order in which they were specified in the authorization chain configuration
- Communicate an attribute from PIP to PDP - e.g. - subject.getPublicCredentials().add(attribute); & subject.getPublicCredentials();
- Add a configuration to an interceptor - Use the service deployment descriptor to pass the data to PDPConfig used in initialize call. The D.D. is located in $GLOBUS_LOCATION/etc/<your_service> and <parameter name="ascope-attribute" value="notmanager"/> i.e. scope_name-attribute_name (Guess can not have hiphenated scope name??)
- Next Steps -
- Develop Attribute/Role-based Authorization - Proper representation of attributes need to be developed which can be transferred accross the PDPs
- support for fine grained expression of "delegation of rights" =
- pluggable authorization engines
- lazy collection of attributes
- caching of decision/attributes
- and metadata about attributes/interceptors
- Resources - GlobusTK 4.0 Release Manual, WS Authentication and Authorization documentation, GridShib (Globus Toolkit with Shibboleth), Community Authorization Service
Comments