Why forms based authentication

Using form-based login and a standardized logout means that the user experience for login and logout features will be consistent across browsers. 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 provide additional functionality with the login procedure, such as a link to a page for lost password management.

The forms that you create for form-based authentication only collect user credentials. The processing of authentication and authorization are handled by other functions. The following is a summary of configuring form-based authentication. See "Configuring Form-Based Authentication" for details.

Task overview: Configuring form-based authentication. Create an HTML form where the user's credentials, such as user name and password, can be submitted.

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 "Defining and Managing Authentication Schemes" for details. See Chapter 5, "Configuring User Authentication" for details. As discussed in "Defining a New Authentication Scheme" , When you select the Form challenge method, you are required to provide the following three parameters in the Challenge Parameter fields.

When the user submits a login form that is protected by an authentication scheme with a Form-based challenge method, WebGate processes the credentials that were specified on this parameter. Oracle recommends that you use POST processing, if possible. Accept the default value of no if you want WebGate to redirect the browser back to the originally requested resource.

This omits a form challenge parameter. If you omit this parameter, the end user can post unlimited length strings for authentication to a Web server that is protected by a WebGate.

Very long strings can cause the WebGate or Web server to crash, denial of service, or another fatal error. Enter passthrough:yes if you want to pass the login credentials to a post-processing system, for example, if you want to pass the login credentials to a post-processing program for single sign-on to an application that does not accept header variables. If you set passthrough:yes , note that this settings causes Oracle Access Manager to perform post-processing of the form.

Therefore, when you set passthrough:yes , you must also enter a landing page in the action of the form and protect the landing page. Alternatively, you can create an authentication action that redirects the user to the landing page. The default is passthrough:no , whether it is explicitly set or if the field is left blank.

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:. Without this cookie, WebGate would be unable to send the originally requested resource upon authentication.

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. 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.

Validate Password Authentication Plug-Ins. You can configure the name of the password field. 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. Custom authentication plug-ins can also process other user credential data.

If WebGate intercepts the form login, it can build the session cookie and carry out the authentication actions. 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:.

To retrieve external data for an authentication request. Create an authentication scheme as described in "Defining a New Authentication Scheme". 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. 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.

Form actions, as described in "About the Form Action". 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.

Open the Logon. Switch to Design view, and save the page. Code the event handler so that it validates the user credentials This section presents the code that is placed in the code-behind page Logon. Double-click Logon to open the Logon. Import the required namespaces in the code-behind file: using System.

SqlClient; using System. Security; Create a ValidateUser function to validate the user credentials by looking in the database. Length userName. Length passWord. Add " userName", SqlDbType. VarChar, 25 ; cmd. Parameters[" userName"]. Dispose ; conn.

Value FormsAuthentication. Value, chkPersistCookie. Checked ; else Response. Redirect "logon. Value, DateTime. Now, DateTime. AddMinutes 30 , chkPersistCookie. FormsCookieName, cookiestr ; if chkPersistCookie.

Checked ck. Expiration; ck. FormsCookiePath; Response. EventHandler this. Security; Double-click SignOut to open the code-behind page Default. SignOut ; Response. You can now use the application. Additional notes You may want to store passwords securely in a database.

Forms-based authentication requires that your client accept or enable cookies on their browser. What is the difference between "basic auth" and "form-based auth"? Share Article. On a scale of , please rate the helpfulness of this article 1 2 3 4 5.

Not Helpful. Very Helpful. Optionally provide additional feedback to help us improve this article Thank you for your feedback!