NVO SSO

From MyWiki

Contents 1 Overview 2 User Experience 2.1 Familiar Web Registration 2.2 Registration Authorities 3 Architecture 3.1 Application Servers 3.2 Login Servers 3.3 Client Applications 3.4 Service Providers 3.5 Architecture Documents 4 Installation 4.1 Release Process 5 Maintenance 5.1 Annual Key Renewal 5.2 Adding an Application Server

Overview

We are developing single-signon for the U.S. National Virtual Observatory (NVO), for use by web portals and desktop applications. The project leader is Ray Plante. We use Pubcookie for web SSO, MyProxy for X.509 credential management, and PURSe for user account management.

A demo is currently online. To access the demo server, sso.us-vo.org, directly (for example via myproxy-logon), first download the CA keys. Also, unless you use a specially patched version of Pubcookie, to interoperate with the demo you will need to use this Pubcookie symmetric key that is identical to the one used by the demo application servers.

User Experience

To users, NVO's SSO login system looks like a regular web security system, while still providing application developers tools for integration with grid services.

Familiar Web Registration

1. A user registers, providing at least an email address, choosing a unique username, and establishing a password.
2. The user receives an email from the NVO login system that includes an activation link (plus option to cut and paste value).
3. The user clicks the activation link in the email.
4. The user can now log in to any

Registration Authorities

In the future, we intend to add these steps to the registration process:

• After activation, the user's information may be sent to a Registration Authority (RA), in order to confirm their identity.
  • The RA would be expected to independently confirm the user's identity, based on registration information such as email address or telephone number.
  • Once confirmed, any certificates issued for the user would include a [SAML] element identifying the user's relationship with the RA.

Architecture

NVO SSO has three components:

• Application servers, which should be easy for researchers to set up and manage, and which trust the login servers, but are not required to be deeply trustworthy themselves.
• Login servers, which authenticate users. There will be very few login servers, and they will be carefully secured.
• Client applications, which would run on scientists' own machines, typically with a single user.

A fourth component sits behind the scenes:

• Service providers to which applications can authenticate using GSI credentials.

Application Servers

Application servers, we expect, will constitute the primary interface between end-users and service providers. They participate in SSO and provide a familiar front-end while handling Grid security behind the scenes.

• User interface: HTML / web
• Back end: GSI or custom interface to services

Our goal is to enable broad development and experimentation with application servers. As a result, we have tried to make them easy to set up and, at the same time, minimize the risk from security compromises.

• Easy to set up
  • Readily-available software (Apache, Tomcat, Gridsphere, etc.)
  • Standard protocols and interfaces (Servlets, Web Services, GSI)
• Minimal security risk
  • App servers never see passwords (only the login server does)
  • Security credentials stored on app servers are short-lived
  • Back-end servers need not trust app servers themselves; they can establish a trust relationship directly with the login server

Login Servers

Regional organizations will maintain highly secure login servers. There should be as few of these servers as possible, in order to keep things manageable. For example, the U. S. NVO will maintain a single login server, perhaps to be shared with organizations in North and South America. We expect that there will be a login server in Europe and one in Asia as well.

Application servers can be configured to trust multiple login servers.

A login server's tasks are:

1. Manage user accounts
2. Verify passwords, without disclosing them to application servers or client applications
3. Provide cryptographic security credentials for accessing remote services
4. Federate with other login servers

Client Applications

In addition to web interfaces that hide the details of the grid security infrastructure (GSI), the NVO SSO approach allows desktop applications to function normally, retrieving credentials from the same MyProxy server, using the same username and password. In fact, single sign-on is possible, in principle, initiated by Web SSO, using secure tokens encoded in an application launching protocol such as Java Web Start, as done by GridShib CA.

Service Providers

Anything that accepts GSI credentials for authentication. Can use confirmation from Registration Authorities for authorization.

Architecture Documents

• Proposed security architecture (PDF) for LSST, DES, etc., using Pubcookie and MyProxy for behind-the-scenes GSI.
• Security architecture diagram (Visio).
• NVO registration sequence (Visio, PDF).

Installation

We offer two routes to installation:

1. From scratch: directions for setting up SSO login servers and applications.
2. From virtual machine images: VMWare images that have all of the necessary software installed, and only require final configuration for your site.

Release Process

VMWare images are available for download, after standard pre-release treatment.

Maintenance

Annual Key Renewal

Host certificates, by default, expire after one year. To update them:

1. Create new host certificates
2. Update host certificates
   • /etc/grid-security/hostcert.pem and /etc/grid-security/hostkey.pem
3. When you update the login server's key, you have to take extra steps:
   • The login server keeps an extra copy of its private key at /etc/grid-security/pubcookie_hostkey.pem, owned by apache instead of root.
   • Each application server keeps a copy of the login server's hostcert.pem in /usr/local/pubcookie/keys/, but named by the login server's hostname (for example, sso.us-vo.org) instead of hostcert.pem

Adding an Application Server

[Quick notes by Bill -- should flesh these out the next time we have to do this.]

• Create host certificates, and install on the application server and login server
• Get the shared symmetric key copied to the client
  1. On login server, copy /usr/local/pubcookie/keys/common.key to the new app server's name
  2. On login server, execute /usr/local/pubcookie/keyclient -P <app-server>
  3. On app server, execute /usr/local/pubcookie/keyclient -d. The -d is important; it means "Download existing key; don't generate new" -- that is, get the key that you just copied from common.key.