Possible IVO security architecture for 2005

These are my thoughts on how IVOA might secure its services in the short term. The choices are mine (except where attributed), but the ideas come mainly from others.

Ephemeral architecture

We need to use standards for expressing security tokens and messages in order that we can use existing code for handling those things. Most of these standards, particularly the web-service variety (those named WS-*) are not yet fit for use. Some are not standardized; some are not stable; some are not supported by code suppliers; some have implementations but the code is poor. It is not currently clear which of these standards will become finished and supported, which will mutate before final issue and which will be abandoned.

Any draft-standards-based architecture that we might choose in 2005 will turn out "wrong" within three years, when the real standards have emerged. We will have to change at least some parts.

We can't afford to wait until enough of the draft standards have matured. We need to apply security in 2005. Therefore, we need to choose a temporary architecture from which we can discard or replace parts as better standards become available. Our security architecture needs to be cheap rather than comprehensive or elegant.

Creating accounts

Individual users have accounts managed by on-line communities. The communities are usually local to the user's home institution, although a community may also allow members from other places or organizations.

Managers of communities make arrangements with providers of restricted services for their community to use those services. Each such arrangement creates a group account at the service for some group within the community; the default group is the whole community. The agreement specifies who may be allowed into the group and the terms of useage of the service. By the agreement, the service provider delegates management of the group to the community operators.

At no point are end users required to register in person at particular services. Communities are not required to register their users individually at services. However, there is a group for each user containing only that user's account, so services can arrange different access rights for each user if necessary.

The arrangements between communities and service providers are made by human contact. They are not mediated by IVOA-standard software and we do not have to define the details of the process. An email exchange will usually be sufficient.

When a service provider makes an access arrangement with a community, the service provider has to set up his or her services to recognize the group accounts involved and to allow the correct access for those accounts. I.e., the service provider has to manage authorization interally. This is discussed in later sections.

In making an access arrangement with the community, the service provider is undertaking to accept digital identity certficates issued by that community; see later sections for details of these certficates. The provider will typically have to import the community's root certificate into his or her services.

The community operators have to manage the membership so as to satisfy the arrangments with the service providers. Some groups may contain accounts only for users known to the community operators; others may contain unverified users. Notably, the community could admit users verifiying only their email addresses and not their real identity, such that users could get access quickly to some lightly-controlled parts of the IVO. In this case, the community would typically have groups of users who have been properly verified.

The ideal scope for a community is one university department. Within the department, all potential users are known to the community administrators, or can easily prove their identity to those administrators. If a user misues services, the department has legal sanction against that user. (This is important in theory; I would not expect these sanctions ever to be invoked in actual usage.) The department is aware of the natural user groups for its members. If resources are available by subscription (e.g. electronic journals), then the subscriptions are typically handled by the departments.

Smaller communities are possible, e.g. research groups within a department, but smaller communities mean more work. Larger communities, e.g. entire universities, are possible, but a large community may not cooperate well in setting up the right groups for the IVO.

End-user accounts are IVO resources and are named by IVOIDs. Community operators may assign the names using the identifer of any resource-naming authority that they control. It is much easier and cleaner if each community has an authority ID just for naming its members; in this case, the community typically runs a publishing registry that owns that ID. Resource documents for accounts should be of type {http://www.ivoa.net/xml/VOResource/v0.10}Organization.

When a user joins a community, the community tells the user the account name (IVOID) and a sign-on password. No other security credentials, such as identity certficates are given to the user to keep and manage.

Signing on to the IVO

Each community runs a sign-on service. A member of the community (more exactly, a member's software agent) may sign on here using the account name and password.

Signing on creates a cryptographic key-pair with the public key embedded in an X.509 certificate signed by a certificate authority within the community. In fact, the agent creates the key-pair locally and passes the public key only, together with the account name and password, to the sign-on service. The service puts the public key into the certificate, signs it and hands back. The private key is never sent across the network and, because a new key-pair is used for each session, is never committed to disc.

The software agent that signs on at the community may be a programme on the user's desktop, or it may be embedded in a web portal. In the latter case, the user signs on to the portal, using the account name and password, the portal forwards the credentials for checking, and the portal keeps the private key and certificate. Web browsers do not need to work the sign-on service directly.

The sign-on service is a SOAP service.

Authenticating to services

To use a service, an agent has to authenticate its use of a group account known to that service. The service site can then check the authorization for the request from its internal records.

The authentication process has four stages.

1. The service establishes that the request comes from an entity holding a certain private key.
2. The service determines the individual account to which the private key is bound.
3. The service determines the community that defines the individual account.
4. The service determines the group or groups associated with the individual account.

Stage 1 can be done either with transport-layer or message-layer security. In transport-layer security (TLS), the agent calls a HTTPS service and uses the key-pair and certificate derived at user sign-on. The service need not be a SOAP service. In message-layer security, the agent calls a SOAP service and signs the SOAP request using the key derived at user sign-on. (Q.v. the discussion of delegated powers, in later sections.)

Stage 2 is simple: the account name and community name are part of the identity bound to the public key in the identity certificate.

Stage 3 involves finding the "attribute server" at the community. Two approaches are possible here: either infer the location of the attribute server directly from the certificate or find it indirectly using the IVO resource registry.

Stage 4 requires looking up group membership on the attribute service; it is a SOAP service. A call to this service, stating the name of the individual account-name, returns a list of groups names. The encoding of attributes, and the protocol used to get them from the attribute service, are defined in the Security Assertion Markup Language (SAML).

Attribute statements can either be obtained by the agent and sent with the request message, or can be obtained by the service after the request is received. In each case, the attribute statements are bound to the key pair used to authenticate the request. In SOAP messages, the attribute statements can be passed in the message header. Attribute statements can be cached by the target service to improve performance.

The Shibboleth system uses attribute servers. A Shibboleth attribute server would respond as needed for this protocol if the server had been loaded with the necessary information. Therefore, communities where there is a Shibboleth installation can use that installation provided that they are allowed to set attributes for users.

Standard Shibboleth does not use X.509 certficates for authentication. Instead, it has a rather weak system of "handles" that covers stage 3 of the procedure above. This part of Shibboleth is not suitable for agent-to-service communication in the IVO, especially for SOAP services. The "GridShib" project, currently under development at NCSA, replaces the name-mapping part of Shibboleth in the target service with a module that can map from an X.509 certificate to an attribute service. This would be very suitable for the IVO.

Delegation of rights

Frequently, requests are delegated to subsidiary agents. In this case, the subsidiary agent needs to be able to work the authentication system; i.e. it has to be able to obtain a key-pair and certificate that are associated with the right groups. This can be done in two ways.

Firstly, the subsidiary agent may be able to get a copy of the key-pair and certificate generated when the user signed on. This case applies if the subsidiary agent is associated with the portal where the user user signed on such that private key can be transferred securely.

Secondly, the subsidiary agent itself can sign on to the community and get new credentials. This is done as a three step process.

1. The delegating agent calls the sign-on service to get an identity-delegation "ticket".
2. The delegating agent calls the subsidiary agent as a service, passing on the ticket.
3. The subsidary agent calls the community sign-on service, passing the ticket in place of the user's password, and gets a new certificate.

The ticket is an opaque object used as a single-use password. Its form is set by the community sign-service that generates and consumes it and need not be the same from community to community. In general, the ticket should be a cryptographically-random string that is both secret and hard to guess.

The procedure above delegates the right to use a user's identity and therefore delegates all the user's rights. Sometimes, an agent may want to delegate a specific access right. In this case, the delegating agent obtains a ticket not from the community sign-on service but from the service where the access right will be used. This is passed to the subsidiary agent. The subsidiary agent calls the target service using a different authentication method: user name and password, with the ticket as the password. This case is particularly suitable for granting access to a particular node in VOSpace.

Implementation notes

To make this work, we need a mixed bag of parts.

• A sign-on service for the community.
• An attribute service for the community.
• An authentication handler for the services.
• A delegation handler for services that also act as agents.
• An authorization plug-in for target services.

AstroGrid needs to build the authorization module so as to have a complete solution for our customers. IVOA does not need to define this module since services do not expose it to the IVO.

The attribute service can be taken from Shibboleth. The authentication handler can be adapted from GridShib . The operations for low-level authentication (proving possesion of private key) should be available on all platforms if we stick with TLS for now. The sign-on service and delegation handler have to be built specially for this architecture. We may be able to use PERMIS for the authorization.

Features to leave out

The following are features that I think we should avoid until the standards and support stabilize.

• Authorization at the community level. This needs elaborate protocols and XML vocabularies. We cannot afford to design our own only to have them made obsolete in 18 months time.
• Anti-replay protection. Some SOAP systems using MLS (e.g. GT3) use the WS-SecureConversation protocol to defeat "replay" attacks. WS-SecureConversation is complex, is not a standard and is not yet well supported. We should not waste time trying to implement the draft standard. We don't really _need) replay protection for low-end security. TLS connections provide automatic replay protection.
• Federation of identities between communities. It's simply too hard and there are too many ways to do it.
• External CAs. Ultimately, we want to be able to use certificates issued by national or international CAs. The details of how to do this are tricky and will be dictated by the up-scale CAs and by national e-Science projects. We should not try to make it work ourselves until the large power groups have sorted themselves out.

Future directions

Remember that most of the detailed implementation will be made obsolete in 2006 or 2007. That said, the general form of the system aligned with current ideas in the grid world which is in turn aligning with ideas in the web-service world.

I expect the comunity idea to persist. The communities may expand from department-sized to campus sized as more sites adopt Shibboleth.

I expect the arrangements between communities and service providers to persist in the form described. This idea was taken from a GRIA pattern for commercial grids and may become common in commercial SOAs. As the IVO grows, we may add some paterns of federation between communities and services to ease the book-keeping.

As WS-Security gets more support we may well change services from TLS to MLS.

The delegation pattern is likely to change. In time, the grid and web-service communities will make standards for delegation and we should probably change to use those standards. It may be that the details change but the basic patterns are similar.

If we use standard delegation protocols, then we can probably use standard sign-on services.

The web-service world will probably standardize services for flexible, distributed authorization. When it is stable we can probably use it for the advanced cases.

-- GuyRixon - 18 Apr 2005