Although authorization is not one of the 'fundamental pillars' of a secure conversation, it is nonetheless an important part of GSI. Authorization refers to who is authorized to perform a certain task. In a Web services context, we will generally need to know who is authorized to use a certain web service.
GSI supports authorization in both the server-side and the client-side. Several authorization mechanisms are already included with the toolkit, but we will also be able to implement our own authorization mechanisms.
The server has six possible authorization modes. Depending on the authorization mode we choose, the server will decide if it accepts or declines an incoming request.
None: This is the simplest type of authorization. No authorization will be performed.
Self: A client will be allowed to use a service if the client's identity is the same as the service's identity.
Gridmap: A gridmap is a list of 'authorized users' akin to an ACL (Access Control List). . When this type of authorization is used, only the users that are listed in the service's gridmap may invoke it.
Identity authorization: A client will be allowed to access a service if the client's identity matches a specified identity. In a sense, this is like having a one-user gridmap (except that identity authorization is configured programmatically, whereas the gridmap is represented as a file in our system).
Host authorization: A client will be allowed to access a service if it presents a host credential that matches a specified hostname. In other words, we will only allow requests coming from one particular host.
SAML Callout authorization: We can delegate the authorization decision to an OGSA Authorization-compliant authorization service. OGSA-Authz (http://forge.gridforum.org/projects/ogsa-authz) is a GGF working group whose goal is to specify standard authorization components. One of the main technologies used in these components is SAML (Security Assertion Markup Language).
This allows the client to figure out when it will allow a service to be invoked. This might seem like an odd type of authorization, since authorization is generally seen from the server's perspective ("Do I allow client FOO to connect to grid service BAR?"). However, in GSI, clients have every right to be picky about the services they can access.
None: No authorization will be performed.
Self: The client will authorize an invocation if the service's identity is the same as the client.
Identity authorization: As described above, the client will only allow requests to be sent to services with a specified identity.
Host: The client will authorize an invocation if the service has a host credential. Furthermore, the client must be able to resolve the address of the host to the hostname specified in the host credential. Note that this is different from server-side host authorization, where we check if the hostname in the credential is equal to a host specified by us.
GSI provides an infrastructure to easily plug in our own authorization mechanisms. For example, our organization might be using a legacy authorization service that can't work out-of-the-box with the authorization methods provided by the toolkit. In this case, we can create a new authorization method that will allow GSI to make authorization decisions based on our organization's legacy service.