The implementation and configuration of authorization within an OGSA-DAI installation varies from project to project and depends on the security model adopted by the project. Over time the OGSA-DAI team hope to expand the range of authorization components bundled with OGSA-DAI. Currently this range is fairly limited and it is likely that any project using OGSA-DAI will have to develop some of their own plug-in security components. The OGSA-DAI team are very happy to help advise you on how to develop these security components and may be able to contribute some effort if the components could have wider appeal.
Authorization in OGSA-DAI GT is based around the notion of policy information points (PIPs) and policy decision points (PDPs) as provided by the Globus Toolkit authorization framework. Please refer to the Globus Toolkit documentation for more details regarding using and developing PIPs and PDPs. The OGSA-DAI PIPs are documented in Chapter 35, Plug-in policy information points for OGSA-DAI GT and the PDPs are documented in Chapter 36, Plug-in policy decision points for OGSA-DAI GT
For full documentation on how to write a PIP or PDP refer to the Globus Toolkit documentation. This section covers issues unique to OGSA-DAI.
If your PDP or PIP utilises an object obtained from the OGSA-DAI
context you will not be able to obtain the object from within the
initialize method of your PIP
or PDP implementation. This is because the PIPs and PDPs are
initialised before the OGSA-DAI context is created. To work
around this issue you should obtain the object from the OGSA-DAI
context the first time the collectAttributes
or isPermitted method is called.
It is possible build a security context from with a authorization chain and pass it to OGSA-DAI so that it is used as the security context for the request instead of the default security context.
To do this all you need to do is add an object that implements
the uk.org.ogsadai.authorization.SecurityContext
interface to the Axis MessageContext object
as a property with key uk.org.ogsadai.security.context.
This security context object will be used when processing the request.
Many authorization solutions will require some action to be performed when a new resource is created or an existing resource is destroyed. For example a database that stores resource IDs and authorized users will need be updated when a new resource is created or when a resource is destroyed.
To obtain events when resources are created or destroyed a class
should implement the uk.org.ogsadai.resource.event.ResourceManagerEventListener interface. This interface contains a method
through which the resource manager and notify the class of changes
to the resource set. A class can easily register itself as a
listener with the resource manager using the following code:
ResourceManager rm = OGSADAIContext.getInstance().getResourceManager(); rm.addResourceManagerEventListener(this);
The following code shows an example implementation of the
resourceManagerUpdated method
that is the method called when resource events occur. This
implementation simply prints out the events, a proper implementation
would write the information to a database, inform an external
service or whatever is appropriate to the application's security
model.
public void resourceManagerUpdated(ResourceManagerEvent event)
{
if (event.getID() == ResourceManagerEvent.ADD)
{
SecurityContext sc = event.getSecurityContext();
ResourceID resourceID = event.getResource().getResourceID());
DistinguishedNameProvider dnp =
(DistinguishedNameProvider) event.getSecurityContext();
String dn = dnp.getDN();
System.out.println("User " + dn + " created resource " + resourceID);
}
else if (event.getID() == ResourceManagerEvent.DELETE)
{
System.out.println("Resource " + event.getResourceID + " destoyed");
}
}
Note the above example expects the security context object to implement
the DistinguishedNameProvider interface.
It should be noted that security context object does not have to implement
this interface. For more details on the security context see
Section 31.1, “Security contexts”.
Some OGSA-DAI activities generate their own workflows at runtime which are then executed from within the activity. Examples of such activities include SQLBag and SQLResilient. These activities may run SQLQuery activities on multiple resources as specified by a resource group. It is important to ensure that the caller is authorized to run the SQLQuery activity on each of the resources in the resource group. We therefore need a means of authorizing these runtime workflows.
OGSA-DAI supports a plug-in a runtime workflow authorizer class to
authorize these runtime workflows. This class must implement the
WorkflowAuthorizer interface (namespace
uk.org.ogsadai.authorization).To
plug in this class add it to the OGSA-DAI context as a miscellaneous
object with ID uk.org.ogsadai.resource.authorizer.
See Section 18.9.1, “Specifying miscellaneous objects” for details of how to add
miscellaneous objects to the OGSA-DAI context.
To give the reader an idea of the types of authorization approaches that could be used with OGSA-DAI this sections presents two example approaches.
In this example the caller's credentials are expected to include attributes that specify the caller's role and also the IDs of the OGSA-DAI resources the caller is allowed to access. Additionally the data resources exposed by OGSA-DAI will use the caller's role attribute to obtain the appropriate login to the underlying databases.
When authorizing requests to the data request execution service the authorization chain could use the existing Resource ID PIP and Workflow Resource IDs PIPs to obtain the ID of the resource the request is a targeted and also the IDs of the resources specified in the workflow. A new PDP could be developed to compare these IDs with the set of allowed resource IDs from the caller's attributes and hence make authorization decisions.
In order to use the caller's role to map to a login to the
underlying databases a new PIP would be written that created a
new security context and adds it
to the Axis MessageContext object
as described in Section 34.2.2, “Passing a security context to OGSA-DAI”.
This security context object could implement a new interface
called RoleProvider that contains
a method to access the caller's role. The data resources could be
configured with a new Login Provider that maps extracts the role from
the security context and maps this to a database login.
When authorizing requests to services other than the request execution service the authorization chain simply needs to consist of Resource ID PIP to extract the ID of the target resource and the new PDP that ensures this ID is one of these specified in the caller's attributes.
In this example we restrict access to dynamically created resources to the user that created them. The implementation consists of two PIPs, one PDP and a plug-in object that listens for resource creation events.
To make the actual authorization decisions we need to store the distinguished name (DN) of the user that created each resource. To do this we use an resource authorizer class that registers with the resource manager to receive events every time a new resource is created. Whenever a resource creation event is received the resource authorizer adds the resource ID and the users DN (extracted from the security context) to its internal data structure. This resource authorizer class also contains methods that can be used to check if a DN has permission to access a specific resource. This class is added to the OGSA-DAI context as a miscellaneous plug-in object.
To make authorization decisions we need PIPs to extract the caller's DN, the resource the request is targeted at and also any resources used in an OGSA-DAI workflow. These PIPs can then precede and PDP in the authorization chain. This PDP gets uses the caller's DN and the set of resource IDs being accessed and then used the resource authorizer class (obtained from the OGSA-DAI context) to see if the caller is authorized to access each resource in turn. If the caller is authorized to access each resource then the whole request is authorized, otherwise the request is rejected.
OGSA-DAI contains all the components required for this example. For details of how to configure the server for this example see Section 14.1.4, “Configuring authorization”.