Siebel Portal Framework Guide > Integrating External Content >

Determining the Login Requirements

Before you configure Portal Agents, you must understand what information is required by the external application to authenticate users. Typically, this information is gathered using a form page, also called a login page, and then sent to the external application. You must determine exactly what information the form gathers from the user and sends to the external application, including field names and values.

In cases where you have specific knowledge about how an external application is implemented and can consult with authoritative sources regarding how the application authenticates users, determining the required input fields and values is relatively simple.

In cases where you do not have specific knowledge about how an external application is implemented, you must attempt to understand its authentication method by examining the application's login page. The steps below describe an approach that you can use to reverse-engineer a login page and provide related Portal Agent configuration tips.

NOTE:  It is not always possible to reverse-engineer a login page. For example, JavaScript might process login field values prior to delivering the POST back to the application server, session values might be encoded in the form itself, or session values might be stored in the browser's session cookies.

This task is a step in Process of Creating Portal Agents.

To reverse-engineer a login page

1. Navigate to the external application's login page and determine whether the external application uses authentication.

   For more information, see Defining Symbolic URLs.

2. If the external application uses form-based authentication, then view the login page's HTML using your browser's view source command.
3. Identify the form on the login page that asks for user credentials (the form might ask for other information as well) and identify the input fields in this form used to authenticate users.

   It is usually best to strip out all non-form lines of HTML and to isolate the <input> tags. That is, remove lines previous to <form ...> and after </form> and remove lines that are not part of the <input> tags.

4. Determine whether the method attribute of the <form> tag is POST.

   If it is POST, then you must define the PostRequest command as an argument of the symbolic URL. For more information, see Defining Symbolic URL Arguments and PostRequest Command.

   If it is GET, then you do not have to define a symbolic URL command, because the default method of symbolic URLs is GET.

5. Determine the target of the form's action attribute, which is usually specified as action="some string".

   If the target of the action attribute is an absolute URL, one that begins with http or a forward slash (/), then use this URL as the base of the Portal Agent.

   If it is a relative address, then you also have to determine where the root of the URL is defined. It could be defined relative to the URL of the login page itself (most common), in a <codebase> tag (rare) or in JavaScript (hard to determine).

   The target URL is defined using the Host Administration View and the Symbolic URL Administration view. For more information, see Defining the External Host and Defining Symbolic URLs.

6. Determine any argument values defined in the target URL.

   These are the characters after the ? character. Usually, these are simple field-value constants. The exception is when a field or a value is a session identifier that is dynamically assigned by the external application server and is only valid for a period before it times out. In this case, it might not be possible to configure a Portal Agent. Define any argument values contained in the target URL as symbolic URL arguments. For more information, see Defining Symbolic URL Arguments.

7. Identify each of the form's <input> tags and determine which ones are necessary to send to the external application for authentication.

   Often there are <input> tags in the form with a type attribute of hidden that are not evident when interacting with the application. Determining whether hidden fields are optional or required is often process of trial and error.

   Some <input> tags might not have values identified. Either these fields are awaiting input to be entered by the user (for example, login name or password) or they are hidden fields with no values.

   • If the input field is specific to the user (it asks for the user's login name and password), then you can use UserLoginId Command and UserLoginPassword Command commands to instruct the Portal Agent to retrieve the user's credentials from the user's My Logins view. For more information, see Defining End-User Login Credentials.
   • If there are hidden fields with no values, then, when you enter them as symbolic URL arguments, make sure that the Required Argument column is not checked. If it is checked, and the input field has no value, then the Portal Agent does not send this request to the target application server, because there is no value to put in its place.

     You define the input fields and values as symbolic URL arguments. For more information, see Defining Symbolic URL Arguments.

NOTE:  The Mozilla browser includes a page info command (^I) that analyzes forms on a page and displays the method, input fields, and so on.