Authentication and authorization procedures for Grid and Virtual Observatory. Definitions and Guideline

This is a live document!


We define and describe the authentication and authorization (A&A) concepts and implementation mechanisms. We present the state of the art for what regards digital certificates and authorities. We present the Grid point of view on the A&A. We show the key-points to provide an interoperable system. We propose a prototype of A&A architecture for Euro-VO DCA.


A&A mechanisms provides a way for a user to connect and use a resource. It is easy to confuse the mechanism of authentication with that of authorization. In many host-based systems and client/server systems, the two mechanisms are performed by the same physical hardware and, in some cases, the same software. However, they are two distinct mechanism and maybe performed by separate systems. Authentication focuses on establishing a person’s identity, based on the reliability of the credential he or she offers. Authentication systems depend on some unique bit of information known (or available) only to the individual being authenticated and the authentication system -- a shared secret. Such information may be a classical password, a digital certificate, or some biometric property. In order to verify the identity of a user, the authenticating system typically challenges the user to provide its unique information (his password, certificate, etc.) -- if the authenticating system can verify that the shared secret was presented correctly, the user is considered authenticated. Authorization focuses on what actions that identity, at that level of assurance, is permitted to do. For example, a UNIX system my be configured in order to allow some users to write and read only a particular disk area or execute only one application (ex. a bastion host may be configured so that users my only execute ssh).

Authorization systems accounts for the following problems:

  1. Is user A authorized to access resource X?
  2. Is user A authorized to perform operation Y?
  3. Is user A authorized to perform operation Y on resource X?
Authentication and authorization are somewhat tightly-coupled mechanisms. Decisions concerning authorization are and should re-main, the purview of the electronic service process owner.

Authentication mechanism

Authentication with passwords

Conceptually, the simplest way to achieve single sign on (SSO) is for all services in the VO to use the same password file. Each message for which authentication is needed then carries the user's password to the service. This scheme is attractive at first sight but has two major draw-backs.

  1. The administration of the shared password file is unwelcome when a few sites are connected and infeasible when 100 or more are involved.
  2. The compromise of one node exposes the credentials of the whole VO.
  3. Shared password are extremely hard to achieve and manage when different authentication mechanisms are involved.

Therefore, shared password systems are not really suitable for the VO.

Authentication with Digital Certificates

Digital certificates are digital files that certify the identity of an individual or institution seeking access to computer-based information. In enabling such access, they serve the same purpose as a driver's license or library card. The digital certificate links the identifier of an individual or institution to a digital public key.

The public key infrastructure

The combination of standards, protocols, and software that support digital certificates is called a public key infrastructure, or PKI. The software that supports this infrastructure generates sets of public-private key pairs. Public-private key pairs are codes that are related to one another through a complex mathematical algorithm. The algorithms are such that it is impossible to derive the private key from the public one. The key pairs can reside on one's computer or on hardware devices. Individuals or organizations must ensure the security of their private keys. However, the public keys that correspond to their private keys can be sent across the network or shared.

Message security

Message security is the protection of the integrity, and sometimes the privacy, of messages from clients to services, using only credentials carried in the messages themselves. It does not refer directly to the authentication of systems or between services (for example the Secure Sockets Layer - SSL). Digital signatures are an example of message security.

Message security protects the integrity of messages by signing them digitally, such that any change to a message by an attacker invalidates the signature. Message security can also protect the privacy of a message by encrypting it. Practical signature and encryption methods typically use PKI cryptography. To do digital signatures, a user's agent must have access to a public/private key pair. The agent signs with the private key and the receiving service checks the signature with the public key. The latter key can be included in the message; the service does not need to have the key beforehand in order to check a signature.

Certificate as users and services identity warrants

Users and services (host, applications etc.) identify themselveswith a service on the basis of the credential they offer. To "vouch for" a sender of a message, a party may construct and sign a warrant of identity that ties together the sender's identity and public key. If the receiver of the message trusts the third party and can verify the signature, any message bound to the warrant authenticates the identity stated in the warrant. In this case "bound to the warrant" means that the message is signed with the public key quoted in the warrant.

Two kinds of warrants of identity are commonly used:

  1. X.509 identity certificates;
  2. Security Assertion Markup Language (SAML) assertions.

Both kinds could reasonably be called "identity certificates", but that term is commonly used to mean specifically X.509 certificates.

X.509 and SAML are equivalent forms for the limited case of asserting a user's identity. Both forms allow more advanced uses but these are not relevant to the current case. X.509 is an older standard and is used more widely. For example, the Globus Toolkit requires X.509 certificates. The European production grid (EGEE-III) uses also X.509 certificates. SAML is a newer standard. For Example, the Shibboleth system for controlling access to web sites requires SAML.

In this document we focus on the use of X.509 certificates which is the standard for the Grid communities and in particular for the EGEE-III one.

Certificate Authority

Digital certificates are issued by certificate authorities just as state governments issue driver's licenses. There are several public companies in the business of issuing certifi-cates. Certificate authorities (CA) are responsible for managing the life cycle of certificates, including their revocation.

A CA must check a user's identity before issuing a certificate using some different authentication scheme to the one in which the warrant is used. That is, the user must pre-register with the CA before using the services to which the CAs warrants grant access. The CA issues a long term warrant to users and services typically they are valid for one year.

In Europe a set of national CAs for e-science (research and education) has been created, which are federated via the EUGridPMA (Policy Management Authority)[cita]. The EUGridPMA is the international organization to coordinate the trust fabric for e-Science grid authentication in Europe. It collaborates with the regional peers APGridPMA for the Asia-Pacific and the Americas Grid PMA in the International Grid Trust Federation.

Each institution/university negotiate with its national CA to create a Registration Authority (RA). The RA mediates between the CA and the user that asks for a certificate for him self or for a service he is going to manage. Typically, the person requesting the certificate is required to be physically present at the RA when a certificate is issued. The RA is in charge of verifying his identity.

Actually, the e-science communities (ex. EGEE-III) agree to trust all the CA that are trusted by the EUGridPMA . Not to trust a CA may prevent a user from accessing some resources/services or some service provider from joining a particular Grid ser-vice.

The warrants policies

The major difference in authentication schemes consists in how the warrants are passed out and communicated to the services that need them. Three schemes are relevant here.

Long-lived warrants held by users The CA issues long-lived warrants (valid for a year) after carefully authenticating the user with physical credentials such as a passport. Users are given their warrants to keep and use as they wish. The CA is not a part of the runtime SSO system. The CA holds and maintain a certificate revocation list.

Temporary warrants held by user agents The CA registers users as in the case of long-lived warrants and arranges a SSO password with each user. This password authenticates the user in access to on-line services representing the CA, but not to general services. No long-lived warrants are issued to the user, but instead the CA issues short-lived warrants (valid for perhaps a day) when the user invoked the CA service and authenticates with the SSO password. The CA is a part of the runtime system but is not involved in the authentication of each message; once the user's agent has the warrant for a session the CA need not be consulted again in that session either by the agent or the ser-vices that the agent uses.

Warrants supplied by referee The CA registers users with a password as in the case of temporary warrants, above. At the start of each session, the user logs in to the CA service with the password, again as in case 2. However, the CA does not supply a warrant to the user's agent. Instead, the agent states the endpoint address of the CA service in each message. When authenticating the message, a service invokes the CA service to get the warrant.

In each scheme, the service requiring authentication has to trust the CA to issue warrants relating only to "proper" users. This means that the CA:

  1. must never issue a warrant for the same identity to two different us-ers;
  2. must never issue a warrant for a falsely held identity;
  3. where warrants are long-lived, must revoke all warrants for which the cryptographic credentials are compromised.

The Shibboleth [cita] system for controlling access to web sites uses the referee scheme. Users log in to a referee service (e.g. using a password). The referee then issues warrants (SAML assertions) that the user is logged in when asked by services needing authentication.

The warrants policies for the EGEE-II and Globus based Grids: proxy certificates

The scheme used for many computational grids, and implemented in the Globus toolkit [cite] is a hybrid of long-lived and temporary warrants. Users (identified by the RA) receive long-lived X.509 certificates from a CA. Using standard SSL it is possible to create a derivative certificate from the original one. This new certificate has a short duration (typically 24 hours). This short term certificate is called "proxy certificates". Proxy certificates are issued by an "end entity" (typically a user or a service), either directly with the "end entity" certificate as issuing certificate, or by extension through an already issued proxy certificate. They are used to extend rights to some other entity (a computer process, typically, or sometimes to the user itself), so it can perform operations in the name of the owner of the user/service certificate (this mechanism is called Delegation).

A warning about proxy certificates

The use of proxy certificates presents also some limitations and possible problems.

(Extracted from OpenSSL Documentation) None seems to have tested proxy certificates with security in mind. Basically, to this date, it seems that proxy certificates have only been used in a world that's highly aware of them. What would happen if an unsuspecting application is to validate a chain of certificates that contains proxy certificates? It would usually consider the leaf to be the certificate to check for authorization data, and since proxy certificates are controlled by the end entity certificate owner alone, it's would be normal to consider what the end entity certificate owner could do with them. subjectAltName and issuerAltName are forbidden in proxy certificates, and this is enforced in OpenSSL. The subject must be the same as the issuer, with one commonName added on.

Possible threats are, as far as has been imagined so far:

  1. impersonation through commonName (think server certifi-cates).
  2. use of additional extensions, possibly non-standard ones used in certain environments, that would grant extra or different authorization rights.

For this reason, OpenSSL requires that the use of proxy certificates be explicitly allowed. Currently, this can be done using the following methods:

  1. if the application calls X509_verify_cert() itself, it can do the following prior to that call (ctx is the pointer passed in the call to X509_verify_cert()): X509_STORE_CTX_set_flags(ctx, X509_V_FLAG_ALLOW_PROXY_CERTS);
  2. in all other cases, proxy certificate validation can be enabled before starting the application by setting the environment variable OPENSSL_ALLOW_PROXY with some non-empty value.

There are thoughts to allow proxy certificates with a line in the default openssl.cnf, but that's still in the future.

Certificate revocation lists

One of the duties of a CA is to maintain a certificate revocation list (CRL) is a list of certificates serial numbers which have been revoked, are no longer valid, and should not be relied on by any system user.

The revocation reasons are well defined [cite rfc3280] :

irreversibly revoked: the CA had improperly issued a certificate; a private-key is thought to have been compromised; failure of the identified entity to adhere to policy requirements; violation of any other policy specified by the CA operator or its cus-tomer.

hold: this reversible statu Currentused to umbient hastemporary invalidity of the certificate. The certificate serial number will be removed from CLR after the security warn-ing has been clarified.

The CRL is generated periodically after a clearly defined timeframe and on the other hand immediately after a certificate has been revoked. The time step is defined by the CA and in a> andf them. is defined are nohis them. "er vali after a cles nohis speciat as st hastempinvalido X509_verifyfined arfined arfin-A is lis1;me re

ty of(upply a xamp>

<)the "A authorized tsf(upply a xamli> m)e isoesources/spoofs thai> to achiclsh/em>ion cabefore starting the apt ord aute ce involveopervate--key hold: Ces on CRL
  • 4> On ld correctlyates". Proxy ce"manag invokes the C"well defined >EUGridPMA . Not to trust a CA may prevent a userll defined rd autte serir by thues waacl,h/em>ion cabefore starorary iO passw,er passed rantptt authentication srai a nehr tender o Eacve are vugh fclidmmunitiese/> X.ital sigfulpleme/>ure genntials cmus. Atheut notabefore starting the apdigital Ont note of the dutSrary iPigital (> <) to we RFC 256/emlicies_for_ts"> Ceul>
  • On> if the irNameoa EUGri,ibynato that owner ooperDPV xampters userd. For Exampll defined ly alloa Thization mechanisms li> wheentity. timefrhatheimthority">ic,dd byritiveheh s.ord assing certificates aro. Fornrr theali after as="twntial he or sh ms. We p: tioe sed For this reaundivathe thloh th valid blemm opera"er vuong-liv.peeular divel ofe age has bX.err theali after a)e ith_Digital_Cert"> Au in practice