Single Sign-on

NRAO Interactive Services Modification Request 10C408, August 2008

1. Introduction

We want to have one database and web service against which several applications can authenticate, and through which we can provide single sign-on across NRAO at the application level. This means that a user should be able to log into one NRAO application and move to another one without having to re-authenticate, even if those applications are hosted at different sites. We want to deploy this as a web service so that anyone across the Observatory can use it easily, eliminating the need for rework.

2. Background

To satisfy this MR, there are five systems that must be able to use the service that we presently provide:

  • EVLA Observing Applications (Stephan)
  • PST (Ashish)
  • BOS (Kai)
  • GBT DSS (Mike McCarty)
  • Proprietary VLA/VLBA data in archive (John Benson)

Other applications are anticipated.

StephanWitz investigated technology options to see what would work best from the perspective of the EVLA applications. He identified the Central Authentication Service (CAS), which supports all of the programming languages we need to accommodate at NRAO, and reported that his early work with it was very promising.

Therefore, the purpose of this MR is to develop a CAS web service that uses the user information contained in the user database tables maintained by Open Sky.

3. Requirements

  • User Handling:
    • A user should be able to log in once, and move between applications (e.g. archive, proposals, observing, dynamic scheduling systems) without re-authentication. The goal is to provide a service that any software application at the sites can use to authenticate against.
    • The users should still be managing their profiles through the the same way they do now, if possible. If this can't be done, making sure that they can GET to their profile administration interface the same way is essential.
  • Back End/Administration:
    • The NRAO Computing Security Policy and the NSF require encrypted password storage. Passwords are currently stored unencrypted (base64-encoded). How can we ensure compliance in a standalone authentication system?
    • It should be possible to associate a user with more than one user group.
    • The service administrator must be able to create new groups and associate users with groups readily.
    • Service administrators at each of the sites/telescopes should also be able to create and maintain their own groups.
  • Documentation:
    • We will need documentation to allows developers of future applications to use Single Sign-On.
  • Mirrors:
    • There will be a main repository for user information, supplemented by mirrors. The rationale for a mirror is the requirement that the sites must maintain continuous operations even if network connections to the sites are down.
    • The mirror(s) can provide the authentication services locally, but operations that modify user information will be directed to the master, not to the mirror.
    • Deployment of mirrors will not be part of this MR. However, other development must proceed taking this future requirement in view.
  • Strategic:
    • We need to plan ahead so that we can split the user schema from the proposal schema later in 2009, e.g. so that the database and the CAS service could be installed on a machine and shipped to CV, plugged in and turned on. So that security can be better managed centrally, we want to keep the option open to move this portion of the system to Pat Murphy so he can make future decisions about it.

4. Implementation

The implementation will be conducted in four phases:
  1. Ashish will build a prototype based on CAS
  2. Ashish will write up an interface description here on the Software wiki, intended to quickly help the people in charge of the applications listed above test out the CAS service from their applications
  3. Ashish will generate a diagram indicating how the system is architected. Most likely, it will look the diagram developed for version 1 of CAS at
  4. Stephan, Kai, Mike and John will provide feedback
  5. Then Ashish will retrofit the operational version of the PST to use the CAS service
  6. StephanWitz will generate a test suite of applications to facilitate preliminary testing.

5. Other issues

  • Perforce we will be operating with cross-site/cross-server authentication. We need to keep cross-site security firmly in mind when discussing the implementation. In particular, authentication must be encrypted for transmission across the Internet. PatrickMurphy and StephanWitz will be available for consultation on these issues.

6. Test Plan

6.1 Internal Testing

6.2 Sponsor Testing

6.3 Integration/Regression Tests


APPROVED: I acknowledge that my request is fully contained in this MR, and if the Open Sky (or other NIS or PST developers) deliver exactly what I specified, I will be happy.

ACCEPTED: I acknowledge that I have validated the completed code according to the acceptance tests, and I am happy with the results.

Written ALERT! - GarethHunt - 26 Aug 2008
Checked - - - - -
Approved by Scientific Sponsor - - - - -
Accepted/Delivered by Sponsor - - - - -

  • Use %X% if MR is not complete (will display ALERT!)
  • Use %Y% if MR iscomplete (will display DONE)

Discussion Area

-- GarethHunt - 06 Nov 2008
Topic revision: r3 - 2008-11-05, GarethHunt
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback