Skip Headers

Oracle9iAS Single Sign-On Administrator's Guide
Release 2 (9.0.2)

Part Number A96115-01
Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Go to previous page Go to next page

6
Mobile Single Sign-On

Oracle iAS users have the option of using mobile, or wireless, devices--specifically personal digital assistants (PDAs) and cellular phones--to gain access to the iAS server. As in PC-based systems, the authentication mechanism is Oracle Single Sign-On. The iAS-wireless option can be selected when Oracle9iAS is installed. If iAS-wireless is selected, Portal-to-Go (PTG), the gateway for mobile devices, is registered with the Single Sign-On server automatically.

This chapter covers the following topics:

iAS-Wireless Concepts and Architecture

Wireless products communicate with iAS using either wireless markup language (WML) or HTML. Cellular phones use the first option, PDAs the second. Because these devices request URLs using Wireless Access Protocol (WAP) and other non-HTTP protocols, hardware gateways must be used to convert messages to HTTP and back again.

The heart of iAS-wireless is PTG. It serves as a browser for interactions between the wireless device and the Single Sign-On server and for interactions between the wireless device and Oracle applications. Actually, the PTG server has a fourfold function:

In the PTG framework, external applications are partner applications that are integrated with the Single Sign-On Software Development Kit (SDK). PTG treats these applications as public applications even if they are not. A PTG instance uses an HTTP adapter to serve as a proxy browser for such applications.

Wireless Single Sign-On

The wireless user has two single sign-on authentication options: she can authenticate directly from the PTG home page, or she can request a partner application, which then performs the authentication.

This section covers the following topics:

Authenticating Through PTG

The wireless user can authenticate from the PTG public page either by requesting a private application or by logging in explicitly to the Single Sign-On server.

The sequence is as follows:

  1. The wireless user accesses PTG by entering a URL of the following form:

    http://host:port/ptg/rm
    

    The PTG public page appears. It displays links for public and private PTG applications.

  2. The user requests a private application or selects the key icon that invokes the Single Sign-On Login page. The portion of this page where the user enters her name is reproduced in Figure 6-1.

  3. The Single Sign-On server looks for the encrypted Single Sign-On cookie. If the cookie is present, the server uses it to identify the user. The server then sends the Single Sign-On redirect form (Step 7). If the cookie is not present, the server sends the mobile XML login form to PTG.

  4. PTG transforms the mobile XML login form to the appropriate markup language and sends the converted form to the device browser.

  5. The user submits the login form with her user name and password.

  6. PTG forwards the login form to the Single Sign-On server.

  7. The Single Sign-On server authenticates the user. If authentication succeeds, the server sends PTG the Single Sign-On redirect form.

  8. PTG sends the user her home page or the requested URL.

Figure 6-1 Wireless Single Sign-On Page: User Name Field

Text description of login.gif follows.

Text description of the illustration login.gif

Authenticating by Requesting a Partner Application

Using the mobile device, the user may also authenticate to the Single Sign-On server by requesting URLs for other partner applications. In this case, the authentication redirection agent is not PTG, but an application integrated with the Single Sign-On SDK.

Figure 6-2 illustrates the authentication sequence:

Figure 6-2 Authenticating by Requesting a Partner Application

Text description of ssoag010.gif follows
Text description of the illustration ssoag010.gif

  1. An unauthenticated user requests a partner application.

  2. PTG sends the request to the partner application, using an HTTP adapter situated on its back end.

  3. If the URL requested is protected, the partner application issues an HTTP redirect to the Single Sign-On server.

  4. PTG follows the redirected URL.

  5. The Single Sign-On server looks for the encrypted Single Sign-On cookie, which is set in the PTG "browser." If the cookie is present, the server uses it to identify the user. The server then sends the Single Sign-On redirect form (Step 9). If the cookie is not present, the server sends the mobile XML login form to PTG.

  6. PTG converts the mobile XML login form to the appropriate markup language and delivers the converted form to the device browser.

  7. The user submits the login form with her user name and password.

  8. PTG passes the login request to the Single Sign-On server.

  9. Upon successful authentication, the Single Sign-On server sends a redirect form that points to the partner application.

  10. PTG follows the redirect form. At this point, PTG, knowing that authentication has been successful, updates the user's session.

  11. The partner application serves up content in mobile XML.

  12. PTG converts the mobile XML content to the appropriate markup language and delivers the converted content to the device browser.

Wireless Single Sign-Off

The Single Sign-off process in wireless is as follows:

  1. The user selects the application logout link.

  2. PTG forwards the request to the Single Sign-On server.

  3. The Single Sign-On server delivers the Single Sign-Off page in mobile XML. Like its PC counterpart, this page contains an image for each of the applications that are active. Unlike its PC counterpart, this page is never seen by the wireless user.

  4. PTG sends an HTTP request to each image link to clean up the user's session in each of the applications.

  5. PTG terminates the user session.

  6. PTG returns the user's home page if the user logged in through PTG. It returns the done_url of the global logout page if the user logged in by requesting a partner application URL.

Change Password Page for iAS-Wireless

The wireless user sees only two Single Sign-On pages: the Login page and the Change Password page. Unlike its PC counterpart, the iAS-wireless Change Password page appears only when users try to log in to the Single Sign-On server and their password has already expired. Wireless users have no access to the Change Password link on the SSO Administration page.

See Also:


Go to previous page Go to next page
Oracle
Copyright © 2002 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index