The Authentication Service user interface is accessed by entering a login URL into the Location Bar of a web browser. This URL is:
http://AccessManager-root/.domain_name:port /service_deploy_uri /UI/Login
During installation, the service_deploy_uri is configured as amserver. This default service deployment URI will be used throughout this document.
The user interface login URL can also be appended with Login URL Parameters to define specific authentication methods or successful/failed authentication redirection URLs.
A URL parameter is a name/value pair appended to the end of a URL. The parameter starts with a question mark (?) and takes the form name=value. A number of parameters can be combined in one login URL, for example:
http://server_name.domain_name:port/amserver/UI/ Login?module=LDAP&locale=ja&goto=http://www.sun.com
If more than one parameter exists, they are separated by an ampersand (&). The combinations though must adhere to the following guidelines:
Each parameter can occur only once in one URL. For example, module=LDAP&module=NT is not computable.
Both the org parameter and the domain parameter determine the login realm. In this case, only one of the two parameters should be used in the login URL. If both are used and no precedence is specified, only one will take effect.
The parameters user, role, service, module and authlevel are for defining authentication modules based on their respective criteria. Due to this, only one of them should be used in the login URL. If more than one is used and no precedence is specified, only one will take effect.
The following sections describe parameters that, when appended to the User Interface Login URL and typed in the Location bar of a web browser, achieve various authentication functionality.
To simplify an authentication URL and parameters for distribution throughout an realm, an administrator might configure an HTML page with a simple URL that possesses links to the more complicated login URLs for all configured authentication methods.
A goto=successful_authentication_URL parameter overrides the value defined in the Login Success URL of the Authentication Configuration service. It will link to the specified URL when a successful authentication has been achieved. A goto=logout_URL parameter can also be used to link to a specified URL when the user is logging out. For an example of a successful authentication URL:
http://server_name.domain_name:port/amserver/ UI/Login?goto=http://www.sun.com/homepage.html
An example goto logout URL:
http://server_name.domain_name:port/amserver/ UI/Logout?goto=http://www.sun.com/logout.html.
There is an order of precedence in which Access Manager looks for successful authentication redirection URLs. Because these redirection URLs and their order are based on the method of authentication, this order (and related information) is detailed in the Authentication Types section.
A gotoOnFail=failed_authentication_URL parameter overrides the value defined in the Login Failed URL of the Authentication Configuration service. It will link to the specified URL if a user has failed authentication. An example gotoOnFail URL might be http:// server_name.domain_name:port /amserver/UI/Login?gotoOnFail=http://www.sun.com/auth_fail.html.
There is an order of precedence in which Access Manager looks for failed authentication redirection URLs. Because these redirection URLs and their order are based on the method of authentication, this order (and related information) is detailed in Authentication Types section.
The org=realmName parameter allows a user to authenticate as a user in the specified realm.
A user who is not already a member of the specified realm will receive an error message when they attempt to authenticate with the realm parameter. A user profile, though, can be dynamically created in the Directory Server if all of the following are TRUE:
The User Profile attribute in the Core Authentication Service must be set to Dynamic or Dynamic with User Alias.
The user must successfully authenticate to the required module.
The user does not already have a profile in Directory Server.
From this parameter, the correct login page (based on the realm and its locale setting) will be displayed. If this parameter is not set, the default is the top-level realm. For example, an org URL might be:
http://server_name.domain_name:port/amserver/UI/Login?realm=sun
The org=orgName parameter allows a user to authenticate as a user in the specified organization.
A user who is not already a member of the specified organization will receive an error message when they attempt to authenticate with the org parameter. A user profile, though, can be dynamically created in the Directory Server if all of the following are TRUE:
The User Profile attribute in the Core Authentication Service must be set to Dynamic or Dynamic with User Alias.
The user must successfully authenticate to the required module.
The user does not already have a profile in Directory Server.
From this parameter, the correct login page (based on the organization and its locale setting) will be displayed. If this parameter is not set, the default is the top-level organization. For example, an org URL might be:
http://server_name.domain_name:port/amserver/UI/Login?org=sun
The user=userName parameter forces authentication based on the module configured in User Authentication Configuration attribute of the user’s profile. For example, one user’s profile can be configured to authenticate using the Certification module while another user might be configured to authenticate using the LDAP module. Adding this parameter sends the user to their configured authentication process rather than the method configured for their organization. For example:
http://server_name.domain_name:port/amserver/UI/Login?user=jsmith
A role=roleName parameter sends the user to the authentication process configured for the specified role. A user who is not already a member of the specified role will receive an error message when they attempt to authenticate with this parameter. For example:
http://server_name.domain_name:port/amserver/UI/Login?role=manager.
Access Manager has the capability to display localized screens (translated into languages other than English) for the authentication process as well as for the console itself. The locale=localeName parameter allows the specified locale to take precedence over any other defined locales. The login locale is displayed by the client after searching for the configuration in the following places, order-specific:
Value of locale parameter in Login URL
The value of the locale=localeName parameter takes precedence over all other defined locales.
Locale defined in user’s profile
If there is no URL parameter, the locale is displayed based on the value set in the User Preferred Language attribute of the user profile.
Locale defined in the HTTP header
This locale is set by the web browser.
Locale defined in Core Authentication Service
This is the value of the Default Auth Locale attribute in the Core Authentication module.
Locale defined in Platform Service
This is the value of the Platform Locale attribute in the Platform service.
Operating system locale
The locale derived from this pecking order is stored in the user’s session token and Access Manager uses it for loading the localized authentication module only. After successful authentication, the locale defined in the User Preferred Language attribute of the user’s profile is used. If none is set, the locale used for authentication will be carried over. For example:
http://server_name.domain_name:port/amserver/UI/Login?locale=ja. |
Information on how to localize the screen text and error messages can be found in the Access Manager.
The module=moduleName parameter allows authentication via the specified authentication module. Any of the modules can be specified although they must first be registered under the realm to which the user belongs and selected as one of that realm’s authentication modules in the Core Authentication module. For example:
http://server_name.domain_name:port/amserver/UI/Login?module=Unix.
The authentication module names are case-sensitive when used in a URL parameter.
The service=serviceName parameter allows a user to authenticate via a service’s configured authentication scheme. Different authentication schemes can be configured for different services using the Authentication Configuration service. For example, an online paycheck application might require authentication using the more secure Certificate Authentication module while an realm’s employee directory application might require only the LDAP Authentication module. An authentication scheme can be configured, and named, for each of these services. For example:
http://server_name.domain_name:port/amserver/UI/Login?service=sv1.
The Authentication Configuration service is used to define a scheme for service-based authentication.
The arg=newsession parameter is used to end a user’s current session and begin a new one. The Authentication Service will destroy a user’s existing session token and perform a new login in one request. This option is typically used in the Anonymous Authentication module. The user first authenticates with an anonymous session, and then hits the register or login link. For example:
http://server_name.domain_name:port/amserver/UI/Login?arg=newsession.
An authlevel=value parameter tells the Authentication Service to call a module with an authentication level equal to or greater than the specified authentication level value. Each authentication module is defined with a fixed integer authentication level. For example:
http://server_name.domain_name:port/amserver/UI/Login?authlevel=1.
The Authentication Level is set in each module’s specific profile. .
This parameter allows a user to login to an realm identified as the specified domain. The specified domain must match the value defined in the Domain Name attribute of the realm’s profile. For example:
http://server_name.domain_name:port/amserver/UI/Login?domain=sun.com.
A user who is not already a member of the specified domain/realm will receive an error message when they attempt to authenticate with the org parameter. A user profile, though, can be dynamically created in the Directory Server if all of the following points are TRUE:
The User Profile attribute in the Core Authentication Service must be set to Dynamic or Dynamic With User Alias .
The user must successfully authenticate to the required module.
The user does not already have a profile in Directory Server.
The iPSPCookie=yes parameter allows a user to login with a persistent cookie. A persistent cookie is one that continues to exist after the browser window is closed. In order to use this parameter, the realm to which the user is logging in must have Persistent Cookies enabled in their Core Authentication module. Once the user authenticates and the browser is closed, the user can login with a new browser session and will be directed to console without having to re-authenticate. This will work until the value of the Persistent Cookie Max Time attribute specified in the Core Service elapses. For example:
http://server_name.domain_name:port/amserver/UI/Login?org=example&iPSPCookie=yes
This parameter option to enables a user to pass authentication credentials using a URL or HTML forms. With the IDTokenN=value parameters, a user can be authenticated without accessing the Authentication Service User Interface. This process is called Zero Page Login. Zero page login works only for authentication modules that use one login page. The values of IDToken0, IDToken1, ..., IDTokenN map to the fields on the authentication module’s login page. For example, the LDAP authentication module might use IDToken1 for the userID information, and IDToken2 for password information. In this case, the LDAP module IDTokenN URL would be:
http://server_name.domain_name:port/amserver/UI/ Login?module=LDAP&IDToken1=userID&IDToken2=password
(module=LDAP can be omitted if LDAP is the default authentication module.)
For Anonymous authentication, the login URL parameter would be:
http://server_name.domain_name:port/amserver/UI/Login?module=Anonymous&IDToken1=anonymousUserID.
The token names Login.Token0, Login.Token1, ..., Login.TokenN (from previous releases) are still supported but will be deprecated in a future release. It is recommended to use the new IDTokenN parameters.