NVO Login Server Federation

From MyWiki

Contents 1 Definitions 2 Design Objectives 2.1 Functional Requirements 2.2 Engineering Goals 3 Cooperating Login Servers 3.1 Design 3.1.1 Native Login Server 3.1.1.1 Initial Login Sequence 3.1.1.2 Subsequent Login Sequence 3.1.2 Non-Native Login Server 3.1.2.1 Initial Login Sequence 3.1.2.2 Subsequent Login Sequence 3.1.3 Open questions 3.2 Implementation 3.3 Problems 4 Shibboleth

Definitions

login server

includes a Pubcookie authentication server and MyProxy server, working together

native login server

the login server that a user originally registered with, and which houses their account information and which is responsible for issuing their security credentials

portal

application server that relies on login servers for authentication and security credentials

resource provider (RP)

back-end resource or service, used by portals, that accepts security credentials for authentication and may re-delegate them to other resource providers in order to perform tasks for the user

Design Objectives

Functional Requirements

• Allow users to log in through any portal (application server), regardless of their native login server
• Preserve security of login servers
• Use GSI credentials issued by a user's native login server

Engineering Goals

• Minimize modifications to Pubcookie
• Minimize complexity of deploying and managing a portal

Cooperating Login Servers

In this design, the login servers cooperate with each other, but they don't require portals to know about more than one login server. That is, concentrate all the complexity in the login servers and their interactions. The reasoning is "portal early and portal often" — make it easy to set up and administer a portal, while allowing freedom to make changes to login servers without disrupting existing portals. After all, portals are the most valuable piece of this, and their administrators are the least interested in security complexities. We want things to just work for them.

• Portals are only aware of a single login server use; they use straightforward mod_pubcookie and mod_myproxy installations
• Login servers all cooperate to provide authentication and credentials
• Users are required to remember their native login server and select it when they log in

Design

There are two main sequences in this design scenario, and which one to use hinges on whether a portal is configured to use a user's native login server or some other login server.

Native Login Server

The simplest scenario is that a user accesses a portal that is configured to use their native login server.

Initial Login Sequence

If the user is not already logged in via another portal:

1. User requests protected page
2. Browser is redirected to login server
3. No Pubcookie session cookie is found, so login server presents login form to user
4. User selects native login server, which is probably already the default
5. User enters username and password
6. Login server submits username and password to the MyProxy server
7. MyProxy checks username and password against PURSe database
8. Login server sends Pubcookie granting cookie to portal server, via browser HTTP request
9. Portal uses granting cookie to:
   • create Pubcookie session cookie
   • request security credential from login server
     1. Portal sends username and granting cookie to MyProxy server
     2. MyProxy server checks signature and expiration time on granting cookie
     3. MyProxy server issues, to portal, a security credential for the user
10. Portal trusts user's identity and uses credential to access service providers

Subsequent Login Sequence

Once the user has logged into one portal, requests to another portal operate via SSO:

1. User requests protected page
2. Browser is redirected to login server
3. A Pubcookie session cookie is found
4. Login server sends Pubcookie granting cookie to portal server, via browser HTTP request, as above ...

Non-Native Login Server

Things get more complicated when a user accesses a portal that is configured to use a login server other than their native login server. We still want the portal configuration and user experience to be straightforward, so we load the complexity into the login servers:

Initial Login Sequence

If the user is not already logged in to this particular login server (changes from native sequence are in bold):

1. User requests protected page
2. Browser is redirected to login server
3. No Pubcookie session cookie is found, so login server presents login form to user
4. User selects native login server
5. User enters username and password
6. Local login server submits username and password to the native MyProxy server
7. Native MyProxy checks username and password against PURSe database
8. Login server sends Pubcookie granting cookie to portal server, via browser HTTP request
9. Portal uses granting cookie to:
   • create Pubcookie session cookie
   • request security credential from login server
     1. Portal sends username and granting cookie to local MyProxy server
     2. Local MyProxy server extracts name of native login server from username/cookie
     3. Local MyProxy server submits username and cookie to native MyProxy server
     4. Native MyProxy server checks signature and expiration time on granting cookie (cookie is signed by the local login server, which requires that each MyProxy server have a copy of each login server's public key)
     5. Native MyProxy server issues, to local MyProxy server, a security credential for the user
     6. Local MyProxy server delegates credential to portal
10. Portal trusts user's identity and uses credential to access service providers

Subsequent Login Sequence

Subsequent logins to other portals in the same domain (that is, that use the same login server) will be single-sign on. The user will not be asked to re-enter their information, but the login servers will still need to cooperate behind the scenes to establish identity and obtain credentials, just as with the initial login.

Open questions

• How does a login server know, on login requests from subsequent portals (that is, for SSO), which is a user's native login server? How does the local MyProxy server know which is the native login server?
  • We could put the name of the native login server into the granting cookie
  • We could suffix the username with the name of the native MyProxy server (for example, vwelch@myproxy.ncsa.uiuc.edu)

Implementation

This design requires changes in only a few places:

• Pubcookie authentication server
  • Verifier script: ability to contact remote MyProxy server
• MyProxy server
  • Option to source credentials from remote MyProxy server rather than locally
  • Trust multiple Pubcookie login servers (multiple public keys)
  • Know to strip off @<myproxy-server> from end of usernames
• Mod_Myproxy Apache Perl module
  • Instead of static MyProxy server, choose based on decorated user name

Problems

• Users will be directed to login servers that they have not seen before

Shibboleth

How would Shibboleth work? What if we switched to it? It includes federated identity services as a fundamental property of its design.

• Can't use it by itself, with GridShib CA, because that gets certificates to users' desktops rather than to an application server.