IVOA logo

Single-Sign-On Authentication for the IVO: introduction and description of principles
Version 0.1

IVOA WG Internal Draft 2004 July 6th

Working Group:
http://www.ivoa.net/twiki/bin/view/IVOA/IvoaGridAndWebServices
Author(s):
Guy Rixon

Abstract

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.

Status of this Document

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

Contents



1. Single Sign-On: definition

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.

2. SSO with passwords

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.

  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 system is not secure by default. An attacker can learn a password by reading an authenticated message. Since, in a simple system, the passwords change infrequently, reading one message unlocks the whole VO for the attacker.

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

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

4. Authentication from digital 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.

5. Identity warrants

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 [3] system for controlling access to web sites requires SAML.

Both forms of warrant can be given a limited lifetime, chosen by the issuer.

6. Certificate authorities

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.

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 run-time SSO system.
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 run-time 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 services 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 users;
  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 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 [4] 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 [3] 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.

7. Communities

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.

8. Recommendations for the VO

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.

Use digital signature plus warrants for authentication
The VO should use the basic practices described above in preference to shared password files or pre-registration of public keys at each service site.
Use WS-Security to encode the signatures
WS-Security defines an XML vocabulary for encoding the signatures in SOAP headers.
Use community and group warrants
The VO should provide warrants to prove users' membership of communities and groups. The VO should prvoide the infrastructure services to provide these warrants.
Use community warrants for individual identities
The community services should provide warrants of individual identity, if users choose to use these (some users and services may prefer external warrants).
Use communities as registration points
To use restricted services in the VO, a user should register with one or more VO communities.
Use community services as sign-on points
A user authenticates, once per session, to the service of the community where he/she registered using a password agreed with the community service during registration. Authenticating to the commnity gives the user's agent the warrants it needs to authenticate in the rest of the VO.
Don't issue long-term warrants
Long-term warrants are a security risk if the corresponding keys are compromised. Cancelling and replacing a long-term warrant is awkward. VO communities should issue only short-term warrants.
Issue warrants to user agents, not to users
Warrants in the VO should be given to a user's agent (e.g. a thread of control running in a portal application). They should not be given to the users per se. If the warrants are held by the user agents and last only for one interactive session, then they do not need to be written to disc. This removes many security risks. In any case, users don't want to manage their warrants manually.
Don't bother with revocation lists
When long-lived warrants are used, services are supposed to check certficate revocation lists before trusting the certficates. When short-lived warrants are used, the warrants are automatically revoked.
Use SAML assertions
X.509 and SAML are roughly equivalent systems, but SAML is better at combining assertions in one warrant. Since a warrant from a VO community typically asserts individual identity, community membership and group membership, combining assetions is good.
Allow X.509 certificates
Users may wish to use X.509 certficates from external CAs to prove individual identity. The VO should allow this, even though SAML is preferred for warrants issued inside the VO. Therefore, authenticating code running in services should accept both X.509 and SAML.

9. Glossary

Account
A record of registration of an identity (q.v.) at a community (q.v.); therefore, logically, a combination of the identity and the community name. There may, in principle, be more than one account per identity (at different communities), but IVOA prefers users to have only one account and may choose to enforce this rule by making each identity specific to one community. A user must have an account for an identity in order to get identity warrants (q.v.) issued for the identity.
Authentication
(1) The act of verifying the identity professed by the sender of a request to a service. In the IVO scheme, verification is by a combination of signature and identity warrant and also verifies the account (q.v.), since the CA for the identity warrant is the community hosting the account. (2) The act of verifying group membership. In the IVO scheme, this is done with a group warrant referring to a separately-authenticated account.
Authorization
(1) The act of associating access rights with an account (q.v.) or with a group (q.v.). In the IVO scheme, we expect most rights to be assigned to groups. (2) The act of checking that the sender of a request has the right to have the request carried out.
Certificate authority (CA)
Any party that can digitally sign a warrant (q.v.). The usefulness of CAs depends on the trust put in them by the receivers of the warrants.
Community
A set of user-management services associated with a set of accounts (q.v.). A community operates a registration scheme by which users join the community. A community operates a certificate authority for its accounts; i.e. it may issue identity warrants (q.v.) for those accounts, but not for accounts in other communities. The community may also operate a register of groups; i.e. it records the membership of groups (q.v.) and may issue group warrants (q.v.)
Group
An association of accounts (q.v.) for which the user identities share some common attributes that are relevant to access control. Typically, access rights are granted to a group rather than to a single account. Note that it is accounts that form a group, not identities by themselves.
Group warrant
A warrant (q.v.) associating a group membership with an identity. The warrant is only useful in combination with an identity warrant (q.v.) for the identity concerned.
Identity
The name of a party using the IVO. Identitys can be associated with accounts (q.v.) and written in identity warrants (q.v.). Identities must be unique in the IVO. In principle, each user should have only one identity; in practice, it is hard to see how this could be enforced.
Identity warrant
A warrant (q.v.) associating an indentity with a public-private key-pair. The identity and the public key are present in the warrant. X.509 certficates are a common form of identity warrant.
Warrant
Any digitally-signed security assertion. To be useful, a warrant associates one security attribute with a second, verifiable attribute; e.g. 'the bearer of this warrant is a member of user-group G provided that they can authenticate the identity I'.

References

[1] OASIS Security services technical committee
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security

[2] Internet Engineering Task Force, RFC2459
http://www.ietf.org/rfc/rfc2459.txt

[3] Internet 2 Project, Shibboleth introduction
http://shibboleth.internet2.edu/shib-intro.html

[4] Globus project
http://www.globus.org/