Single sign-on authentication for the Virtual Observatory

Goals

Some parts of the VObs need access control:

• any part where a user stores data or changes the system state;
• a minority of archive services where access to the data is restricted;
• services that limit use of resources (storage, CPU time, etc.).

In each of these cases, the available service are based on the identity of the requesting user. Even in the special-but-common case where all professional astronomers get the same level of service, it may be appropriate to distinguish the professionals from amateurs in order to protect the service against 'flooding' or 'Slashdotting'.

Therefore, it is necessary to have ways of communicating and proving a user's identity. Established wisdom is that a single-sign-on (SSO) system is needed in order that

• a user only has to remmeber one password for the entire VObs;
• a user signs in only once per session on the VObs, not once per use of a service;
• services can 'sub-contract' work to other services in a user's name.

This document is a profile for the use of established and emerging web-service standards. It lists and recommends one possible set of techniques for building an SSO system (others are known), refering to the primary standards for the details. The recommendation is in two parts:

1. how SOAP clients prove identity to services;
2. how the identities are set up in the first place.

The first part is better understood and tested than the second. The second part depends on the first. The first part could be adopted by IVOA without the second part.

Authenticating clients to services

Basic mechanism

A client proves identity to a service by digitally signing its messages to that service. The client does this with a public-private key-pair: the message is signed with the private key, which the client holds, and the signature may be checked using the public key, which is sent with the message.

The public key is carried in an X.509-format certificate of identity. The certificate contains the public key and the name of the account under which the client is running. The certificate itself is digitally signed by a certificate authority (CA).

When a service receives the message, it verifies the digital signature of the CA in the certificate and the signature of the client on the message. If both signatures match, and if the service operators trust the CA, then the service trusts that the original sender of the message is the party whose identity appears in the certificate.

The digital signature cannot be verified if any part of the signed message is changed. Therefore, as a side-effect of the authentication, the service trusts that the message has not been intercepted by an attacker and tampered wth during transmission. However, it is possible for an attacker to record a SOAP message in parsing and send the entire message again, possibly multiple times; this may allow a denial-of-service attack. A digital signature does not guard against a replay of the entire message.

To eliminate replay attacks, the client includes in the message a unique identifier or 'nonce', plus a timestamp giving the time of original transmission. The service remembers the nonces of all messages received in some short period (typically five minutes) and rejects all messages with duplicate nonces. To prevent an attacker altering the anti-replay metadata they are also digitally signed by the sender.

What the client does

The client:

1. composes the body of the SOAP message;

1. includes a wsse:Security element in the SOAP header of the message;

1. adds the X.509 certificate to the wsse:Security encoded as a wsse:BinarySecurityToken element;

1. signs the message body and writes the signature into the wsse:Security as a ds:Signature element;

1. adds a wsse:UsernameToken element to the wsse:Security, the former containing a wsse:Nonce element and a wsu:Created element (whose value is the current time);

1. signs the wsse:UsernameToken and writes the signature into the wsse:Security as a ds:signature element;

1. sends the message to the service.

This sequence presumes that the client already has the X.509 certficate. The method by which the client gets that certficate is described below, in the section on public-key infrastructure.

This is an example of the structure of the wsse:Security element in the header.

<wsse:Security 
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
  <ds:Signature>
    <!-- Signature for wsse:UsernameToken -->
    ...
  </ds:Signature>
  <wsse:UsernameToken>
    <!-- Guards against replay attacks -->
    <!-- Username here is NOT authenticated as not signed by CA -->
    <wsse:Username>ivo://ast.cam.ac.uk/Community/GuyRixon</wsse:Username>
    <wsse:Nonce>4cz8rnEhdsjmcie2138ck==</wsse:Nonce>
    <wsu:Created>2004-05-12T14:26:00+01:00</wsu:Created>
  </wsse:UsernameToken>
  <ds:Signature>
    <!-- Signature for SOAP body -->
    ...
  </ds:Signature>
  <wsse:BinaryToken>
    <!-- Certificate used in digital signatures -->
    <!-- Certficate contains the authenticated username signed by CA -->
    ...
  </wsse:BinaryToken>
</wsse:Security>

The use of the wsse:UsernameToken to prove uniqueness of the message is recommended by the WS-I security profile. The use of an X.509 certificate in the signatures follows GGF practice for the Grid. Otherwise, the wsse:Security element is formed according to the rules of the WS-Security standard.

What the service does

On receipt of the message, the service checks that:

1. the wsse:Security element is valid according to its XML schemata;

1. the CA who signed the certificate is one that the service trusts;

1. the certificate is correctly signed;

1. the certificate is not on the CA's 'revoked' list;

1. the digital signature of the message body matches the certificate;

1. the nonce and creation time of the message are not in the log of recent messages;

1. that the signature on the wsse:UsernameToken matches the certificate.

If any of these checks fail, then the service rejects the message.

In fact, the order of the checks is arbitrary.

To perform checks 2 and 3, the service must have the CA's root certficate -- which contains the CA's public key -- pre-installed. The set of CA root certficates that the service uses defines the set of CAs that the service trusts.

Public Key Infrastructure

The public key infrastructure (PKI) is the set of arrangments by which the certficate authority (CA) chooses to whom it issues certificates. It is the basis by which service providers come to trust the users.

Accounts and communities

The identity encoded in the X.509 certficate used in the authentication procedure is treated as an account name. The account is normally operated by a human end-user, so the identity is typically a user name. Accounts might also be established for software agents or services.

The set of identities signed for by a given CA defines a community of users. When we say that a service trusts a CA, as in the service checks above, we mean that the service operators trust that CA to manage the issuance of certificates such that they are not easily misused by attackers outside the community. In effect, the service has to trust the CA's community not to include malicious attackers.

The set of accounts authorized to use a given service forms a separate community that is distinct from the set of accounts that can authenticate to that service (the CA's community). Generally, the authorized community is a sub-set of the authenticatable community. The service needs to establish trust in (the members of) both communities separately. The process for establishing sufficient trust is trickier and slower than the computational processes of authentication.

In the most-basic model for PKI in grid computing (as implemented in the Globus toolkit), the service has to define the authorized community for itself. This means, in effect, that the service operators have to check out and authorize each individual user, and to maintain the user records. This is a large workload in a large grid of services with thousands of users. It is probably infeasible for most service providers.

One alternative approach is to define the authenticatable and authorized communities to be the same. I.e., the service operators assign the same privileges to all users who can authenticate. The operators trust the CA to admit to the CA's community only users who are valid users of the service. This model is a good match to astronomical requirements if and only if the CA communities are the natural communities of astronomy such as university departments and mission teams for space observatories. In other words, the labour of providing services to the VObs may be greatly reduced if natural, astronomical communities operate their own CAs.

IVOA Community services as certificate authorities

The certificates signed by a CA, and the matching private keys may be given by the CA to the certified users, and stored by the users explicitly. This is typical when the CA is a national facility and has no connection with the software in which the credentials will be used. This arrangement causes problems with the security of the private keys and in the way that client programmes get to use the certificates and keys. The latter problem is acute when the user is connected to the client software via a web browser and web portal, but the credentials live on the user's PC. The problem is even worse if the user needs to log on other than from his own PC: in that case the credentials are unavailable.

Alternatively, the certificates and keys may be held securely by the CA and made available via a web service. Client software can download the PKI credentials at the start of a workflow, use them for many web-service requests and then delete the client's copy. This approach suits a community of mobile users who typically connect to the VObs via a web portal.

In a refinement of the second method, the public-private key pairs for the certificate may be generated by the client and the certficate generated on request by the CA using the client's public key. This method avoids the need to send private keys over the network. It is this method that is recommended for the VObs.

What the client does

The client starts with 'SSO credentials': an account name and password pre-agreed with a VObs community. The client wants 'grid credentials': an X.509 certficate and matching private key for the account.

The client:

1. generates a public-private key-pair;
2. composes a request for grid credentials according to WS-trust (section 4.1);
3. adds a wsse:Security header to the message;
4. adds a wsse:UsernameToken to the wsse:Security header, the former holding the accountname and password;
5. digitally signs the message body using the private key from step 1;
6. adds the public key from step 1 to the wsse:Security header as a wsse:BinarySecurityToken;
7. sends the request to the community service using HTTPS.

The client is saying to the community service 'please sign a certficate with my account name and this new key'.

The type of the requested token is wsse:X509v3. The request type is wsse:ReqIssue.

The wsse:Security header and its contents are formed according to WS-Security.

The transport-level security (HTTPS) on this exchange protects the clear-text password.

What the community service does

On receiving a WS-Trust request from a client, the service:

1. athenticates the caller's identity using the wsse:UsernameToken in the SOAP header;
2. checks the signature on the message;
3. composes a new X.509v3 certficate with the client's chosen public key and the account name, and sets a limited lifetime (24 hours by default) for the validity of the certificate;
4. digitally signs the certificate;
5. composes a response message according to WS-Trust (section 4.2) including the X.509v3 certificate;
6. sends the response to the client.

The new certficate is signed using the CA root certificate held by the community service. This makes the certificate valid in the basic authentication-process described above.

-- GuyRixon - 17 May 2004