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) and receive a key pair in return. 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.
Frequently, a service provider may wish to assign a privilege, such as a certain amount of storage space, to a community, such as a university department. The service provider does not care who in that community gets the space and does not want to manage the detailed access rights. Sometimes, the provider wants to assign the rights to just a group within a community, such as a project team within a department. The community, or group within the community, manages the division of the rights between its members.
This community authorization requires that a user authenticate not just as an individual but as a member of a community and possibly as a member of a group within that community. Multiple warrants are needed, or the warrant format must carry multiple assertions within one warrant. Additional warrants, or assertions in one warrant, are needed to express the privileges of the individual user assigned by the community.
Clearly, there is a need for a software service representing a community. This service:
The community service is thus a form of CA. It has the advantage over national CAs that the members of the on-line community are normally members of a real-world community and thus known to the community administrators. This makes registration easier and more secure. A second advantage is that the warrants issued by the community have a limited range of application. The warrants from an astronomy community will never be used for, say, on-line banking and need not be secured to the standard required by a bank. Therefore, the registration checks can be made more easily.
It is possible to combine community warrants with external warrants. A user may use an X.509 certficate as a warrant of his individual identity together with SAML assertions from a community service to prove membership of the community and groups.
It is also possible to make the communities the only CAs. To do this service providers must trust the communities as CAs; but this may be easier than establishing trust between service providers and CAs outside astronomy. In any case, service providers would need to trust communities to issue warrants for group membership.
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