Model for handling of Identity, Authentication and Authorization

This document introduces and annotes a UML model of Identity, Authentication and Authorization (IAA) for the VO, and hence for AstroGrid. It supersedes the earlier model ModelNotesIAA (it is easier to start afresh than to hack on the old page!)

Identity

We need to express the right of Parties to use Resources in a way that can be controlled using GSI and which allows reasonably-efficient use of the system.

• Class diagram relating to concepts of identity:
  

Parties are organizations or individuals, and individuals can be either human or automatic (i.e. software agents). The Party pattern comes from Martin Fowler's discussion of accountablity in his book Analysis Patterns and was introduced to AstroGrid's research by Tony Linde. In the context of grid security, we can say that a Party is an enitity that has been issued with an X.509 certificate, modelled as IdCertificate and the Party's identity is the DistinguishedName in the certificate. In base reality, there are parties without certificates, but our system can't deal with them, so we make the rule that a Party has exactly one certificate.

Guy Rixon is a party because a certificate of identity has been issued in that name. "The Globus gatekeeper daemon at the computer apm2.ast.cam.ac.uk" is also a party, and has a certificate. "Anonymous" is a default Party, and it would be possible to issue a real certificate for this dummy individual if it helped the system. Where an organization has a shared account at one site, that account can be a party and have a certificate: "the archive at CASU" is a possible example.

As discussed elsewhere, most access rights accrue to individuals by their membership of groups or affiliations to institutions and funding agencies.

For example, Guy Rixon has no inherent right as an individual to use INT WFS data, but Guy Rixon works for an astronomy department at a British university and receives access rights to WFS on that account. At a finer-grained level, write access to data published in "MySpace" belong to the Party who originally published the data, but that Party's collaborators may be granted similar access for the duration of the collaboration.

Both the cases above represent access rights resulting from the roles that a Party plays. In the former case, the role could be modelled as an organizational Party "IoACambridge" and given a certificate and a shared account. Whether this approach is either desirable or feasible is unclear; sharing certificates between individuals may be unwise, and forcing users to use different, shared accounts to get their access rights is clunky. In the latter it's clearly inconvenient to represent a short-term collaboration as a full-scale organization. Getting certificates for collaborations takes time and effort (for references, signatures, checks, balances) and certfifying bodies may be unwilling to issue these certficates since there are so many possible collaborations.

To resolve this problem, we can largely abandon the idea of parties who are organizations and formally model the roles. A Role is effectively a party with no certificate and we give a Role meaning and power within the VO by providing one or more formal registries of roles that are independent of the registries for certificates.

Having (and being known to have) a Role grants a Party zero or more Authorities, where an Authority is just a convenient way of modelling a set of access permissions on various resources.

The objects of desire for Parties with Authorities are Services and DataSets. Services, in the bright new OGSA worls, are all assumed to be web services. DataSets are any collections of data that are meaningful to some service for access-control purposes. DataSets can be large (e.g. "the INT WFS; all of it") or they can be small (e.g. a single observation in the ESO archive).

Both Services and DataSets have similar attributes and are special cases of Resources. However, the distinction is important on two counts. Firstly, the permissions are different: ServicePermissions say how a Party can use a resource (e.g. use allowed or no use; how much CPU time; how much storage etc.); DataSetPermissions are more like Unix file permissions. Secondly, Services are visible acrosss the VO; they are what the VO is made up of and they are all written down in the VO's ResourceCatalogue. DataSets are typically invisible until discovered in a query to a particular data-service. That is, the identity of a DataSet , and therefore the permissions attached to it, is usually only meaningful to it's parent Service.

Classes of service

• Inheritence tree of Service classes:
  

Each service in the VO is a WebService. For our purposes, a WebService becomes a GridService when it understands griddish authentication with GSI. This may mean that every GridService conforms to OGSA, or it may be that OGSA-compliant services are a sub-class of GridServices. For now, let us assume that all GridServices comply with OGSA. Essentially every service in the VO needs to understand authentication (we need at least to be able to turn away anonymous users sometimes for flood control), so will be a GridService.

A VoService is a GridService that understands about a Party's Role, as defined above. Initially at least, generic GridServices won't follow this convention, so Role-dependent work will be restricted to the VoService sub-class.

It may seem that using an IAA policy different to all other virtual organizations iis a problem. What do we do if we want to share services with GridPP, for example? In fact, however we handle roles specific to astronomy, there are two roles for each Party that all grids will understand: the Party's DistinguishedName and the Party's CertificationAuthority . Both these are written into the IdCertificate and are obvious in any griddish transaction.

* CertifcateRelationships .gif:

VoServices are sub-classed into the following:

• VoDataService: an archive that accepts queries and returns data extracts.
• VoProcessingService : executes well-defined data-transforms on supplied data.
• VoComputeService: executes user-supplied code on user-supplied data.
• VoStorageService: stores user-defined data.
• VoRoleService: given an IdCertificate, returns Roles performed by that Party.

Authentication

Since we operate over the public Internet, all identities of Parties need to be authenticated before we can trust them. (If we operated on a VPN, this might not be necessary.)

Grid operations imply the use of the Grid Security API (GSI), which defines a framework for using PKI authentication with X.509 certificates. This seems to be the most-standard part of Globus is presumably absolutely non-negotiatble for a system following OGSA rules.

• Shows authentication interactions:
  

Finding which Roles a Party plays is logically part of authentication, since it slightly modifies the authenticated identity. This is show in the diagram above. I have shown each VoService calling out to exactly one VoRoleService when it needs to discover roles that are not implicit in a Party's IdCertificate. This implies either that there is a central registry of Roles, or that each VoService keeps its own registry and the contents are replicated around the VO. Since any central registry needs to be replicated anyway (for reliability) and since all VO services are likely to run at established data-centres, these two options are almost identical.

Note that the onus is on the VoService to find the Roles, not on the VoClient. This complicates the VoService slightly, but it seems simpler overall than requiring the VoClient to look up the VoServices access policies in detail and select the right roles before submitting a job. Reducing the responsibilities of the client is a GoodThing if we want user-programmers to make their own clients for our system.

Since a VoRoleService is a VoService is a GridService, all transactions with a VoRoleService involve mutual authentication ia GSI. That is, a VoService can trust the results from a VoRoleService implicitly. It is less clear that a VoService could trust results forwarded from a VoRolesService by a VoClient, and this is another reason to have the VoServices doing the looking up.

Creating a collaboration involves invoking an update operation on a VoRoleService that establishes a new Role. How the new Roles propagates round the various VoRolesServices nees to be worked out in detail. Roles representing collaborations should be subject to time limits and should lose validity after the time limit.

Authorization

Authorizing a use of a service is a four-step process.

1. Authenticate the requesting Party's identity (i.e. check his IdCertificate).
2. Check permission to use the service as a whole, using ServicePermissions.
3. Determine which controlled DataSets are involved.
4. Check permission to use the DataSets using DataSetPermissions.

If the proposed usage doesn't involve any controlled data-sets, then the third step can be skipped.

For queries to a VoDataService, this order basically says "see if he's worth spedning time on, then do the query, then see if he's allowed to see the results". This before-and-after permission checking reflect the fact that the list of data-sets to check doesn't exist until at least part of the query is run. Furthermore, the checking process, which may involve re-authentication of the requesting party via the VoRoleServer needs to be separated from the real business of running the query. The next diagram illustrates this.

• Arrangements inside a VoDataService:
  

Note how the authentication and authroization are handled by the VoGateKeeper , which is the Facade for the whole service (FacadePatternGoF ). The SearchEngine , which does the real work, is invoked by the VoGatekeeper and never touches the AuthorityDB. Note also how the AuthorityDB is matched one-to-one with the service. This reflects the fact that different services have wildly different needs for storing permissions. If the AuthorityDB is delegated to each VoService, it can be tailored to that service, allowing significant optimization. In fact, since many services have few or no restricted data, many implementations of the AuthorityDB will be trivial, and these cases should not be encumbered with the software needed for the difficult cases.

The two permissions checks themselves involves several steps which are best show in an activity diagram.

* How authorization is done:

Note how the system avoids going out to the VoRoleService if it can resolve the authorization from the Party's certficate.

Note also how the matching of roles is done eventually inside the VoRoleService. This is an attempt to minimize the amount of data that has to be exchanged between the VoGatekeeper and the VoRoleService. It assumes that the set of Roles attached to a typical Resource will be smaller than the number of roles performed by a typical Party.

Deployment

• Where the pieces live:
  

Each VoGatekeeper and its AuthorityDB form a package located at a particular VoService site, where the SearchEngine lives. That is, for the reasons of optimization discussed above, the AuthorityDB needs to be matched to a particular application. In principle, the package could be hosted elsewhere in the VO and could invoke the SearchEngine remotely, but this begs the question of how the SearchEngine knows to trust a remote gatekeeper. It's simpler to co-host the IAA package with the SearchEngine .

The VoRoleService can be anywhere in the VO as long as it responds quickly and reliably, and so long as the VoServices can find it easily. Reliability suggests that we have to replicate the VoRoleService as we do the ResourceCatalogue. We should find out if it is feasible to put a replica of the VoRoleService alongside each VoService.

-- GuyRixon - 15 Mar 2002