Siebel Portal Framework Guide > Integrating External Content >

Determining the Login Requirements

Before you configure Portal Agents, you need to 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 may process login field values prior to delivering the POST back to the application server, session values may be encoded in the form itself, or session values may be stored in the browser's session cookies.

To reverse engineer a login page

1. Navigate to the external application's login page and determine whether the external application uses NCSA Basic Authentication or Form-based authentication.

   NCSA Basic is an older authentication mechanism that requires the browser to prompt the user for login name and password before displaying the page. NCSA Basic provides rudimentary protection against trespassers. Usually, you can tell if a site is using NCSA basic because a small popup dialog box will appear asking for login credentials. If this is the case, you can configure the Portal Agent using NCSA basic as the authentication method. See Defining Symbolic URLs for more information.

2. If the external application uses form-based authentication, 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 (often the form will 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 not part of the <input> tags.

4. Determine if the method attribute of the form tag is POST.

   If it is POST, you will need to define the PostRequest command as an argument of the symbolic URL. See Defining Symbolic URL Arguments and PostRequest for more information.

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

5. Determine the target of the from'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 (/), use this URL as the base of the Portal Agent.

   If it is a relative address, you also need 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. See Defining the External Host and Defining Symbolic URLs for more information.

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 a period of time before it times out. In this case, it may not be possible to configure a Portal Agent.

   You will define any argument values contained in the target URL as symbolic URL arguments. See Defining Symbolic URL Arguments for more information on how to do this.

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 will 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), you can use UserLoginId and UserLoginPassword commands to instruct the Portal Agent to retrieve the user's credentials from the user's My Logins view. See Defining End-User Login Credentials for more information.
   • If there are hidden fields with no values, 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, the Portal Agent will not send this request to the target application server because there is no value to put in its place.

     You will need to define the input fields and values as symbolic URL arguments. See Defining Symbolic URL Arguments for more information.

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.