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!)
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
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
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
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.
are sub-classed into the following:
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.
Authorizing a use of a service is a four-step process.
- Authenticate the requesting Party's identity (i.e. check his IdCertificate).
- Check permission to use the service as a whole, using ServicePermissions.
- Determine which controlled DataSets are involved.
- 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.
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.
- Where the pieces live:
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
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
- 15 Mar 2002