Previous     Contents     Index          Next     
iPlanet Calendar Server 5.0 Programmer's Reference



Chapter 8   Single Sign-on Authentication


This chapter describes the Single Sign-on authentication mechanism included in iPlanet Calendar Server 5.0. This scheme is independent from any other authentication mechanisms, session management, and resource access control. To use it, your client must support cookies and your server must support HTTP. Single Sign-on does not impact application performance. This scheme does not require a centralized session manager. Applications manage their own sessions and may have different timeout and revocation policies.

This chapter has the following topics:



What is Single Sign-on?

Single Sign-on allows a user to sign on once and use multiple applications. These applications form a circle of trust that use each other's cookies as verification of authority so that the user does not have to sign on to each application separately.

Each application can have its own verification interface, if necessary. However, each verification authority must store a cookie that is understood by the other applications' verification authority routines. See Cookie Information" later in this chapter.



Limitations of Single Sign-on


Despite the benefits listed earlier, there are some limitations that might deter you from using Single Sign-on:

  • Applications need to implement the verification protocol. See "Issues" later in this chapter.

  • This scheme is not suitable for shared machine situations.

  • Applications need to be in the same domain and have access to each other's Single Sign-on verification URL.

  • The browser must be restarted for the user to switch to a different identity.

    This is necessary because each browser session can support only one user ID.

  • The client must support cookies.



Process Flow

As diagrammed in the figure that follows, the flow starts with an application receiving access requests. Since a circle of trusted applications share the same prefix, the program fetches all cookies with the matching prefix.

If the application does not find one of its own cookies, it checks to see if there are cookies available from any of the other trusted applications. Once it finds a valid cookie, the program uses the information from these cookies to verify authority and establish a session. When granting access, it sends back its own application specific cookie.

If there are no cookies available with this circle's prefix, or the available cookies are invalid, the program displays a login screen to the user.

Figure 8-1 illustrates Single Sign-on process flow.

Figure 8-1    Single Sign-on Process Flow



Implementation Requirements


In order to participate in this single sign-on scheme, all applications in the circle need to:

  • Be able to read and write cookies.

  • Support additional configuration parameters:

    • List of trusted applications.

    • Single Sign-off.

    • Prefix string.

  • Implement the Single Sign-on verification protocol over HTTP.

    • Request:

      The request contains the Single Sign-on cookie in the header and has the client IP address as a parameter of the URL:

      GET verificationurl client=clientIPHTTP/1.0

    • Response when key is valid:

      A text/plain ASCII response with each key-value pair taking a separate line. timeremaining is optional.

      fquid=user id@fully qualified domain name
      authtype=plaintext | cert | ...
      timeremaining=[time left before this session time out]

    • Response when key is not valid:

      A text/plain ASCII message: Error: user does not have a valid session.

  • Edit the configuration file, ics.conf, to set the configuration data for your trusted circle. See the "iPlanet Calendar Server Administration Guide" for details on the configuration file. Single Sign-on configuration parameters start with the prefix sso.


Cookie Information

The cookie format is as follows:

configurable prefix-application installation unique identifier=single sign-on key


Other recommended settings:

  • Domain set to .domain name.

  • Path set to /.

  • Expires field not set.


Trusted Applications Record

While the storage and format of additional configuration parameters are application specific, each record should contain:

  • A unique identifier for this particular trusted application installation.

  • A fully qualified domain name or IP address of the machine hosting the application.

  • A URL that supports the Single Sign-on verification protocol.

    Example: http://domain.com/VerifySSO?


Single Sign-off Parameter

The single sign-off parameter is a boolean indicating whether this application performs single sign-off. The default should be true.

  • If true, the application removes all single sign-on cookies matching the trusted circle prefix when the user logs off.

  • If false, the application removes only its own single sign-on cookie when the user logs off.


Prefix String

This is the common string shared by all applications in the trust circle. You can form multiple circles of trust within a domain by choosing separate prefixes.



Single Sign-on Example


This example illustrates the steps involved in completing a single sign-on cycle.


The Example

The participating applications use ssogrp1 as the prefix for this circle of trust. Trusted applications in this circle are: WebMail, WebCal, and HRapp.

  1. John checks his mail.

    WebMail receives the login request from jsmith running on 208.12.60.3. WebMail looks for cookies that have ssogrp1 as part of their name. There is no such cookie. WebMail prompts the user to authenticate and then sends back a cookie with the prefix string, ikey-, plus this WebMail installation's unique identifier (3fr7d), and the single sign-on key (l3khj5l3k9ldh), which happens to be the session ID.

    The cookie returned is: ssogrp13fr7d=l3khj5l3k9ldh.

  2. John then checks his calendar.

    • WebCal receives the login request from jsmith running on 208.12.60.3. The only ssogrp1* cookie WebCal found was ssogrp13fr7d=l3khj5l3k9ldh. WebCal retrieves the following entries in its config file:

      3fr7d.verificationurl=http://webmail host/VerifySSO?

    • WebCal issues HTTP GET:

      GET http://webmail host/VerifySSO?client=208.12.60.3 HTTP/1.0

      Cookie: ssogrp13fr7d=l3khj5l3k9ldh

    • WebMail verifies this is a valid key and returns:

      fquid=jsmith@example.com
      authtype=plaintext
      timeremaining=1000

    • WebCal generates a single sign-on key, a97ads64, for John and sends back the cookie:ssogrp1lkj87f=a97ads64.

  3. John surfs the net for a while and then wants to check his calendar again.

    • WebCal receives log in request from jsmith running on 208.12.60.3.

    • WebCal found several ssogrp1 cookies. One of them matches WebCal's unique application ID (lkj87f).

      It sends back the cookie: ssogrp1lkj87f=a97ads64.

    • Since WebCal uses session ID as the single sign-on key, it retrieves session a97ads64 from its session database, verifies that the session is still valid and then allows the user to proceed.

  4. John needs to access his company's HR application which requires certificate authentication.

    The HR application was developed in-house and was modified to support the verification protocol.

    • HRapp receives the login request from jsmith running on 208.12.60.3.

      Since it requires certificate authentication, it asks the client to send the certificate.

    • HRapp does not check for the ssogrp1* cookies.

    • HRapp generates a session B53P997KD for John and sends back a cookie: ssogrp1adf38=lka79jy5d3l3r.

      This cookie will allow other participating applications to use HRapp as a verification authority.

  5. John checks his mail again and decides to log off.

    • WebMail receives the logoff request from jsmith running on 208.12.60.3.

    • In addition to invalidating John's WebMail session, it also removes all ssogrp1* cookies.

  6. Now if John wants to access any of the applications again, he will need to log in again.


Configuration Parameters for the Example

  • Prefix: sso.appprefix="ssogrp1"

  • Single sign-off boolean: sso.singlesignoff="true"

  • Application information:

    • WebMail:

      appid=3fr7d

      3fr7d.ip=198.93.96.111

      3fr7d.verificationurl=http://webmail host/VerifySSO?

    • WebCal:

      lkj87f.ip=198.93.78.103

      lkj87f.verificationurl=http://webcal host/VerifySSO?

    • HRapp:

      adf38.ip=198.93.70.8

      adf38.verificationurl=http://hr host/VerifySSO?



Issues

The section discusses the issues, assumptions, and requirements for four areas:


Security

  • The assumption is that it is sufficiently difficult to guess the correct combination of single sign-on key and client IP address, so it's not necessary to require authentication for the verification protocol.

  • If the client connections come from a proxy then the single sign-on key is the only defense. So it is extremely important that the key is very difficult to predict.

  • It's the application's responsibility to generate secure single sign-on keys.

  • It's also helpful to configure the application to have shorter session timeout so each single sign-on key does not stay valid for a long time.

  • HTTPs could be used to protect the communications. If an application requires client certificate authentication then it should always request the certificate from the client. However, it can still act as a verification authority for others.


Management

  • Every application must maintain the trusted application list. Each application could, potentially, be using a different mechanism to store and manage that list.

  • Only the application that generated it can revoke a single sign-on key. Administrators can not easily turn off a user's access to all applications.


Scalability

Cookie number limitations:

  • 300 total cookies

  • 20 cookies per server or domain. Completely specified hosts and domains count as separate entities, and each has a 20 cookie limitation.


Performance

  • The verification request to other applications only happens once. Once an application session is established, the verification protocol is no longer involved.

  • If the browser contains many stale cookies (cookies with an invalid single sign-on key), then logging into a new application may take a long time.

    This should not happen very often for two reasons:

    • Each application should remove its own cookie when users log out. (If the application performs single sign-off, then it removes all single sign-on cookies that have the applicable prefix.)

    • Applications should leave the expires field blank so the cookie is not persistent across browser sessions.


Previous     Contents     Index          Next     
Copyright © 2000 Sun Microsystems, Inc. Some preexisting portions Copyright © 2000 Netscape Communications Corp. All rights reserved.

Last Updated February 20, 2001