Single-sign-on authentication is defined and mechanisms for its implementation are introduced. Digital signatures, identity warrants, certificate authorities and community-management services are all briefly described. The proposed form for the SSO system for the IVO is outlined: authentication by digital signature plus warrant of identity, encoded using WS-Security; warrants issued by certficate authorities inside the IVO; management of warrants by services representing astronomical communities.
This is a Note. This is the second working-group draft of the first release.
This is an IVOA Note expressing suggestions from and opinions of the authors. It is intended to share best practices, possible approaches, or other perspectives on interoperability with the Virtual Observatory. It should not be referenced or otherwise interpreted as a standard specification.A list of current IVOA Recommendations and other technical documents can be found at http://www.ivoa.net/Documents/.
An authenticating system requires a user to prove his or her identity (to the software, typically by presenting a password) when requesting use of the system. A single-sign-on (SSO) system requires this authentication once for each session of use regardless of the variety of resources used or the number of commands sent to those resources. A 'session' is typically the run-time of a a client programme such as a web browser. Closing and restarting the client implies the start of a new session for which reauthentication is required.
In the context of the IVO, we take SSO to mean that a user authenticates to the entire VO once per session and that this grants access to all archives, storage and processing facilities that the user has a pre-arranged right to use. SSO authentication is not a registration process, nor is it an authorization process. Rather, SSO authentication is the means by which a user proves that he he or she has previously registered and been authorized to use services.
Conceptually, the simplest way to achvieve 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 drawbacks.
Therefore, shared password systems are not really suitable for the VO.
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 is an alternative to transport security, in which a secure connection is created to carry the messages. Transport-layer Security (formerly known as Secure Sockets Layer) is an example of transport security. 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 public-key cryptography. In this paper, and generally in VO work, we shall be concerned only with digital signatures.
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.
Authentication - proof of the sender's identity - and protection of message integrity are separate functions but both can use the same credentials and mechanisms.
If a message is signed, then the receiver knows that it came from the party holding the private key matching the public key with which the signature was checked. If the receiving service associates that public key with a user identity, and if the service also trusts that only the appropriate user has access to the private key, then the service trusts that the message came from the known user; i.e. the user has authenticated.
The agent and service can exploit this way of authentication if the user registers his/her public key with each service ahead of time, using a trusted channel that is distinct from the run-time messages. This done, the service has a trustable link between the key pair and the user's identity. The secure shell (SSH) system works this way. However, the burden of pre-registering the key with all services remains; the work quickly becomes infeasible as with the password case.
If the user is unknown to the service at runtime but includes the public key in the messages, authentication is not acheived. The service can check the signature in the messages but has no reason to trust the user's professed identity. However, It is possible to authenticate users with digital signatures and without pre-registration at services: a warrant of identity from a third party is needed.
A service may trust the professed identity of the sender of a message if
The latter case is the one that applies in the IVO.
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:
Both kinds could reasonably be called "identity certificates", but that term is commonly used to mean specifically X.509 certificates. Therefore, I introduce the generic term "warrant" to cover both forms.
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. SAML is a newer standard and is growing in popularity, For Example, the Shibboleth  system for controlling access to web sites requires SAML.
Both forms of warrant can be given a limited lifetime, chosen by the issuer.
Where X.509 certificates are used, they are signed and issued by Certificate Authorities (CAs). Since SAML assertions work in a similar way, I will use the same term for the issuers of both kinds of warrant.
A CA must check a user's identity before issuing a warrant 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 major difference in SSO schemes consists in how the warrants are passed out and communicated to the services that need them. Three schemes are relevant here.
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:
The reliability of a CA is determined by the quality of these checks. Each service has to choose whether to trust the PKI operated by a particular CA. Choosing not to trust a CA may prevent a service provider from joining a particular grid of services, or it may prevent some users of that grid from using the service in question.> One of the major problems of authentication by digital signature is to get all providers to trust all the CAs used by the user base.
The scheme used for many computational grids, and implemented in the Globus toolkit  is a hybrid of long-lived and temporary warrants. Users receive long-lived warrants (X.509 certificates) from a CA and use these to create derivative warrants called "proxy certficates". Only the proxy certficates are sent to services. The CAs are typically national organizations.
The Shibboleth  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 purpose of authentication is to support access control by allowing the level of authorization to vary between users. This implies that each service provider should maintain a database of users authorized on that service and their privileges. Some services do work this way.
However, the VO may eventually grow to have tens of thousands of users (~104 professional astronomers and a greater number of occasional users in education and the general public). It is unreasonable to ask all service providers to manage this user base.
In general, users are naturally grouped, by nationality, institution and project, and access rights are granted more often to groups than to individuals. It is quite feasible for each service provider to manage the allocation of access rights to the groups provided that some other body manages the group memberships. We can call this body a "community".
A community manages the individual, on-line identities of its users such that only known individuals get credentials; i.e. it prevents identity theft. Given that the IVO is to use identity warrants to identify individuals, an IVO community must be involved in the issue of these warrants. This can be done in several ways
Case 3 allows a community to signs its own warrants, but does not require service providers to establish trust with each individual community. Instead, the service provider establishes trust with the higher-level CA.
Where a service provider bases authorization decisions on group membership, his or her services must be able to determine the group membership of an authenticated user. This is best done by sending to the service warrants stating that membership. It seems reasonable that the source of the identity warrants should also be the source of the group-membership warrants. An IVO commmunity is well placed to supply both. It may be possible to combine identity and group membership into one warrant.
The ideal community is sized such that the community managers can know all the members personally. Typically, we should expect a community in every HEI that has an astronomy department.
In the discussion of digital signature, above, it is assumed that all client programmes have credentials for the user on whose behalf they make requests. The credentials are an identity warrant, probably an X.509 certificate, and a matching private key. So equiped, a client application can make authenticated requests to web services.
Frequently, requests to web services imply subsidiary requests to other web services. One example is a query to a Data Access Layer (DAL) service that causes it to write results to a VOStore. The DAL service needs to authenticate its request to the store as coming from the user that sent the query. Since a VOStore is a SOAP service, the DAL service ought to sign the request with the user's private key; but the DAL service doesn't have that key. To proceed, the application has explictly to delegate some signing powers to the DAL service.
Signing powers may be delegated by generating "proxy credentials" in the DAL service. These consist of a private key chosen by the DAL service and a proxy warrant containing the matching public key. The proxy warrant is signed by the client application using the user's private key.
To authenticate to the VOStore, the DAL service signs the message with the private key from its proxy credentials and includes in the message both its proxy warrant and the warrant that it received in the request from the client application. The store validates the proxy warrant using the warrant sent from the client and then verifies the client's warrant using the pre-agreed CA certificate.
Note that the DAL service cannot generate working proxy credentials without the aid of its client; the client has to sign the proxy warrant to make it valid. Futhermore, the client cannot generate the proxy credentials without the aid of the DAL service as the latter has to generate the key-pair. Thus, the delegation cannot happen in a single message from the client to the DAL service. At least two messages are needed: one to send the unsigned copy of the proxy warrant to the client and another to send back the signed copy.
Two approaches have been used by the grid community to enable delegation of proxies to web services. In the first, the messages exchange for delegation is made part of the transport protocol; e.g. the HTTPG protocol used by v3 of the Globus Toolkit adds the delegation exchange to the Secure Sockets Layer handshake. In the second, the delegator invokes two special SOAP operations on the service: one to request the unsigned proxy warrant; the second to deliver the signed warrant; both these operations precede the SOA request in which the delegated powers are used. It has proved to be easier, ultimately, to leave the transport protocol alone and to add the extra SOAP messages.
It is important to note that this form of delegation lets the delegatee use the delegator's identity without restriction. It is theorectically possible to modify the warrants to restrict the allowed use, but schemes that do this quickly become over-complex. Delegation of identity, also known as "delegation by impersonation" is the grid standard.
Proxy credentials typically have short periods of validity; one day is a common lifetime. This limits the liability if the proxy is compromised. It has become common practice in grid computing to issue only a limited proxy even to the initial client applications, keeping a user's long-term credentials away from the network. Taking this one step further, a community service can issue proxy warrants to clients. The MyProxy protocol is one such system.
The implementations of limited proxies in grd computing all use X.509 certificates. It would be possible to reimplement the idea using SAML assertions or some other form of warrant, but the available tools all assume X.509.
This is a summary of the recommended form of the IVO's SSO system. The normative specification is in two other documents, one defining the structures included in messages and the other defining the community services providing the PKI.
 OASIS Security services technical committee
 Internet Engineering Task Force, RFC2459
 Internet 2 Project, Shibboleth introduction
 Globus project