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.

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 sender is previously known to the service, or
• a trusted third party vouches for the sender.

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:

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

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 (~10⁴ 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:

• registers users;
• manages user groups;
• manages authorization data;
• issues warrants.

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

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/