Delegation of a user's identity to software agent

This paper expands the technical detail of the architecture suggested in SecurityArchitectureFor2005.

When a user signs in to a software agent with a UI, he or she delegates identity to that agent. The agent can use all access rights associated with that user account. The agent may be a programme running on the user's desktop or it may be part of a web portal: call it the "user agent".

The access rights typically allow that agent to command other services - call them "payload services" - in the user's name. User agents and payload services can be modelled as specializations of the general class of software agents. In this representation, all agents share some security features. The software agent types are the entities that can be in the "chain of command" from the user to the scientific resources in the VO.

When the user signs in, the user agent receives an account name and a password. The account name is assumed to be known and valid at all payload services where the user agent can assert access rights. The password is not globally valid; all agents except user agents require authentication with cryptographic keys and signed identity certificates, not with passwords.

The user agent generates a cryptographic key-pair at the start of each session, when the user signs in. The agent retains the private key in memory; this key is never committed to disc or transmitted across the network, and it is discarded at the end of the session. To make the matching public key useful for authentication, the key must be embedded in an X.509 identity certificate and signed, by a certificate authority (CA) to bind it to the user's account name.

The agent gets the certificate by calling a SSO service. The agent passes the account name and the public key and authenticates its right to use the identity with the password. The SSO service creates and signs the X.509 certificate and sends it back to the agent.

The messages to the SSO service need to be encrypted to hide the passwords.

The agent can now use the certificate to authenticate the user's identity to any number of other agents, and especially to payload services. It can do this because it holds the private key matching the public key in the certificate.

In a distributed, grid-like system, the user agent may not talk directly to payload services; there may be workflow executors or broker services or autonomous, intelligent agents in the chain of command. In this case, the user may wish to delegate identity beyond the user agent. This is done by allowing the agent receiving the new delegation to sign on via the SSO service in the same way that the user agent did. This leaves the agent with a key pair and a certificate in the user's name bound to the key pair. The agent can then authenticate to the payload services. This pattern can be repeated to successive levels of agents as required.

The system is more secure against misuse if the agents do not retain the user's credentials for long periods. Hence, the user agent does not keep the SSO password after the sign-on sequence and the certificates issued at sign-on are only valid for a short time (possibly a day). Therefore, it is not desireable that the user's SSO password, which is valid indefinitely, be shared among the agents. Instead, an agent that has received a certificate from the SSO service may also request a temporary password for that identity. The agent can then delegate the identity by passing on the temporary password. The temporary password may be valid for only a few minutes, and the SSO service may further restrict it to be valid for only one authentication.

The authentications in this scheme may be either at transport level (e.g. HTTP basic-auth or SSL handshakes) or at message level (e.g. WS-Security for SOAP messages). Messages carrying passwords are encrypted, either at transport level or at message level. Other messages need not be encrypted.

There are mutiple SSO services. There may be one such service at each place where users are registered, or there may be one per regional virtual-observatory project (e.g. one for AstroGrid, one for NVO, etc.). The distribution of the CAs dictates the distribution of the SSO services as each SSO service includes its own CA. It is extremely unlikely that there will ever be one CA for the entire virtual observatory, so multiple SSO services are expected.

Each agent that obtains certificates must be able to find the appropriate SSO service for the user. This is simple if the distinguished names of users, which are passed between agents and between agents and SSO services, include or are linked to the names of the SSO services. Therefore, a distinguished name for a user of the virtual observatory needs to include the name of the community running the SSO service where the user is registered. The SSO service itself can then by found through the IVO resource-registry.

-- GuyRixon - 26 Apr 2005