IVOA single-sign-on profile: trust model
Version 0.1

IVOA WG Internal Draft 2005 May 05

Working Group:

http://www.ivoa.net/twiki/bin/view/IVOA/IvoaGridAndWebServices

Author(s):

Guy Rixon

---

Acknowledgments

The ideas presented here have been gathered from many sources; few, if any, of the concepts are original, but the synthesis may be something new.

My understanding of the basic requirements comes from discussions in the AstroGrid-1 project (2001-2004), furthered by discussions in the GWS-WG of IVOA. The basic community concept came from the same sources, although the form presented here is somewhat different from the AstroGrid plans. The division of responsibilities (service provider defines authorization, community defines group membership) was refined by discussion inside IVOA; previously, the plan was to make authorization decisions inside the community.

The imperative to use X.509 for authentication and the delegation of identity comes from the Grid world and especially from the Globus alliance (although the  techniques involved predate the grid movement).

The possible usefulness of "weak" certificate authorities was suggested by Ray Plante in an email discussion on the GWS-WG list [Plante].

The need for stronger control of access delegation was pointed out by Dave Morris and Wil O'Mullane at the IVOA meeting of 2004, in Cambridge MA. This has led to the detailed requirements for use of warrants.

Reagan Moore proposed the need to interoperate with Shibboleth [Shibboleth].

The use of the attribute service was copied from the Shibboleth design.  The actual protocol is taken from the SAML specification [SAML], but without Shibboleth as a worked example I'd never have understood what the SAML TC intended.

The idea of combining a Shibboleth system with PKI-based authentication is taken from Von Welch's "GridShib" project, which he outlined at the UK e-Science workshop on security of April 2005 [e-Science].

The concept of community operators settings up group accounts with resource providers was taken from a GRIA use-case also presented at the UK e-Science workshop [e-Science].

The process of delegating credentials between agents was refined in discussions with Carlo Nicola at IoA Cambridge.

Contents

1. Introduction

The single sign-on (SSO) system proposed for the IVO presumes [SSO introduction] the use of identity warrants (i.e. statements of identity digitally signed by some authority) for authentication of agents requesting services. The use of warrants presumes a Public Key Infrastructure (PKI) for their issue and a PKI presumes a convention under which service providers can place trust in the output of the PKI. This document describes that trust model.

The trust model defines two things: the agreements that have to be made in order for users and services to participate in the IVOA SSO system; and the software services that have to be provided, in addition to the astronomical services, to make the model work.

2. The community concept

Access rights to restricted resources tend naturally to be granted to groups of users. E.g.

• Researchers in ESO-member countries have early access to images in ESO archives.
• British scientists can use computers of the National Grid Service.
• University departments may buy subscriptions to electronic journals.
• A research group inside a department has access to a remote supercomputer.

In each case, this access is enabled by an agreement between the provider of the resource and some party taking responsibility for the group.

In this trust model, a community is formally a group that manages its membership in a systematic way.  A community typically has sub-groups that are not themselves self-managing communities. A super-group may be formed by the union of communities, or of selected sub-groups within communities.

The virtual observatory should create a software system that mirrors the natural groupings of users and makes these groupings useful for authentication, authorization and accounting (AAA). Service providers can then trust software agents requesting service on the basis of the agent's relationship to the communities and groups. (Trust, in this context, means specifically that the provider believes that the agent has the right to use the identity that the agent professes. [Harrison])

Users of the virtual observatory are expected to join a community and be assigned membership of groups according to their real-world situation. Operators of communities contact providers of restricted resources to arrange access for community members: they create group accounts at the resource sites. Community operators run software services that allow users (technically, software agents acting for users) to prove their community membership to the resource sites.

There should be no need for individual users to register directly with resource providers. If the IVO required this, then the administrative load on the resource providers would be too high.

The ideal size for a community is the greatest grouping of users who are all known a priori to the community manager. When the users are known to the manager, then registration is easy. If communities are smaller, then registration is still easy but more arrangements have to be made between communities and providers. If the communities are larger, fewer arrangements are needed but registration is harder and slower for end-users. A typical community in the IVO should represent a university department.

Communities may be federated into a hierarchy. E.g., there could be a community representing  the US NVO. Users registering with a community at, say, Caltech, would automatically become members of the NVO community. Some service providers could then assign access rights to the NVO community and would not need to make separate arrangements with Caltech. Other providers might assign resources only the Caltech community.

3. Setting up a community

When setting up a community from scratch, the initiators shall do the following:

1. Appoint named individuals as community operators. These persons become responsible for the proper operation of the community.
2. Register the community in the IVO resource-registry as a resource of type Organization (see annex A for details).
3. Define the rules for admitting members to the overall community. Note that the rules determine the likelihood that service providers will trust the community and its CA. The community initiators should consult with the major service providers to determine suitable rules. See the section on registering users for more detail.
4. Set up a mechanism for registering users, in accordance with the rules of step three. This mechanism include the human procedures and any registry service that the community uses to record membership.
5. Set up a certificate authority (CA) and associate it with a sign-on service such that a software agent bearing a community-member's password may be issued with a short-term identity certificate. See the sections on registering users and on warrants for more details.
6. Set up an attribute server from which service providers can request assertions of  identities and group memberships associated with an identity certificate. See the section on warrants for more details.

4. Agreement between a community and a service provider

4.1 Content of the agreement

The agreement between a service provider and an community operator should be made by human interaction, possibly by email, rather than by some automated process in software.

The service provider and community operator shall agree on the service level to be provided to a group within the community, and on the allowed membership of that group. The group may already exist, or a new group may be defined for this agreement. The agreement shall be recorded by both parties.  It may be useful to publish the agreement as a page on the WWW.

The agreement should contain, or refer to, the service provider's terms of acceptable usage. By making the agreement, the community operator agrees to inform group members of these terms. The agreement may require the community operator to apply reasonable sanctions against users who do not conform to the terms of use.

The agreement shall define the certificate authority (CA) to be used by group members when authenticating to the services in question. The service provider agrees to trust certificates from this CA for authentication of agents requesting access to the services.

The CA must be one for which the community services can sign certificates, as discussed below. This means that the service provider cannot specify an arbitrary CA., but must choose from the CAs that the community supports. Wherever possible, the provider should choose the CA operated by the community itself.

One agreement can cover any number of user groups within the given community.

4.2 Implementing the agreement: community operator

The community operator shall create the group if it does not already exist. This is an act of configuration in the community servers; it does not make a record in software at the service provider's site.

The community operator should name the group using an IVOID, according to the rules of annex A. The community operator should register that group in the IVO resource registry.

4.3 Implementing the agreement: service provider

The service provider shall grant the agreed access to the group. This is an act of configuration in the authorization software at the provider's site; it does not make a record in software at the community's site.

The service provider shall arrange to trust certificates from the chosen CA. This is an act of configuration of the authentication software at the provider site and does not make a record in software at the community site. Typically, the provider must download from the community the root certificate of the CA and must install it locally.

5. Registering users

5.1 Registration in the community

The community operator shall register end users either when they apply personally, or when they are known to have joined the real-world community of which the on-line community is a mirror. E.g., a community operator may create user accounts for all staff joining a department without waiting for the individuals to request membership.

The community operator shall create and record for each user an identity in the form of an IVO identifier (IVOID) according to the rules set out in Annex A of this document. User identities should be registered in the IVO resource registry.

The community operator shall note the user's group memberships in the community's attribute server (see below for details).

The community operator shall assign a password to a user account such that the community's sign-on service accepts the password for logging on to the IVO. The operator shall give the password to the user, but only after the user has proven his or her real-world identity in a way that satisfies the conditions-of-membership provisions of all agreements applying to the community and to the groups of which the user is a member.

Possession of the password allows the user to sign in to the community. Signing in causes the community's CA to sign and issue a short-term identity certificate for the user and give it to the user's software agent. Long-term certificates are not issued to the user at the time of registration.

The conditions under which the password is given out determine whether service providers choose to trust the community, and its sub-groups, and its CAs. It is vital that the community operator does the agreed real-world authentication before giving the password. Typically, the user must go to the operator in person to receive the password.

It is possible to run a community with two levels of registration. Ray Plante [Plante] suggests weak registration for most users, requiring only an email application or the filling in of a web form. In this case, there is no effective real-world authentication. A community that allows weak registration has a weak CA that signs certificates for weakly registered users. Within the community, there may be groups of users who are strongly registered, with stronger real-world authentication required for a user to get the account password. The strongly-registered groups use a separate, strong CA. This bi-level registration may be very convenient. It allows users to register casually in order to use lightly-controlled resources but allows proper registration for access to resources whose providers do not accept weakly-registered users. It is vital to maintain separation between the two levels. It is noted that providers of VOStores will typically require strong registrations [Good].

5.2 Registration in the target services

Services may or may not maintain local accounts for individual users. Many services will work satisfactorily with the group accounts set up in the community-provider agreements. Others, notably VOStore instances, grant different access to individual users.

If a service needs to distinguish individual users, then it shall create an internal account for a new user when an agent acting for that user first makes a valid request to the service. Before considering the request valid, the service shall check that that the user belongs to a group that has an account in the service. The local user-account shall be created automatically without need for intervention by the user, the service provider, or the community operator. The account creation shall not cause variation in the protocol used by the requesting agent; there shall be no extra exchange of messages between the service and the agent concerned with setting up the new account. This is a reasonable strategy when the requesting agent has demonstrated the right to use the group account on the service.

6. Warrants issued by the community

The community shall issue warrants - i.e. digitally-signed tokens - of two kinds.

1. X.509 certificates for authentication.
2. SAML assertions to inform authorization decisions by services outside the community.

These warrants are not alternatives. Most secured requests to services will use both kinds of warrant. The exact usage of the warrants is explained in the separate document on the SSO architecture [SSO architecture].

6.1 X.509 certificates

An X.509 certificate binds an identity, called the "distinguished name" (DN) to a public key by means of a digital signature. To validate the certificate, one needs the public key of the signatory, which is presented in another certificate. To validate that second certificate, one may need the public key of the signatory of the second certificate. This chain of validation proceed until the validating party arrives at a certificate for a signatory who is inherently trusted, called the "trust anchor".

The community shall issue a certificate to any software agent that signs in to the community with a user's SSO password (see the section on registering users for a discussion of this password). The community shall trust such an agent to be acting on behalf of the user and under the user's personal, on-line identity. The community shall create such a certificate at the time of issue, using a public key supplied by the agent, and shall sign the new certificate using either the community's CA or a long-term certificate held on behalf of the user.

The point of creating new certificates at sign-on is to allow the agent signing on to generate its own private key; to avoid the need for a private key to be sent across the network; to avoid the need to store the private key between sessions; and to avoid the need to share a private key between agents. Thus, it is not sufficient for the community to store and return a certificate created when the user registered: the user's software agents would not have access to the matching private key.

Normally, a community should sign certificates using an internal CA. This means:

• the community has a public-private key-pair used for signing certificates;
• the community has a self-signed root certificate by which the CA's public key can be presented to outside parties;
• the community's CA certificate is accepted as a trust anchor by service providers;
• the community's sign-on service has access to both the CA certificate and the CA's private key.

Communities' internal CAs may be federated into a higher-level community. This means that instead of a self-signed root certificate, a community CA has a certificate signed by a CA in the higher-level community. E.g. communities in US universities could federate into the US NVO and use the NVO's root certificate as the trust anchor. This complicates the authentication process slightly but reduces the number of trust anchors that service providers must recognize. [Plante]

Under special circumstances, the community may issue certificates without operating its own CA. The user may have a long-term certificate issued by an external CA, e.g. by a well-known national-level organization such as the UK e-Science programme, or by a well-known commercial CA such as Verisign. Some (but not all) of these certificates allow the bearer to sign subordinate, short-term certificates known as proxies. If the community can acquire and store a certificate of this type and the matching private key, then the community's sign-on service can sign proxies with the user's long-term certificate instead of with the root certificate of a local CA. If the community uses this arrangement, then the community's agreements with service providers shall require that the providers trust the external CA.

When a community issues a certificate to an agent, it must also pass to the agent all the certificates in the chain between the trust anchor and the certificate carrying the agent's key. The agent needs to present this entire chain when authenticating to services.

Certificates issued to agents should have a limited lifetime. One day is a reasonable default lifetime.

The community shall also create, sign and issue a certificate, as above, if an agent authenticates to the sign-on service using a certificate previously issued by the same sign-on service. This can happen in two cases:

• The agent is replacing its time-limited certificate.
• The agent is delegating access to a subordinate agent.

The DN in a certificate issued by a community to an agent need not be the same as the registered identity (IVOID) of the associated user. In the general case it won't be the same, as the DN syntax specified for the X.509 format is mismatched with the IVOID syntax. In the case of a CA external to the community, the names can't be the same as the CA defines the DN and imposes its own naming scheme. If the service needs to recover the IVOID for the user, then it should request it from the community as a SAML assertion about the DN.

Note that more than one agent may use a DN at one time. However, each agent has its own certificate and hence has a unique public key. An alternative is to issue a different DN to each agent. [Saunders]

6.2 SAML assertions

A SAML assertion [SAML] is a SAML statement that has been digitally signed by some authority recognized to make such statements. In the IVO, the communities are the authorities. A SAML attribute statement reports zero or more facts - "attributes" - about the subject identity. Each attribute has a name, a namespace and zero or more values (i.e. attributes are basically array-valued). Attributes are used to aid the receiver in making authorization decisions.

In the IVO, each community shall act as an attribute authority. The community services shall provide SAML assertions for which the subjects are distinguished names in certificates issued by the community to agents. For each such distinguished name, the community shall keep and make available the following attributes:

1. The IVOIDs of the community user-accounts with which the DN is associated.
2. The user groups for which access rights have been delegated to the DN.
3. The user accounts for which access rights have been delegated to the DN.

"Access rights delegated to the DN"  means that the agents operating with certificates containing the DN have been delegated the rights in question.

A SAML assertion applies to a particular subject; in the IVO, this is the DN from the matching X.509 certificate. A service should accept an assertion as applying to a particular agent only if the agent can authenticate the DN using the certificate.

If more than one agent is using a DN, and if the community needs to distinguish between agents, then the attribute assertion can be defined as valid only if the agent authenticates with a specific public key; this ties the assertion to a specific X.509 certificate. This case applies if different sub-sets of access rights are delegated to agents operating with the same DN.

The SAML standard defines a SOAP service that emits assertions containing attribute statements in response to attribute queries. An IVO community shall operate a service conforming to this standard.

7. Shibboleth compatibility

The community system described in this document is intended to be compatible with the Shibboleth SSO system [Shibboleth] of the Internet 2 project. The two systems are not identical - e.g. Shibboleth does not deal with X.509 certificates and the IVO system does not allow anonymity - because they have different aims. However, the two systems can share components.

Both systems use SAML attribute servers. An attribute service set up by a university for Shibboleth may well be sufficient for an IVO community. If it is insufficient, then it can be made sufficient by adding suitable attributes to the database; nothing in the protocol needs to change.

A SAML "origin" installation (SSO services plus attribute services at a community site) could be extended into an IVO community by adding an IVO-compatible SSO service with a CA. This latter service could delegate sign-ons to the SSO service provided for Shibboleth and do the issuing of certificates as an extra feature.

An IVO community constituted as per this document could be extended into a Shibboleth "origin" installation by adding a Shibboleth "Handle service".

In both the above cases, the register of community members, which is the valuable part of the installation, can be used by both the IVO and Shibboleth systems.

References

[e-Science] UK e-Science core programme, Town meeting on Security for e-Science, approaches and interoperability http://www.nesc.ac.uk/events/townmeeting0405/

[Good] John Good, in email thread SSO authentication: a new approach on GWS-WG mail-list http://www.ivoa.net/forum/grid/0503/0290.htm

[Harrison] PaulHarrison, in email thread SSO authentication: a new approach on GWS-WG mail-list http://www.ivoa.net/forum/grid/0503/0284.htm

[Plante] Ray Plante, in email thread SSO authentication: a new approach on GWS-WG mail-list http://www.ivoa.net/forum/grid/0503/0281.htm

[Saunders] Eric Saunders, in email thread SSO authentication: a new approach on GWS-WG mail-list http://www.ivoa.net/forum/grid/0503/0280.htm

[Shibboleth] Internet 2 project, Shibboleth web-site http://shibboleth.internet2.edu/

[SSO architecture] Guy Rixon pp GWS-WG, IVOA SSO profile: architecture (forthcoming)

[SSO introduction] Guy Rixon, IVOA SSO profile: introduction and description of principles http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/SSO-introduction.htm

Annex A:  naming rules for communities, groups and individuals

Communities, groups within communities and users should all be named using IVO identifiers (IVOIDs) and should be registered in the IVO resource registry. Use of IVOIDs makes the names unique within the IVO. Use of the resource registry makes the groupings visible. The registered resources should be of type {http://www.ivoa.net/xml/VOresource/v0.10}Organization in each case.

The community must have a registered Organization resource. For the groups and users, these resources are optional but recommended.

The community operator may choose any valid IVOIDs. However, a hierarchical naming scheme is strongly recommended. The IVOIDs for groups should be based on the IVOID for the community using one of these forms:

(community IVOID)/groups/(group name)
(community IVOID)#groups/(group name)

e.g.

ivo://astrogrid.cam/community/groups/CASU
ivo://astrogrid.cam/community#groups/CASU

The first form applies if the group is a registered resource and the second if it is not.

Similarly, user accounts should be named using on of these forms:

(community IVOID)/users/(user name)
(community IVOID)#users/(user name)

e.g.

ivo://astrogrid.cam/community/users/Mike Irwin
ivo://astrogrid.cam/community#users/Mike Irwin

This convention is to aid human readers. Software should not depend on the details of the naming.