Implementation Guide › Configuration Considerations › Authentication and a Centralized Login Server

Authentication and a Centralized Login Server

A CA SiteMinder® 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 SiteMinder® 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.

Note: For more information about authentication schemes, see the Policy Server Configuration Guide.

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 SiteMinder® 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:

Example: Grouping applications by authentication requirements

A CA SiteMinder® 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.

  By identifying applications that share the same authentication requirements, three login pages replace the need for eight, as detailed by the following table:

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 SiteMinder® OnAuthAttempt and OnAuthReject responses to redirect users.

  Note: For more information about responses, see the Policy Server Configuration Guide.

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

    Note: For more information about the login FCC as it applies to forms–based authentication, see the Policy Server Configuration Guide. For more information about configuring the login FCC with a Web Agent and how the FCC process requests, see the Web Agent Configuration Guide.

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

  Note: For more information about configuring a logoff page, see the Web Agent Configuration Guide.

Login Page Use Cases

The purpose of the following use cases is to get you thinking about configuring CA SiteMinder® 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 SiteMinder® 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.

    Note: For more information about the SMTRYNO cookie, see the Web Agent Configuration Guide.

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

  Note: For more information about configuring an FCC file with @directives, see the Policy Server Configuration Guide.

• A CA SiteMinder® administrator has configured a form–based authentication scheme named Auth1. The target of Auth1 is login.asp.

  Note: For more information about configuring authentication schemes, see the Policy Server Configuration Guide.

The following diagram illustrates the authentication process for this use case:

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.

    Note: For more information about the SMTRYNO cookie, see the Web Agent Configuration Guide.

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

  Note: For more information about configuring an FCC file with @directives, see the Policy Server Configuration Guide.

• A CA SiteMinder® administrator has configured a form–based authentication scheme named Auth1. The target of Auth1 is login.asp.

  Note: For more information about configuring authentication schemes, see the Policy Server Configuration Guide.

The following diagram illustrates the authentication process for this use case:

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.

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