Oracle® Application Server Single Sign-On Administrator's Guide 10g (9.0.4) Part Number B10851-01 |
|
OracleAS Single Sign-On provides a framework for integrating deployment-specific login, change password, and single sign-off pages with the single sign-on server. This means that you can tailor these pages to your UI look and feel and globalization requirements, using any suitable Web technology. We recommend, however, that you use JavaServer (JSP) pages. The sample pages provided with the product have been integrated using the same framework.
This chapter contains the following topics:
The process that enables single sign-on pages can be summarized in a few steps:
p_submit_url
(see the table for a description of this parameter). At least two of these parameters, ssousername
and password
, appear on the page as modifiable fields.
The user submits the change password page, entering her old password, new password, and new password confirmation. The page passes the parameters contained in Table 12-4 to p_submit_url
(see the table for a description of this parameter).
If an error occurs, the single sign-on server redirects the user to the change password page and displays an error message. See "Change Password Page Behavior" in Chapter 3 for a detailed discussion of conditions under which errors might occur.
If the password change is successful, the user is redirected to the partner application URL that triggered the authentication request.
The URLs for login, change password, and single sign-off pages must accept the parameters described in the tables that follow if these pages are to function properly.
This section contains the following topics:
The URL for the login page must accept the parameters listed in Table 12-1.
The login page must pass the parameters listed in Table 12-2 to the routine p_submit_url
.
The login page must have at least two fields: a text field with the parameter name ssousername
and a password field with the parameter name password
. The values are submitted to the routine p_submit_url
. The login page must also submit site2pstoretoken
as a hidden parameter.
In addition to submitting these parameters, the login page is responsible for displaying appropriate error messages, as specified by p_error_code
, redirecting to p_cancel_url
if the user clicks Cancel.
You can configure the deployment-specific login page with a link that enables users to reset their passwords. This URL can go either to the home page for Oracle Delegated Administration Services or to the Forgot My Password link within Oracle Delegated Administration Services. Users who click the Forgot My Password link are challenged with a question. They must successfully answer this question before their password is reset.
Oracle Delegated Administration Services is generally available on the same computer as OracleAS Single Sign-On at a URL of the following form:
http://
single_sign_on_host
:single_sign_on_port
/oiddas/
To configure the login page for Forgot My Password, see Chapter 10, "DAS_URL Interface Reference," in Oracle Internet Directory Administrator's Guide.
The URL for the change password page must accept the parameters listed in Table 12-3.
The change password page must pass the parameters listed in Table 12-4 to p_submit_url
.
The change password page must have at least three password fields: p_old_password
, p_new_password
, and p_new_password_confirm
. The page should submit these fields to p_submit_url
.
The page should also submit p_done_url
as a hidden parameter to p_submit_url
. In addition, it should display error messages according to the value of p_error_code
.
The URL for the single sign-off page must accept the parameters listed in Table 12-5.
URLs for login and change password pages must accept the process errors described in the tables that follow if these pages are to function properly.
The login page must process the error codes listed in Table 12-6.
The change password page must process the error codes listed in Table 12-7.
The OracleAS Single Sign-On framework enables you to globalize deployment-specific pages to fit the needs of your deployment. When deciding what language to display the page in, you can adopt different strategies. Two are presented here.
This section explains how to use either the HTTP Accept-Language header or deployment page logic to choose a language to display.
Browsers enable end users to decide the language (locale) they would like to view their web content in. The browser sends the language that the user chooses to the server in the form of the HTTP Accept-Language header. The logic of the deployment-specific page must examine this header and render the page accordingly. When it receives this page, the single sign-on server takes note of the header value for Accept-Language and sends it to partner applications when it propagates the user's identity.
The Accept-Language header is the preferred mechanism for determining the language preference. A major benefit of this approach is that end users have typically already set their language preference while browsing other Web sites. The result is browsing consistency between these pages and single sign-on pages.
Although Oracle recommends the approach introduced in the preceding section, you may choose to implement globalization based on mechanisms that extend or override the language preference set in the browser. You may, for instance, elect to do one of the following:
If you use page logic to set language preferences, the page must propagate this information to the single sign-on server. The server must propagate this information to partner applications. The net result is a consistent globalization experience for the user. Your page must pass the language in ISO-639 format, using the locale
parameter (Table 12-2) in the login form. A number of sites contain a full list of ISO-639 two-letter language codes. Here is one of them:
http://www.ics.uci.edu/pub/ietf/http/related/iso639.txt
Here is a site that contains a full list of ISO-3166 two-letter country codes:
http://www.chemie.fu-berlin.de/diverse/doc/ISO_3166.html
Once it determines the end-user's locale, the deployment-specific page must use the corresponding translation strings to render the page. To learn how to store and retrieve these strings, see Chapter 2, "Developing Locale Awareness," in Oracle Application Server 10g Globalization Guide. You may also want to consult standard documents about Java development. Here are two links:
http://java.sun.com/j2se/1.4.1/docs/guide/intl/index.html
http://java.sun.com/j2se/1.4.1/docs
When implementing deployment-specific pages, observe the following guidelines:
off
. This prevents user credentials from being saved or cached in the browser. Here is an example of the AutoComplete tag:
FORM NAME="foo" AutoComplete="off" METHOD="POST" ACTION="bar"
Use the policy.properties file to install deployment-specific login and change password pages. Use the WWSSO_LS_CONFIGURATION_INFO$ table to install the deployment-specific single sign-off page.
To install your own login and change password pages, edit the following parameters in $ORACLE_HOME/sso/conf/policy.properties:
#Custom login page link loginPageUrl =login_page_URL
#Custom change password page link chgPasswordPageUrl =change_password_page_URL
Finally, restart the single sign-on server. For instructions, see "Stopping and Starting the OC4J_SECURITY Instance" in Chapter 2.
OracleAS Wireless has its own framework for integrating deployment-specific wireless login and change password pages. The procedure for installing these pages is similar to that used to install standard pages (section immediately preceding). First, go to policy.properties at $ORACLE_HOME/sso/conf; then edit (add) the following parameters:
#Wireless login page link wirelessLoginPageUrl =wireless_login_page_url
wirelessChgPasswordPageUrl =change_password_page_URL
Finally, restart the single sign-on server. For instructions, see "Stopping and Starting the OC4J_SECURITY Instance" in Chapter 2.
The WWSSO_LS_CONFIGURATION_INFO$ table in the single sign-on schema contains the LOGIN_URL column. Use this column to enable the single sign-off page.
LOGIN_URL contains three values separated by a space. The first two values are reserved for backward compatibility. Do not edit these values. The third value specifies the single sign-off page. If you are installing your own single sign-off page, you must modify this last value:
sqlplus orasso/password
See Appendix B to learn how to obtain the password for the single sign-on schema.
UPDATE WWSSO_LS_CONFIGURATION_INFO$ SET LOGIN_URL='UNUSED
UNUSED http://server
.domain
[:port
]/single_ signoff.jsp';
UPDATE WWSSO_LS_CONFIGURATION_INFO$ SET LOGIN_URL='UNUSED UNUSED UNUSED';
The ipassample.jar file contains the files login-ex.jsp, password-ex.jsp and signoff-ex.jsp. You may customize these to suit your deployment. If you want to use these files, see "Obtaining the Sample Files" in Chapter 2.
|
![]() Copyright © 1996, 2003 Oracle Corporation. All Rights Reserved. |
|