Model for handling of Identity, Authentication and Authorization: version 3

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 models ModelNotesIAA and ModelNotesIAA2 (it is easier to start afresh than to hack on the old pages!)

The first section, on identity, explores what needs to be controlled, and by whom, without examining "how" very much. The subsequent sections deal more with how the system should be implemented.

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.

Parties and Roles

• Parties, Roles and Authorities: class diagram:
  

Parties are individual humans, individual automata (i.e. software agents) or organizations. 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. Parties can assign or be assigned Roles, and a Party that assigns a Role to another can also revoke that Role.

Authorities are sets of permissions to use various resources, and they accrue only to Roles. Identity as a Party gets you nothing unless you also have a Role. "Owner" is an obvious type of Role.

Basic types of Roles

• Types of Role: class diagram:
  

LocalRoles are meaningful only inside a particular service. They are assigned by some party operating that service to a user of the service. LocalRoles typically apply to DataSets held by a service, because both are arranged and managed by the service provider. LocalRoles might also apply to subsidiary services accessed only through the service where the Role applies. A common kind of LocalRole could be the PI of an observation-set stored in an archive: the PI is allowed access during the proprietary period. How any given service implements access based on LocalRoles is a choice for that service, although AstroGrid may be able to offer some standard solutions. Since the IAA needs of services vary, the implementation of LocalRoles can be tuned to individual needs.

GridRoles are recognized across the Grid and apply equally to all services; however, the authorities that a given GridRole can use vary from service to service. That means that service providers who use GridRoles rely on outside organizations to establish and assign those Roles, but reserve to their own control the granting of Authorities to the Roles. Each GridRole has some IdCertificate by which the right of a Party to use the Role can be tested. The IdCertificate needs to have a common implementation across the virual organization. In a system based on Globus and OGSA standards, the IdCertificates are X.509 certificates.

GridMembership Role

An important special case of GridRole is GridMembership for a party. This is the basic way that a party gets Authority to use a service which applies IAA. Prior art shows us how GridMemberships are established.

• Registration of individual: class diagram:
  

The party - a human individual in this case - applies to a RegistrationAuthority^? which checks the party's identity and background. If the party is found to be suitable for membership of the grid, and hence of the virtual organization, the RegistrationAuthority^? makes a recommendation to the CertificateAuthority. The latter grants a GridMembership to the user and issues an IdCertificate to represent this. At some later time, the CertificateAuthority may revoke the GridMembership.

GridGroup Role

Another special case is the formation, by individual end-users of a collaboration that wants to share access rights to resources spread across the grid. They represent this sharing by the use of a common IdCertificate for their GridGroup.

• Creation of GridGroup: class diagram:
  

There are actually both local and grid roles involved. The local roles are inside the bit of software that makes the GridGroup role usable and gthey are there for the administration of the group.

One Party assumes the role of GroupInitiator to set the process off. This party arms some software that administers the accessibility of the GridGroup role and its IdCertficate^? to other parties of the group. The GroupInitiator also has to create, or have created by some other party, the IdCertificate for the group. Finally, the initiator is responsible for removing the use of the GridGroup Role as Parties leave the group. This last task is the reason for the local roles: the GroupInitiator can't cancel the GridRole itself without dissolving the group, but can revoke the (local) GroupMembership role.

The basic idea of this group is that members arrange to use the GridGroup role, with its certificate, instead of their individual GridMembership roles and certificates when they access property shared by the group.

There are two cases where this pattern can be used and they have very different scopes.

Firstly, if the GroupInitiator is an ordinary member of the grid, then the group's GridRole will typically only have authority on resources created under that role. The obvious case is when a group member copies DataSets into MySpace using the group role: the group owns those copies of the data jointly. The group won't have any a priori authority over data-sets or services created outside the group because the providers of those data and services have no special reason to trust the group, nor do they trust the GroupInitiator to control membership to their satisfaction.

Secondly, if the GroupInitiator is the CertificateAuthority for the grid -- i.e. the group is an official part of the grid -- then there may be cause for service providers to grant special authority to the group. The providers would do this because they trust the CertificateAuthority to run the group appropriately. The obvious example of this mode is a cartel of service providers -- owners of large compute engines perhaps -- undertakes a service agreement with a funding body. The funding body defines the group to be individuals it wants to support and delegates the actual running of the group to the certficate authority. The providers give the group authority because they are being paid to.

Classes of service in the grid

* Hierarchy of services:

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 the GridRoles used in the virtual observatory. As discussed above, the GridRoles are expected to be implemented as X.509 certificates, so "understanding" a VObs GridRole basically means trusting the CertificateAuthority for the VObs and knowing how to use that CA's mechanism for revoking certificates. These matter will be discussed further in the section on authentication.

The sub-classes of VoService do specific tasks in VObs:

• VoDataService provides data extracts in response to queries.
• VoApplicationService runs locally-installed applications on supplied data, using local computing power.
• VoComputeService runs user-supplied applications on supplied data using local computing power.
• VoStorageService stores dta on behalf of a VObs user.
• VoRoleService administers GridRoles.

The VoGridRoleService sub-class administers GridMembership roles and the VoGroupRoleService class does the GridGroup roles.

The VoRoleService has four main operations:

1. A party may use local authentication - password based - to access a LocalRole in the VoGridRoleService and thus to extract the GridMembership certificate that lets the Party use the GridRole of the service. This is "logging on to the grid" and it can be done either locally, at the user's client computer or remotely, via a web browser.
2. A Party holding an IdCertificate for a GridMembership may use the VoGroupRoleService to recover the IdCertificate for a GridGroup of which they are a member. The Party can then use the group certificate to talk to other services.
3. The VoGroupRoleService is the software that a GroupInitiator uses to manage membership of a GridGroup. GroupInitiator and GroupMembership are LocalRoles stored in an instance of VoRoleService.
4. The service allows some other party on the grid to query the validity of a Role; this is especially relevant to Automata. The CertificateAuthority could use a VoRoleService to make public the "revocation list" of IdCertificate that other services should no longer accept.

Operation 1 is what the existing grid-programmes MyProxy and grid-proxy-init aleady do; operations 2 and 3 are roughly what the Community Authorization Server already does. In each case, we may choose to change the details of the operation from the existing methods. As far as I know, operation 4 is not a feature in any Grid products to date.

From here on dowm, this document is a work in progress. It should be complete by the end of Tuesday 23 Apr 2002.

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.)

To access a GridService, a Party must use a GridRole (usually that Party's GridMembership, but sometimes a GridGroup). On the grid, authentication means verifying that the party using the GridRole has the right to do so. This in turn means checking that the Party presents the proper IdCertificate for the Role and then establishing that the certificate is not stolen, is not forged and has not been revoked.

Inside a service, a Party may need to use LocalRoles to get access to parts of the service. The act of authenticating a GridRole for access to the service should also authenticate zero or more LocalRoles associated with the GridRole. That is, having decided to trust the GridRole of a Party, a service should not ask for secondary authentication; there should be no prompts for passwords, for example. This is necessary for the case when the party using the GridRole is an Automaton and has no way of responding to the secondary challenge.

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 and is presumably non-negotiatible for a system following OGSA rules

• Authentication ladder:
  

In any end-user's session on the grid, there is a ladder of authentication.

1. The user starts the chain off by using traditional, password-based authentication to get into a VoGridRoleService.
2. The VoGridRoleService generates a proxy IdCertificate: a short-lifetime version of the permanent IdCertificate from the user's GridMembership role. The proxy is cached for later retrieval, either on the user's home machine (when the user starts with a GridUI^? programme on that machine that talks to a local VoGridRoleService) or in a GridPortal (when the user starts with a WebBrowser^? that talks to a remote VoGridRoleService).
3. The proxy certificate is picked up by a VoClient programme that the user runs (either on his/her home machine or at the GridPortal;

1. Optionally, the VoClient contacts a VoGroupRoleService and exchanges the GridMembership certificate for one corresponding to a GridGroup.
2. The VoClient uses the certificate to authenticate to a VoService.
3. Optionally, the first VoService sub-contracts to other GridServices. In this case, the first VoService uses the user's GridRole and IdCertificate to authenticate on the user's behalf to its subcontractors.

Note that each PKI authentication uses exact one IdCertificate representing exactly one GridRole. If a user needs to access a service with two GridRoles (e.g. personal and group), then this needs to be done as two separate calls to that service. This limitation of the authentication is forced on us by the conventions of GSI. In order to use the standard GridServices that may appear over the next few years (and particularly the standard services to do with databases) AstroGrid needs to remain compatible with GSI and to use the minimal number of extensions.

On occasion, it may be necessary to revoke an IdCertificate. This is most likely to be the case if the cryptographic keys for the certificate have been compromised. All CertificateAuthorities are required to publish lists of revoked certificates but there seems to be no standard for who those lists might be read by a programme.

The revocation list might be published as a WebService. The VoRoleService for the relevant roles could be set up to answer enquiries as to whether a given Role is still in play. The enquiry would have to be made by the VoService doing authentication, since there is no way for a client to assert securely that its certificate is still correct. The VoService could either ask in the authentication process for each transaction, or it could ask at intervals, perhaps daily; the choice would depend on the sensitivity of the access requested under the certificate.

The ability to check automatically for revocation should be made a standard part of a VoService; it is an extra feature that distinguishes a VoService from an ordinary GridService.

Authorization

Authorization means establishing the right of an authenticated Party (i.e. a Party presenting an authenticated Role; see above) to use resources. The objects of desire for Parties with Authorities are Services and DataSets.

• Authority and Resource: class diagram:
  

Services, in the bright new OGSA world, 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 its parent Service.

Using established authorities

When a Party tries to use a service, his/her authority to do so must be tested by retrieving the Authority object associated with the Party's GridRole. The ServicePermissions in the Authority determine whether the Party can use the service and, if so, how much of the resource they may use. If no Authority is available for that GridRole, then access is denied.

When the Party has been given access to the service, the service may select or create data-sets that the Party wants access to. For each DataSet^?, a check must be made that the Party has an authority with the appropriate DataSetPermissions.

Consider a data-service that contains restricted data:

• Illustrating authorization with a VoDataService:
  

The VoGatekeeper performs the authentication and so establishes the roles of the Party requesting data. The gatekeeper must look up the single GridRole that the Party is using in the AuthorityDB, getting back the Authority for that Role. The gatekeeper then checks that the ServicePermissions in the Authority t see if they cover the intended usage of the service.

If the service usage is authorized, the VoGatekeeper passes the request to the SearchEngine^? which selects data to export.

When the query has been executed, and data have been selected, the service as a whole must decide which DataSets to allow the user to collect, based on the union of the DataSetPermissions in the Authorities of all the Roles that are recognized for this user. This can happen in two ways:

• the search engine checks the LocalRoles and DataSetPermissions while doing the search;
• the VoGatekeeper checks the Roles and DataSetPermissions when exporting the DataSets.

If the SearchEngine^? is a DBMS, it may be more efficient to let it do the authorization of DataSets for export; commercial DBMS are usually good at handling roles and permissions. If the SearchEngine^? is a simpler machine, or if the access restrictions are simple, then it may be easier to have the VoGatekeeper do it. In either case, a "successful" query may give the user all the selected data, none of the data, or only some of the data. In the latter case, it is important that the report to the user indicates that the result is incomplete.

Setting authorities; delegation

In the model so far, all the Authorities have been kept with the service they apply to. This should be made universally true for the following reasons:

• An Authority may contain DataSetPermissions which are meaningless outside its parent service.
• The implementation of the AuthorityDB may well need to be different for each service, for performance.
• The service providers have to retain control of the AuthorityDB.

By extension, the interface for maintaining the AuthorityDB should be a local interface, not a GridService, and its form will differ from service to service. We can assume that the interface allows the service provider to

• add an Authority for a new GridRole;
• revoke an Authority for a known GridRole;
• change the permissions in an Authority;
• add or remove LocalRoles associated with a GridRole.

Beyond that, it isn't useful to specify the interface here.

However, one operation on the AuthorityDB should always be made available to the Grid through the parent GridService: delegation of Authority. If a Party has a Role that grants authority in a service, then that party should be able to delegate a part of the authority to another party.

The common example is the PI of a set of observations delegating read-access to his/her research student during the period before the archived observations become public. Another example concerns a reseracher loading some private data into a VoStorageService, and hence having read, update and delete access; the researcher wants to delegate read access only to some colleagues, and read/update access (but not delete access) to others. A final example is a user with some quota of time on a compute farm allocating part of the time to various students. In the latter two cases, we see that only part of the authority is delegated, and that part may be different for different delegates. It follows that the effect of delegation can't always be acheived by forming a GridGroup, nor can it be done safely by letting the delegates "borrow" the delegator's credentials.

To make the delegation work, the VoService must expose an operation that takes a GridRole and an Authority, prepared by the delegator, and associates the Authority with the role in the AuthorityDB. Services that doesn't provide this kind of access to their AuthorityDBs won't be able to do delegation; it's a choice for the service provider. The delegation interface is the major feature that distinguishes a VoService from a GridService: it is a new feature that will be special to the VObs, at least initially.

Publishing authorities

All VoServices are assumed to be listed in some resource catalogue which VoClients can search. This catalogue should state the GridRoles needed to access each service. However, it is probably neither useful nor feasible to list all the LocalRoles involved.

Deployment

The main objects in the system can be divided into three groups:

• those that need to be on the user's home computer;
• those that need to be at a particular data-centre;
• those that can be put anywhere on the grid.

The free-floating components are likely to be placed at an existing data-centre but they remain independant of that data-centre's core operations.

• Deployment of objects:
  

Check-list of desirable features in IAA

Do we have a single-sign-on system? Yes, if the services play nicely and don't require secondary authentication. One password-authentication to a VoRoleService supplies a proxy IdCertificate that works all over the VObs.

Do we have unique identities for parties across the VObs? Yes: each IdCertificate is unique within its own virtual organization, and the name of the VOrg is a part of the IdCertificate; hence, the certificates are globally unique.

_If some part of the security system is compromised, can we control the damage?_ Yes, although the reaction time may not be very good. We have, as a normal part of GSI, time-limited proxy IdCertificates. If one of these is compromised, then it becomes useless after (typically) 24 hours. We also have plans for handling revocation of users' permanent certificates.

Can we deal with access to restricted data? Yes: we recognise DataSetPermissions explictly.

Can we deal efficiently with access to unrestricted data? Yes: no data-service is required to control read-access to its data. A service may be a pure web-service with no IAA at all and anonymous read-only access to all its data. Alternatively, a service may have restricted access (to manage the load on the server), but the data need not then be subject to any access control.

Can we deal with quota-limited access to compute and storage services? Yes, although the details are not included in this model yet. The ServicePermission^? class is specifically intended to deal with this.

Do the service providers retain control of their facilities? Yes: the Authorities ultimately control access and Authorities are always set by service providers, not by the administration of the grid. The only trust that service providers have to place in outside agencies is that the CertificateAuthority will not issue IdCertificates to unsuitable people, and that compromised certificates will be revoked without delay.

Can a party with limited rights to use restricted data in an archive delegate those rights? Yes. If the service provider allows delegation (some might not), then the VoService model provides an interface for invoking it. Details of the process need to be worked out.

Can a party delegate different rights on the same resource to different collaborators? Yes, the model allows this.

_Can an observatory archive manage collaborative access to its resticted (proprietary-period) data when new data are continually arriving? Yes. The archive should create a local role of PI for the DataSets obtained under each observing proposal, and should link this LocalRole to the GridRole of the PI. The PI can then use normal collaboration arrangements to share the data; no human contact with the service provider is needed to set this up. Naturally, the service won't allow the PI to delegate any more than read access since s/he only has read access in the first place.

Can a group share data equally in MySpace? Yes. The GridGroup mechanism works in MySpace.

Can a group share data unequally in MySpace? Yes: the core GridGroup has equal access but any group member may delegate some of that access to non-members. The delegation feature will definitely be enabled for MySpace.

Do the IAA arrangements work with industry-standard toolkits? No. Using GSI for authentication means that we have to use specially-adapted hosting environments for our services.

Do all the IAA arrangements work with any OGSA-compliant software? Almost. From a client's point of view, everything works, except that non-VObs-specific software won't understand the protocols for delegation or for looking up revoked certificates. From a service's point of view, everything works since our environment is a super-set of what OGSA requires.

-- GuyRixon - 22 Apr 2002