Authentication and a Centralized Login Server

Contents
sm1252sp1
Contents
A
CA Single Sign-On
deployment typically includes applications for which different authentication (login) requirements exist. These requirements can result in numerous login pages that the individual application owners must manage. Managing these login pages locally can introduce inconsistencies, such as page design and the presentation of error messages, that can affect the overall authentication experience.
We recommend managing login pages centrally to help:
  • Create consistency across your applications. If a single
    CA Single Sign-On
    team owns all login pages, the team can implement them consistently and manage them easier.
  • Minimize the number of login pages. Minimizing the number of entry points into applications creates the impression that users are logging into a centralized infrastructure, rather than individual applications.
Consider the following when configuring login pages:
  • Identify applications that share the same authentication requirements and reuse the same login page.
  • Use a centralized login server to host all login pages
  • Configure login pages to inform users when:
    • They have failed to provide valid credentials.
    • Too many attempts have resulted in a failed authentication.
Centralize Login Pages
Application login requirements can range from basic user name/password authentication to forms–based authentication to digital certificates. If possible, we recommend:
  • Managing all login pages from a central login server to avoid duplication on every web application.
  • Managing all other system–wide resources, such as password services pages, error pages, and terms and conditions pages from a central server.
Managing login pages centrally is the process of identifying applications that share the same login requirements. Consider the following when configuring authentication:
  • Try to avoid creating separate login pages for each application. As
    CA Single Sign-On
    adoption increases, managing a login page for every application may not be sustainable.
  • Identify applications that share the same authentication requirements. If possible, use a single login page as an entry point into these applications.
Use a table similar to the following to group applications by authentication requirements:
Auth Scheme Name
Type
Login Page Server
Login Page URL
 
 
 
 
 
 
 
 
 
 
 
 
Example: Grouping applications by authentication requirements
A
CA Single Sign-On
environment protects ten applications:
  • Five of the applications require forms-based authentication.
  • Three of the applications require Windows-based authentication.
  • Two of the applications require basic user name/password authentication.
Auth Scheme Name
Type
Login Page Server
Login Page URL
Auth1
Forms
login.acme.com
/login.asp
Auth2
Windows
login.acme.com
/smgetcrd.ntc
Auth3
Basic
login.acme.com
n/a
 
Best Practices
Consider the following when configuring login pages:
  • Display an error message when a user fails to authenticate properly.
  • Redirect users to a page that displays a message that the number of login attempts has been exceeded.
  • We recommend using forms–based authentication to redirect users. If you are unable to use forms–based authentication, you can use the
    CA Single Sign-On
    OnAuthAttempt and OnAuthReject responses to redirect users.
    • If you configure forms–based authentication, consider creating a dynamic page, such as login.asp, to create a tighter integration with your existing infrastructure.
    • If creating a dynamic page is not possible, use the sample login FCC file (login.fcc) that is included as part of the Web Agent installation to configure a login FCC file. The default location for the sample file is
      web_agent_home
      \samples_default\forms. The forms directory is the default location for files that the Forms Credential Collector (FCC) processes.
      • web_agent_home
        Specifies the Web Agent installation path.
  • We recommend creating a separate directory on the Web Agent host system for all login pages. Using a location other than the forms directory helps to prevent the sample files from being accidentally overwritten.
  • Display a custom logoff page after a user logs out successfully.
Login Page Use Cases
The purpose of the following use cases is to get you thinking about configuring
CA Single Sign-On
authentication.
These use cases reflect best practices and are intended to identify techniques that you can use as part of a global architecture. These use cases are not intended as a final architecture. Extrapolate the necessary infrastructure from these cases to configure login pages that best meet the needs of your organization.
Stand–Alone Login Page
In this use case,
CA Single Sign-On
directs users to a stand–alone login page when they request a protected resource. Specifically:
  • A dynamic login page (login.asp) is deployed to the Web Agent host system.
  • The dynamic login page is coded to:
    • Post to a login FCC file (login.fcc).
    • Display an error message when the SMTRYNO cookie is present in the web browser of the user.
  • The login FCC file is configured with an @directive (@smretries) to redirect users to a failed authentication page (login.unauth) after two failed authentication attempts.
  • A
    CA Single Sign-On
    administrator has configured a form–based authentication scheme named Auth1. The target of Auth1 is login.asp.
The following diagram illustrates the authentication process for this use case:
Graphic showing the authentication process using a dynamic login page
  1. A user requests a protected resource.
  2. The Web Agent contacts the Policy Server, which determines that the resource is protected.
  3. The Web Agent redirects the user request to login.asp.
  4. The user submits invalid credentials. The credentials are posted to the login.fcc file and processed by the FCC.
  5. The FCC forwards the credentials to the Policy Server.
  6. The Policy Server determines that the credentials are invalid and notifies the FCC.
  7. The FCC inserts the SMTRYNO cookie into the web browser of the user and redirects the user to the login page.
  8. The login page refreshes with an error message. The error message states that invalid credentials were supplied and to try again.
  9. The user submits invalid credentials. The credentials are posted to the login.fcc file and processed by the FCC.
  10. The FCC forwards the credentials to the Policy Server.
  11. The Policy Sever determines that the credentials continue to be invalid and notifies the FCC.
  12. The user has exceeded the maximum number of failed authentication attempts and is redirected to a page that displays a failed authentication message.
Embedded Form on a Web Portal
In this use case, a form is embedded on a web portal home page. Users enter credentials in the form and are redirected to the protected resource upon authentication. Specifically:
  • A web portal home page (portal.asp) includes an embedded form that prompts users for credentials. The home page:
    • Contains a target variable that points to the protected resource.
    • Posts to a login FCC file (login.fcc).
  • A stand-alone login page (login.asp) is deployed to the Web Agent host system. If users try to access the protected resource directly, this page prompts users for credentials. The login page:
    • Posts to the login FCC file.
    • Displays an error message when the SMTRYNO cookie is present in the web browser of the user.
  • The login FCC file is configured with an @directive (@smretries) to redirect users to a failed authentication page (login.unauth) after two failed authentication attempts.
  • A
    CA Single Sign-On
    administrator has configured a form–based authentication scheme named Auth1. The target of Auth1 is login.asp.
The following diagram illustrates the authentication process for this use case:
Illustration of the authentication process using an embedded form in a web portal
  1. A user navigates to the web portal home page.
  2. The Web Agent contacts the Policy Server, which determines that the resource is unprotected.
  3. The user submits invalid credentials. The credentials are posted to the login.fcc file and processed by the FCC.
  4. The FCC forwards the credentials to the Policy Server.
  5. The Policy Server determines that the credentials are invalid and notifies the FCC.
  6. The FCC inserts the SMTRYNO cookie into the web browser of the user and redirects the user to the login page. The login page appears with an error message. The error message states that invalid credentials were supplied and to try again.
    Although not illustrated, if the user accessed the protected resource directly, the login page would appear without an error message because the web browser would not contain the SMTRYNO cookie.
  7. The user submits invalid credentials. The credentials are posted to the login.fcc file and processed by the FCC.
  8. The FCC forwards the credentials to the Policy Server.
  9. The Policy Sever determines that the credentials continue to be invalid and notifies the FCC.
  10. The user has exceeded the maximum number of failed authentication attempts and is redirected to a page that displays a failed authentication message.