| Oracle® Access Manager Access Administration Guide 10g (10.1.4.0.1) Part Number B25990-01 |
|
|
View PDF |
| Oracle® Access Manager Access Administration Guide 10g (10.1.4.0.1) Part Number B25990-01 |
|
|
View PDF |
Authentication involves determining what authentication method is required for a resource, gathering credentials over HTTP, and returning an HTTP response that is based on the results of credential validation.
Form-based authentication enables you to create customized Web forms that process user logins using the Access System's authentication and authorization mechanisms. These forms are HTML pages that allow you to present login information in different languages, to display user interface elements that comply with your company's presentation standards, and to add functions to the login page: for example, for lost password management.
This chapter covers the following topics:
The Access System challenges the user with a form that was configured in an authentication scheme under the following conditions:
If a Web resource is protected using a policy with an authentication scheme that requires a form and there is no valid session cookie (ObSSOCookie).
If the valid session cookie exists, but it is from a lower authentication level (regardless of the challenge method).
The authentication challenge is an HTML form with one or more text input fields for user credentials. In a typical form-based authentication, text boxes are provided for the user name and password. Users enter their credentials in these fields. The most common credential choices are user name and password, but any user attributes can be used, for example, user name, password, and domain. A Submit button posts the content of the form. When the user clicks the Submit button, the form data is posted to the Web server. WebGate intercepts and processes the form data. Upon validation of the user credentials collected in the form, the user is authenticated.
You may want to use form-based authentication for reasons such as the following:
Using form-based login and a standardized logout (see "Configuring Logout" for details) means that the user experience for login and logout features will be consistent across browsers.
You can apply your organization's look and feel in the authentication process.
For example, a custom form can include a company logo and a welcome message instead of the standard user name and password window used in Basic authentication.
You can gather additional information at the time of login.
You can provide additional functionality with the login procedure, such as a link to a page for lost password management.
See the information on lost password management in Oracle Access Manager Identity and Common Administration Guide for details.
|
Note: The forms that you create for form-based authentication only collects user credentials. Authentication and authorization are handled by other functions. See Chapter 4, "Protecting Resources with Policy Domains" for details. |
The following is a summary of configuring form-based authentication. For more details on this process, see "Configuring Form-Based Authentication".
Task overview: Configuring form-based authentication
Create an HTML form where the user's credentials, such as user name and password, can be submitted, using information in "Considerations when Creating a Form".
Place the form in an unprotected directory, or in a directory protected by an Anonymous authentication scheme, on your Web server with a WebGate.
The same login form and its associated authentication scheme can be used by multiple policy domains.
Set up an authentication scheme to use form-based authentication and define the path to the login form.
See "Considerations when Creating a Form" for details.
Call the form action using HTTP GET or POST.
See "About the Form Action" for details.
Protect the target URL in the action of the login form with a policy.
See Chapter 5, "Configuring User Authentication" for details.
Configure the challenge parameters and passthrough mode in the authentication scheme.
See Challenge Parameters for details.
Specify the plug-ins.
See "Plug-Ins Used with Form-Based Authentication" for details.
The rest of this section discusses the following topics:
When you select the Form challenge method, you are required to provide the following three parameters in the Challenge Parameter fields.
|
Note: During form-based authentication with a custom plug-in, the original resource name is not available to the plug-in in the pre-defined names in the Challenge Parameter creds list. For example, in the Authentication Plug-in API the ObAnPluginInfo struct contains the Creds data type where the Access Server provides four pre-defined names within this list: Resource, Operation, RequesterDN, and RequesterIP.When using form-based authentication, the Resource returned by the API is the resource that the login form POSTs to (not the actual resource of the original URL). |
A fourth parameter, passthrough, is optional.
Enter passthrough:yes if you want to pass the login credentials to a post-processing system. For example, you enter passthrough:yes if you want to pass the login credentials through to a post-processing program for SSO to another application that does not accept header variables.
If you accept the default passthrough mode but want to redirect users to a page other than the originally requested resource, in the policy domain rule specify a redirection to another page upon authentication success. If redirection to the login form occurs as described in "Redirection", and passthrough mode is not set for the form authentication scheme, WebGate redirects the browser back to the originally requested resource. You can use the ObRequestedUrl header variable to redirect.
If the login form is the page that user requests, redirection is not needed. However, users can attempt to go around a login form, for example, by bookmarking pages. In these cases, WebGate redirects the request to the login form. After authentication success, WebGate redirects the user back to the requested resource.
A cookie named obFormLoginCookie maintains the original request information. By default, this cookie is set when the browser is first redirected to the form. Information in this cookie includes:
The requested URL
The requested operation
An authentication scheme
The URL of the host to return to
Without this cookie, WebGate would be unable to send the originally requested resource upon authentication.
When the user authenticates, the ObSSOCookie is also set. For more information on the ObSSOCookie, see "Single Sign-On Cookies".
You need several plug-ins to work with your form authentication scheme. The order of the plug-ins is also important.
Credential Mapping Authentication Plug-In
Credential mapping is defined for each login form. The credential_mapping plug-in performs the task of mapping the user-supplied credentials to a unique DN in the directory server. WebGate searches the directory for profiles with attributes matching the form credentials. It handles the password credential consistently with basic authentication.
Logically, password validation can only happen after the user is identified. Therefore, the credential_mapping plug-in needs to be used before validate_password and must be the first plug-in specified in your form-based authentication scheme.
Validate Password Authentication Plug-Ins
Form authentication uses the same validate_password plug-in that is used in basic authentication. You can configure the name of the password field.
More Possible Custom Authentication Plug-Ins
As with basic authentication, custom authentication plug-ins can be used to check the user name and password using other login services and user repositories. In fact, the same processing functions could be used for both basic and form user name/password authentication. Custom authentication plug-ins can also process other user credential data.
|
Note: During form based authentication with a custom plug-in, the original resource name is not available to the plug-in in the pre-defined names within the Challenge Parameter creds list. For example, in the Authentication Plug-in API the ObAnPluginInfo struct contains the Creds data type where the Access Server provides four pre-defined names within this list: Resource, Operation, RequesterDN, and RequesterIP.When using form-based authentication, the Resource returned by the API is the resource that the login form POSTs to (not the actual resource of the original URL). |
For more information about plug-ins, see "Configuring a Form-Based Authentication Scheme".
If WebGate intercepts the form login, it can build the session cookie and carry out the authentication actions.
|
Note: If a form authentication scheme on IIS is configured with the passthrough option, and the target of the login form requires the data posted by the form, the WebGate extension method (where the WebGate DLL is the action of the form) cannot be used. The WebGate filter method (where the action of the form is a protected URL that is not the WebGate DLL) must be used instead, and the postgate DLL must be installed and enabled. See the Oracle Access Manager Installation Guide for details. |
Form-based authentication schemes can pass authorization actions in header variables. However, they cannot pass authentication actions in header variables.
An authentication scheme can collect context-specific information before submitting the request to the Access Server. Context-specific information can be in the form of an external call for information. This information can be of the following types:
server: variables set by other Web server plug-ins
header: HTTP header variables
post: posted data
query: query string data
cookie: HTTP cookie
To retrieve external data for an authentication request
Create an authentication scheme as described in "Defining a New Authentication Scheme".
In the Challenge Parameter field, specify the following:
creds:source$name
or
creds:name
where source is one of the following:
server
header
post
query
cookie
If you omit the source, sources are searched in the order shown in the list.
|
Note: The Web server source (the server parameter) takes precedence over other sources. This prevents the request data, which is under control of the user, from overriding Web server data. For example, a remote_user cookie sent from a user will not override a remote_user variable set by the Web server. |
If the client is a WebGate, as opposed to the Access Manager SDK, the WebGate will extract the requested data. If the client is the Access Manager SDK, it is up to the calling program to collect this data.
For a plug-in to make use of the creds parameter, you specify what is passed in the obMap credentials parameter of the ObUserSession object. See the Oracle Access Manager Developer Guide for details.
You need to create a custom form that you want users to see when they access a protected resource. The form can be as complex as you want it to be. Within the form, you must at least provide fields for a user to submit a login and password.
Key areas to consider when you are designing a form are:
The ObFormLoginCookie as described in "ObFormLoginCookie".
Form actions, as described in "About the Form Action".
Form actions and WebGate.dll, as described in "Notes for Microsoft IIS".
Character set encoding for the login form must be set to UTF-8, as shown and described in "Sample Login Form".
As previously mentioned, WebGate sets the ObFormLoginCookie when the browser is first redirected to the form. This can become a problem in the following situations:
If your login form has a link for Password Management that is protected by an Anonymous authentication scheme, the user is redirected back to the login form instead of going to the lost password link.
After the login has been completed, WebGate marks the ObFormLogin Cookie "done" and will not allow the user to use the form login again within the same browser instance. This causes a problem for the oblogout functionality. When a user tries to log out, and then log back in, WebGate bypasses the form login processing.
You can avoid these situations by entering an action challenge parameter when you configure your form authentication scheme. See "Protecting Resources with Policy Domains" for details.
The following procedures describe how to configure a form and an authentication scheme for the form.
Task overview: Creating a form for authentication
Create a custom form that you want users to see when accessing a protected resource, using considerations described in "Considerations when Creating a Form".
|
Note: Do not protect the form or any of its components (such as GIFs and links) with an authentication method, or use an Anonymous authentication scheme. |
Place the form in an unprotected directory, or in a directory protected by an Anonymous authentication scheme, on your Web server with WebGate.
The same login form and its associated authentication scheme can be used by multiple policy domains.
Configure a form-based authentication scheme, as described in "Configuring Form-Based Authentication".
The rest of this section discusses the following topics:
When you create an authentication scheme you include the name, an optional description, and the level of the authentication scheme. Parameters and options are described within the following procedure. For more information about authentication schemes, see Chapter 5, "Configuring User Authentication".
|
Note: When a form resides on the same server as a WebGate, the relative form URL given for the form in the authentication scheme is on the same machine as WebGate. As a result, you do not include the https:// (or http://) host:port portion of the URL in the authentication scheme. However, when the form resides on a remote server, the host and port are required in the authentication scheme. |
To configure a form-based authentication scheme
In the Access System Console, click Access System Configuration, select Authentication Management, then click Add.
The Define a New Authentication scheme screen appears.
Enter the following for the authentication scheme:
A name.
A description.
The level of the authentication scheme: The level of the scheme is a number that corresponds to the relative security level for this scheme. Higher levels are considered more secure.
Select Form as the Challenge Method, as described in "About Challenge Methods".
In the Challenge Parameter field, enter the following:
form:relative_form_URL creds:credential_names action:Action_URL passthrough:[yes] (Optional)
The Access System assumes the relative form URL given for the form in the authentication scheme is on the same machine as WebGate.
Do not include the http://server host:port portion of the URL if the authentication scheme is on the same machine as the WebGate.
For example:
form:/login.html
Credential names are a space-separated list of expected credential names from the form.
For example:
creds:login password
The Action URL sets the ObFormLoginCookie to be returned only when the form posts the login credentials.
For example:
action:/access/dummy.cgi
For more information, see "About the Form Action".
The default passthrough mode is no. Accept the default if you want the Access System to automatically redirect users to their original requested resource.
Specify whether or not you want the user to authenticate using SSL.
You can also use Challenge Redirect to redirect the users to a central location storing all forms.
If you answered yes to SSL, specify the Challenge Redirect URL for your secure server.
Enter the following two required plug-ins:
| Order | Plug-in Name | Plug-in Parameters |
|---|---|---|
| 1 | credential_mapping | obMappingBase="o=company,c=us" ( the base DN in the LDAP search). obMappingFilter="[(Identity Login Attribute=%form input field for login%)]" |
| 2 | validate_password | ObCredentialPassword="[form input field for password]" |
|
WARNING: The directory login attribute is an attribute defined in the Identity System using a semantic login type, as discussed in the Oracle Access Manager Identity and Common Administration Guide. Also, you cannot have spaces in the filter. The Policy Manager does not validate the string that you provide as the credential_mapping filter, so it is possible to enter an erroneous filter. No error occurs while saving; however, the filter will fail and the plug-in will return "Authentication Failed" each time it is run. |
For information about users and the obMappingFilter, see "Including Users in the obMappingFilter".
Click Save.
The form action does not process the credentials for authentication. This is the job of the Access System plug-ins that you configure for the form-based authentication scheme. In the form element of a login form, the action attribute is a URL to which form data is posted when the user submits the form.
For example, in the following form the action URL is /access/dummy and the method is post:
<html> <head> <meta http-equiv="Content-Type" content="text/html;charset=utf-8" > </head> <form name="myloginform" action="/access/dummy" method="post"> UserID <input type="text" name="userid" size="20" value="user1k1"> Password <input type="password" name="password" size="20" value="oblix"> <input type="submit" name="submit" value="Login"> </form> </html>
The action URL is configured so WebGate sets the ObFormLoginCookie for the action URL path, and this cookie is only returned on the form post. When a user submits credentials, the form action is called using the HTTP GET or POST method. The form action does not process the user's credentials for authentication. That is the job of the plug-ins configured for the form-based authentication scheme.
The form action can be a call to a URL that does not do anything. When the form posts to an action URL, WebGate intercepts the post because of the ObFormLoginCookie. WebGate processes the credentials in the post data, authenticates the user, and redirects the user to the originally requested URL as indicated by the ObFormLoginCookie. Since the action URL is never reached, it does not actually have to exist. All that is required is that a policy protect the action URL. In the previous example of a form, the action URL /access/dummy is protected by a policy domain that protects all URLs subordinate to /access. However, /access/dummy, as the name implies, does not exist.
The form action can also be a call to a script that does post-authentication processing. For example, you may have a script that does post-processing on credentials to achieve single sign-on for an application that does not accept header variables. When the form action is a script, the authentication scheme must be configured with the passthrough:yes challenge parameter. This tells WebGate that the action URL is a script that must be executed after the form login. In this case, WebGate does not redirect the user to the originally requested URL. WebGate allows the Web server to continue processing the action URL. WebGate passes the originally requested URL in the ObRequestedURL header variable to the action URL script, and the script can redirect to the original URL if desired.
|
Note: The form action URL must reside in a policy domain protected by the Access System. |
When the form resides on the same server as a WebGate, the submit action assumes that the local host is being used. However, if the form is on a different server from the WebGate, the submit action in the form must return the data to the Web server where the WebGate resides.
Because of the IIS architecture, the WebGate ISAPI plug-in checks all incoming requests for post-processing data. You must do one of the following:
Either set your form action to call the webgate.dll, for instance:
action="/access/oblix/apps/webgate/bin/webgate.dll"
Or ensure the WebGate filter post-processing is turned on by setting the following Registry entry:
HKEY_LOCAL_MACHINE\SOFTWARE\Oblix\Oblix COREid\version\WebGate\postdata="yes"
where version is the version number of the installed product.
This topic describes:
You may want to include only activated users in your obMappingFilter so that only activated users can login. To do this, you must filter users whose obuseraccountcontrol=ACTIVATED.
To include only active users in the obMappingFilter
Follow the procedure "To configure a form-based authentication scheme".
In the mapping filter, specify only active users. An example:
obMappingFilter="(&(objectclass=wwmOrgPerson) (uid=%loginid%) ( | ( ! (obuseraccountcontrol=*)) (obuseraccountcontrol=ACTIVATED)))"
|
Note: This example uses the Oracle sample data (wwmOrgPerson). Change this object class to your site-specific object class. The uid=%loginid% assumes the form has a field called loginid and that this value is also included in the creds field. |
You may want to include non-active users in your obMappingFilter so that deactivated users cannot login. To do this, you filter users with a status of obuseraccountcontrol=PENDING-ACTIVATION or PENDING DEACTIVATED.
To include only non-active users in the obMappingFilter
Follow the procedure "To configure a form-based authentication scheme".
In the mapping filter, specify the inactive users. For example:
obMappingFilter="(&(objectclass=wwmOrgPerson) (uid=%userid%)(!(|(obuseraccountcontrol= PENDING-ACTIVATION)(obuseraccountcontrol=DEACTIVATED) (obuseraccountcontrol=PENDING-DEACTIVATION))))"
|
Note: This example uses the Oracle sample object class wwmOrgPerson. You must change this object class to your site-specific object class. The uid=%loginid% assumes the form has a field called loginid and that this value is also included in the creds field. |
The following sections contain examples of forms that can be used for form-based authentication:
The following are examples of HTML forms and corresponding authentication schemes.
The following is a very simple login form:
<html> <head> <meta http-equiv="Content-Type" content="text/html;charset=utf-8" > </head> <h1>My Login Form</h1> <form name="loginform" action="/oblix/login.cgi" method="post"> Login ID: <input type="text" name="login" size="20" value=""> <p> Submit:<input type="submit" name="submit" value="OK"> <p> Password:<input type="password" name="password" value=""> </form> </html>
The following is another sample login form. It shows the minimum requirements for a form login authentication scheme. A production login form can be enhanced for aesthetics and branding. An example of an authentication scheme using this form is as follows:
Name: Sample Form Login
Description: Uses SampleLoginForm.html
Level: 1
Challenge Method: Form
Challenge Parameters:
form: /loginforms/SampleLoginForm.html
creds: -userid password
action: /access/oblix/apps/webgate/bin/webgate.dll
SSL Required: no
Challenge Redirect: (none)
Enabled: yes
Plug-ins:
credential_mapping obMappingBase="o=Company,c=US", obMappingFilter="(&(&(objectclass=gensiteorgperson) (uid=%userid%))(|(!(obuseraccountcontrol=*)) (obuseraccountcontrol=ACTIVATED)))" validate_password obCredentialPassword="password
For Active Directory, use "user" for the object class and "samaccountname" for the login. For example:
credential_mapping for Active Directory obMappingBase="ou=Hokaido,dc=perry,dc=oblix,dc=com", obMappingFilter="(&(&(objectclass=user)(samaccountname=%login%) )(|(!(obuseraccountcontrol=*))(obuseraccountcontrol=ACTIVATED)) )"
The login form must be either unprotected or protected by an authentication scheme with a challenge method of None. This ensures that the user is not re-challenged when redirected to the login form. For the sample scheme, you can configure a policy domain that protects the form using the Anonymous authentication scheme. This sets a temporary ObSSOCookie when the login form is displayed. The ObSSOCookie is rewritten after a successful login.
In the sample scheme, the userID is the uid attribute from the user's directory profile. The credential_mapping plug-in searches the user directory from the base o=Company,c=US. The credential_mapping plug-in searches for the gensiteorgperson object that contains a uid matching the submitted userID. The additional information in the ObMappingFilter determines whether the user is activated. The validate_password plug-in performs a BIND to the directory, using the submitted password and the user profile DN retrieved when the credential_mapping plug-in searches the directory.
The action is the WebGate local URL. This URL must be protected using any authentication scheme. For example, you might use the Policy Manager policy domain that was optionally created during setup of the Policy Manager.
In the case of IIS, the WebGate action is executed as an ISAPI extension, which allows it to safely obtain the post data containing the credentials. In the case of other Web servers, WebGate intercepts the post request (because the action URL is protected) and extracts the post data for authentication. WebGate sets the ObFormLoginCookie using the action challenge parameter as its path. This ensures that the ObFormLoginCookie is returned only on the post request from the form submission. The ObFormLoginCookie contains information about the originally requested resource. After a successful authentication, WebGate uses this information to redirect the user's browser to the originally requested resource. In the redirection, WebGate sets the ObSSOCookie with the user identity, authentication scheme level, session start and refresh time, and browser IP address.
Sample Login Form
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML> <HEAD> <TITLE>Oracle Access Manager Sample Login Form</TITLE> <META http-equiv=Content-Type content="text/html; charset=windows-utf-8"> <META content="MSHTML 6.00.2800.1226" name=GENERATOR> </HEAD> <BODY> <H2>Oracle Access Manager Sample Login Form</H2> <FORM name=SampleLoginform action=/access/oblix/apps/webgate/bin/ webgate.dll method=post> UserID <INPUT name=userid> Password <INPUT type=password name=password> <INPUT type=submit value=Login name=submit> </FORM> </BODY> </HTML>
10g (10.1.4.0.1) WebGates receive only UTF-8 encoded input data. As a result, form-based authentication supports non-ASCII login credentials (username/password). When you use form-based authentication with 10g Release 3 (10.1.4) WebGates, you must ensure that character set encoding for the login form is set to UTF-8.
To set the login form encoding to UTF-8 for 10g (10.1.4.0.1)
Add the following META tag to the HEAD tag of the login form HTML page.
<META http-equiv="Content-Type" content="text/html;charset=utf-8">
If you upgrade an earlier WebGate to 10g (10.1.4.0.1), you must also update the login form HTML page after upgrading.
The following JSP and ASP code samples create a pop-up login form. This prevents any issues that can arise when a login form is included as a frame within a frameset. The JSP code must be used with a Web server that has a JSP servlet engine. The ASP code must be used with IIS or another Web server with an ASP engine.
When you use one of these login pop-up examples, you need to configure an authentication scheme using one of the following challenge parameters:
form:login/login.asp (assuming the ASP form is stored under the /login folder)
or
form:login/login.jsp (for the JSP form)
JSP Code Sample
<%@ page import="java.util.*" %>
<%
int launchStatus = -1;
String URLVal = "";
String HTTPStart = "http://";
String QueryStr = request.getQueryString();
String ServerName = request.getServerName();
String PathName = request.getServletPath();
if (QueryStr != null)
{
if (QueryStr.indexOf("launchForm") == -1)
{
launchStatus = -1;
}
else
{
launchStatus = 0;
}
URLVal = HTTPStart.concat(ServerName);
URLVal = URLVal.concat(PathName);
URLVal = URLVal.concat("?");
URLVal = URLVal.concat(QueryStr);
URLVal = URLVal.concat("&launchForm=TRUE");
}
else
{
URLVal = HTTPStart.concat(ServerName);
URLVal = URLVal.concat(PathName);
URLVal = URLVal.concat("?launchForm=TRUE");
}
if ((launchStatus != 0))
{
%>
<HTML>
<HEAD>
<SCRIPT Language="Javascript">
function openLoginForm()
{
newUrl = "<%= URLVal %>";
child = window.open(newUrl, "loginFormWindow",
"toolbar=no,directories=no,menubar=no,status=no,scrollbar=no,resizable=yes,widt h=670,height=400");
if (child.opener == null)
{
child.opener = window;
}
window.name = "loginOpener";
if (navigator.appName == "NetScape") {
child.focus();
}
}
</SCRIPT>
</HEAD>
<BODY bgcolor="#ffffff" onload="openLoginForm(); return true;">
<center>
<p>
<hr>
<p>
<Font face="verdana" size="2">
Please enter your login credentials
</Font>
<p>
<hr>
<p>
</center>
</BODY>
</HTML>
<%} else %>
<html>
<script language="JavaScript">
function setAction()
{
document.forms[0].target=self.opener.name;
document.forms[0].submit();
window.close();
}
</script>
<body>
<center>
<h1>User Login</h1>
<br>
<br>
<form name="frmlogin" action="/FormProtect/login.cgi" method="post"
target="loginOpener">
<hr>
<b>User ID </b><input type="text" name="txtUserID">
<br>
<b>Password </b><input type="password" name="pwdPassword">
<br>
<input type="button" title="Login" onclick="javascript:setAction();
" value=Submit>
<hr>
</center>
</form>
</body>
<html>
ASP Code Sample
<%
dim launchForm
launchForm = Request("launchForm")
if launchForm <> "True" then
'This is the plain/blank HTML page
%>
<HTML>
<HEAD>
<SCRIPT Language="Javascript">
function openLoginForm()
{
// now open the new window with newUrl
<% if len(request.servervariables("QUERY_STRING")) > 0 then %>
newUrl= "<%=request.servervariables("URL") & "?" &
request.servervariables("QUERY_STRING") & "&launchForm=True"%>";
<% else %>
newUrl= "<%=request.servervariables("URL") & "?launchForm=True"%>";
<% end if %>
child = window.open(newUrl, "loginFormWindow",
"toolbar=no,directories=no,menubar=no,status=yes,scrollbar=yes,resizable=yes,wi dth=670,height=400");
if (child.opener == null)
{
child.opener = window;
}
window.name = "loginOpener";
if (navigator.appName == "NetScape")
{
child.focus();
}
}
</SCRIPT>
</HEAD>
<BODY bgcolor="#ffffff" onload="openLoginForm(); return true;">
<center>
<p>
<hr>
<p>
<Font face="verdana" size="2">
Please enter your login credentials
</Font>
<p>
<hr>
<p>
</center>
</BODY>
</HTML>
<% else %>
<HTML>
<SCRIPT language="JavaScript">
function setAction()
{
document.forms[0].target=self.opener.name;
document.forms[0].submit();
window.close();
}
</SCRIPT>
<BODY>
<CENTER>
<H1>User Login</H1>
<BR>
<BR>
<form name="frmlogin" action="/FormProtect/login.cgi"
method="post" target="loginOpener">
<HR>
<B>User ID </B><input type="text" name="txtUserID">
<BR>
<B>Password </B><input type="password" name="pwdPassword">
<BR>
<input type="button" title="Login" onclick="javascript:setAction();
" value=Submit>
<HR>
</CENTER>
</FORM>
</BODY>
<HTML>
<% end if %>
Non-ASCII user credentials are supported in only form-based authentication.
The following ASP code sample is a multi-language form that supports both Spanish and English.
<%
Option explicit
dim strLanguage, strNewLanguage, intPointer
dim bolLoginToCOREid
bolLoginToCOREid = Request("LoginToCOREid")
if bolLoginToCOREid = true or bolLoginToCOREid = "true" then
bolLoginToCOREid = true
else
bolLoginToCOREid = false
end if
strLanguage = Request.Cookies("PrefLang")
'Response.Write "lenguaje:" & strLanguage
if strLanguage = "" or strLanguage = "EN" then
strLanguage = "EN"
strNewLanguage = "SP"
intPointer = 0
else
strLanguage = "SP"
strNewLanguage = "EN"
intPointer = 1
end if
dim strUser(1),strPassword(1),strEnter(1),strPreferences(1),strCancel(1)
dim strLanguageDescription(1),strForgot(1),strDescription(1),strMsgUandP(1),strMsgU (1)
dim strUserType(1),strCOREidUser(1),strCOREidAdmin(1)
strUser(0) = "User:"
strUser(1) = "Usuario:"
strPassword(0)="Password:"
strPassword(1)="Contraseña:"
strEnter(0) = "Enter"
strEnter(1) = "Proceder"
strPreferences(0)="Preferences"
strPreferences(1)="Preferencias"
strCancel(0)="Cancel-Portada"
strCancel(1)="Cancelar-Portada"
strLanguageDescription(0)="Espanol"
strLanguageDescription(1)="English"
strForgot(0)="Forgot your password?"
strForgot(1)="¿Olvidó su contraseña?"
strMsgUandP(0)= "Please enter your user name and password."
strMsgUandP(1)= "Por favor teclee su usuario y contraseña."
strMsgU(0)= "Please enter your user name."
strMsgU(1)= "Por favor teclee su usuario."
strUserType(0) = "User Type:"
strUserType(1) = "Tipo de Usuario:"
strCOREidUser(0) = "Oracle Access Manager User"
strCOREidUser(1) = "Usuario Oracle Access Manager"
strCOREidAdmin(0)= "Oracle Access Manager Admin"
strCOREidAdmin(1) = "Administrador Oracle Access Manager"
strDescription(0)="Click ""Preferences"" to see and modify some of your attributes." & _
"<p>Da un clic en ""Español"" para cambiar esta pagina de idioma." & _
"<p>Click ""Forgot your password?"" if you don't remember your
password and you need to change it, " & _
"you will be prompt to answer your challenge phrase."
strDescription(1)="Da un clic en ""Preferencias"
" para ver y modificar algunos de tus atributos." & _
"<p>Click on ""English"" to change the language of this page." & _
"<p>Da un clic en ""¿Olvidó su contraseña?"
" si no recuerdas tu clave y deseas cambiarla, " & _
"será necesario contestar tu frase personal."
dim identityProgram
dim userDN
dim finalURL
identityProgram="/identity/oblix/apps/userservcenter/bin/ userservcenter.cgi?program=modify&tab_id=Employees"
userDN = Request.ServerVariables("HTTP_USERDN")
finalURL = identityProgram & "&uid=" & userDN
dim obTemp
dim ObSSO
dim ObLogin
ObSSO = "ObSSOCookie=loggedout; path=/; domain=.oblix.com"
Response.Cookies("ObFormLoginCookie") = "done 1"
Response.Cookies("ObFormLoginCookie").Expires = Date() - 1
obtemp = "ObTEMP=%23comp_cookie=false%23; path=/"
%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0018)http://10.26.3.90/ -->
<HTML><HEAD>
<TITLE>Login</TITLE>
<meta http-equiv="pragma" content="no-cache">
<%if bolLoginToCOREid then%>
<meta http-equiv="Set-Cookie" content="<%=ObLogin%>"
<%end if%>
<META http-equiv=Content-Type content="text/html; charset=windows-utf-8">
<SCRIPT LANGUAGE=javascript>
<!--
//Functions for keydown
nextfield = "login"; netscape = ""; ver = navigator.appVersion; len = ver.length; for(iln = 0; iln < len; iln++) if (ver.charAt(iln) == "(") break; netscape = (ver.charAt(iln+1).toUpperCase() != "C"); function keyDown(DnEvents) { k = (netscape) ? DnEvents.which : window.event.keyCode; if (k == 13) { if (nextfield == 'done') { setAction(); }else{ eval('document.loginform.' + nextfield + '.focus()'); return; } } } document.onkeydown = keyDown; if (netscape) document.captureEvents(Event.KEYDOWN|Event.KEYUP); //\Functions for keydown expireDate = new Date expireDate.setFullYear(expireDate.getFullYear()+7) var URLs = new Array(2); URLs[0] = "/identity/oblix/apps/userservcenter/bin/ userservcenter.cgi?usertype=delegatedIdentityAdminBIZ"; URLs[1] = "/identity/oblix/apps/admin/bin/ front_page_admin.cgi?usertype=systemAdmin"; function setCookie (name, value, expires) { document.cookie = name + "=" + escape (value) + "; expires=" + expireDate.toGMTString() + "; path=/"; } function delCookie (name) { var expireNow = new Date(); document.cookie = name + "=" + "; expires=Thu, 01-Jan-70 00:00:01 GMT" + "; path=/"; } function changeLanguage(){ setCookie("cemexPrefLang","<%=strNewLanguage%>"); document.location.reload(true); } // Delete the cookie function deletecookie(){ if (document.cookie != "") { thisCookie = document.cookie.split("; ") expireDate = new Date expireDate.setDate(expireDate.getDate()-1) for (i=0; i<thisCookie.length; i++) { cookieName = thisCookie[i].split("=")[1] document.cookie = "cookieName="+cookieName + ";expires=" + expireDate.toGMTString(); } } } function killObCokies(){ // Kill Any Cookies... document.cookie = "<%=obSSO%>" document.cookie = "<%=obLogin%>" //document.cookie = "ObTEMP=; path=/"; //delCookie("ObSSOCookie"); //delCookie("ObFormLoginCookie"); //delCookie("ObTEMP"); } function mySubmit() { if (!((loginform.login.value.length > 0) && (loginform.password.value.length > 0))) { alert("<%=strMsgUandP(intPointer)%>"); return; } // Kill Any Cookies... killObCokies(); //document.cookie = "ObSSOCookie=loggedout; path=/; domain=.cemexnetlab.com" document.location.reload(true); document.cookie = "<%=obTemp%>"; myWindowHandle = window.open ('about:blank','myWindowName','scrollbars=yes,width=600,height=500'); loginform.action="/identityredirect/redirector.asp"; // loginform.action="/identity/oblix/apps/userservcenter/bin/ userservcenter.cgi?program=modify&usertype=endUser"; loginform.target="myWindowName"; loginform.submit(); } function setAction() { if (!((loginform.login.value.length > 0) && (loginform.password.value.length > 0))) { alert("<%=strMsgUandP(intPointer)%>"); document.loginform.login.focus(); return; } killObCokies(); // Kill Any Cookies... document.cookie = "<%=obTemp%>"; <%if bolLoginToCOREid then%> loginform.action = eval ("URLs["+loginform.selectName.options[loginform.selectName.selectedIndex].value +"]"); <%else%> loginform.action="/access/oblix/apps/webgate/bin/webgate.dll"; <%end if%> loginform.target=""; loginform.submit(); } function lost() { if (!(loginform.login.value.length > 0)) { alert("<%=strMsgU(intPointer)%>"); return; } // Kill Any Cookies... killObCokies(); myWindowHandle = window.open (
<%if bolLoginToCOREid then%>
<form name="loginform" action="/identity/oblix/apps/userservcenter/bin/
userservcenter.cgi?usertype=delegatedIdentityAdminBIZ" method="post">
<%else%>
<form name="loginform" action="/access/oblix/apps/webgate/bin/webgate.dll"
method="post">
<%end if%>
<input type="hidden" name="ObLoginDomain" value="dc=oblix,dc=com">
<TABLE cellSpacing=0 cellPadding=0 width=763 align=center border=0>
<TBODY>
<TR vAlign=top>
<TD width="39%" colSpan=2>
<TABLE cellSpacing=0 cellPadding=0 width="100%" border=0>
<TBODY>
<TR>
<TD vAlign=top width="99%" bgColor=#cc0033>
<TABLE cellSpacing=0 cellPadding=0 width="100%" border=0>
<TBODY>
<TR>
<TD align=left><B><FONT face="Verdana, Arial, Helvetica,
sans-serif" color=#ffffff size=2>Login</FONT></B> </TD>
</TR></TBODY>
</TABLE>
</TD>
</TR>
<TR>
<TD>
<TABLE cellSpacing=0 cellPadding=0 width=255 border=0>
<TBODY>
<TR>
<TD align=middle colSpan=3>
<TABLE width="90%" border=0>
<TBODY>
<TR>
<TD align=right width="50%"><FONTclass=classBold>
<%=strUser(intPointer)%> </FONT> </TD>
<TD align=left width="50%">
<input type="text" name="login" size="16"
onFocus="nextfield='password';" value="">
</TD></TR>
<TR> <TD align=right width="50%"><%=strPassword(intPointer)%> </TD> <TD align=left width="50%"> <input type="password" name="password" onFocus="nextfield='done';" value="" size="16"> </TD></TR> <%if bolLoginToCOREid then%> <TR> <TD align=right width="50%"> <%=strUserType(intPointer)%> </TD> <TD align=left width="50%"> <select name="selectName"> <option selected value="0"><%=strCOREidUser(intPointer)%> </option> <option value="1"><%=strCOREidAdmin(intPointer)%> </option> </select> </TD></TR> <%end if%> <TR> <TD colSpan=2> <A href="javascript:setAction();"><%=strEnter(intPointer)%> </A> <A href="javascript:mySubmit();"> <%=strPreferences(intPointer)%></A> <A href="javascript:loginform.reset();"> <%=strCancel(intPointer)%></A> </TD></TR> <TR> <TD colSpan=2> </TD></TR> <TR> <TD align=right colSpan=2> <A href="javascript:changeLanguage();"> <%=strLanguageDescription(intPointer)%></A> </TD></TR> <TR> <TD class=classNormal align=right colSpan=2> <A href="javascript:lost()"><%=strForgot(intPointer)%></A> </TD></TR></TBODY> </TABLE></TD></TR></TBODY> </TABLE></TD></TR></TBODY> </TABLE></TD> <TD width="1%"></TD> <TD width="60%"> <TABLE border=0> <TBODY> <TR> <TD class=classBold width="100%"> <P> <%=strDescription(intPointer)%> </TD></TR></TBODY></TABLE></FORM><DIV id=logoQA><IMG src="login_files/QA.gif"> </DIV><SCRIPT LANGUAGE=javascript><!--document.loginform.login.focus();--></SCRIPT></BODY></HTML>
For information on troubleshooting, see"Troubleshooting Oracle Access Manager" on page E-1.
