Identity Management Services

Introduction

Argus is a software system which enables one or more high-security SSL HTTP servers in a domain (entrusted with handling user passwords) to provide reliable client identification for applications running on other authorized SSL HTTP servers within the domain. Argus provides client identification only. Decisions about whether an identified client is authorized to access a given application or resource are the responsibility of the applications.

The Argus login and related pages run in secure mode so any communication between them is encrypted. In addition, steps are taken to ensure that another application or browser cannot usurp the individual's credentials. The web pages that can use Argus are pre-registered and a list is available online.

The Problem

• Many web applications need to identify their clients. Examples:

  • Distribution of copyrighted course materials, licensed software or databases, sensitive records.

  • Courseware

  • Departmental work orders

• Application specific password databases are a nuisance for users (how many passwords can you remember?), or a security risk if users make their application passwords the same as more powerful passwords (i.e. campus Online ID).

• Certificate based authentication is not mature on the browsers most people use.

• Authentication mediated by a departmental HTTP server means the server must handle user passwords in the clear. For security reasons, we don't want these popping up all over campus, though for performance reasons we do permit a few, e.g. online grades and fee payment.

The Argus Solution

• A high-security server on campus operated by ACS to provide reliable client identification to other authorized web servers.

• Uses popular, off-the-shelf components:

  • Netscape and Microsoft browser clients.

  • Apache HTTP Servers

  • Perl 5 and/or Tomcat 4 or 5

• A simple user interface: screens for Online ID and password with important "consciousness-raising" security information.

• A simple Application Program Interface (API) for Application Servers:

  Perl CGI (KuPortal):
  

  use KuPortal; $user_info = KuPortal::user_status(-application => $appname, -timeout => $timeout, -asref => 1); if ($user_info->get_value('kuPersonDepartmentNumber') ne '1234000') { print_unauthorized_page(); }

• A simple Servlet Filter for Java-based Application Servers:

  Java Servlet Filter (ArgusFilter)

  ArgusFilter returns user attributes via the HTTPServletRequest in the getHeader and getRemoteUser methods.

Argus Components

• Login Servers: high-security systems with a supported SSL HTTP server, certificate, and the Argus authentication server software installed:

  • logincgi - provides client login screens and authentication

  • loginserver - an SSL daemon for secure communication between the login server and authorized Argus applications.

• Argus Applications - authorized web pages or systems with a supported SSL HTTP Server, certificate, the Argus API, and applications requiring client identification.

• Client Browsers - web browsers supporting SSL and Persistent Client State HTTP Cookies. Currently this includes Netscape (version 1 and later) on Windows, Mac and Unix platforms, and Microsoft Internet Explorer (version 3 and later) on Windows and Macintosh. Many other browsers also support these cookies.

Argus Online IDs

Development of Argus began with the desire to authenticate users to web based applications. There were two candidates for the Online ID: Exchange username and People Search alias. Each had its own password. Because there was no tradition of people knowing or using their alias passwords, as they were created along with their email accounts, the Exchange username became the Online ID. This was later expanded to NT domain logins with no Exchange mailbox to include people at our KUMC campus, who were not part of our Exchange mail system. It has since migrated into an iPlanet LDAP server, freeing us from Active Directory.

As more applications used Argus to authenticate, we migrated Argus to an initial sign on system, which requires a user to authenticate the first time they visit an Argus authorized application. Any visits to other Argus authorized applications use the original authentication. This will also enable us to incorporate various Internet 2 middleware initiatives, such as Shibboleth.

Acknowledgements

The Argus authentication system was heavily influenced by the Bluestem project at UIUC. Our requirements were simpler in that we don't yet support multiple authentication schemes, but are more complex in that we have multiple non-cooperative users sharing our main campus web servers and so need fine control at the server path level, which Bluestem does not.

The Argus authentication system was primarily developed and written at Academic Computing Services, a unit which no longer exists, by Kathryn Huxtable, with much advice and comment from Wes Hubert, Aaron Brown, and Sarah Kanning.