International     Virtual     Observatory Alliance

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

IVOA Note 2005 October 02

Working Group:

not applicable

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

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

1. The community may operate its own, internal CA.
2. The community may operate as a registration authority to an external CA.
3. The community may operate its own CA, but with a CA certificate signed by a higher-level CA.
4. The community may delegate all processes to do with warrants to a specifc, external CA.

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.

8. Delegation of identity by proxy credentials

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[5] 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.

9. 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 to SOAP services

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 X.509 certificates as warrants in preference to SAML assertions

Most existing PKIs in academic computing use X.509 for identity warrants, and most web-service tool-kits are set up to handle X.509. Conversely, few toolkits handle SAML.

Use WS-Security to encode the signatures

WS-Security defines an XML vocabulary for encoding the signatures in SOAP headers.

Use attribute warrants

The VO should provide warrants to prove users' membership of communities and groups. The VO should provide the infrastructure services to provide these warrants. The recommendation to use X.509 for the warrants of personal identity need not apply to the attribute warrants: we do not yet know the best way to encode these.

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). This means that communities should either operate their own X.509 CAs or should cooperate with CAs in their parent VO project.

Use communities as registration points

To use restricted services in the VO, a user should register with one or more VO communities.

Support external CAs

Where users have X.509 certificates issued by a widely-accepted CA that is external to the IVO communities, the IVO should allow use of these certificates. Any given user should have the choice of getting warrants from their IVO community or from an external CA.

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 to users

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.

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

[5] MyProxy
http://grid.ncsa.uiuc.edu/myproxy/