How to protect web apps with CA Single Sign On (CA Siteminder)

Before explaining how to protect the web apps with Siteminder SSO I would like to brief about how SSO works.

CA Single Sign On: It’s a property of access control of multiple related, yet independent, systems. With this property, a user with a single ID and password can gain access to a connected system and can seamlessly login into multiple systems.

There are organizations who have many web applications supporting the business. Those web applications must be secured and don’t want everybody to access the application. We can control this using a mechanism that forces each user to login into the application.

This document focuses on protecting an application using “WebAgent.” Webagents are CA developed agent which can integrate with variety of HTTP or Application servers. You can also provide SSO third party or vendor hosted applications through Federation module of CA SSO.

For protecting any web application with SSO, the below steps must be followed.
1) Webagent installation
2) Webagent configuration
3) Policy server configuration

1) Webagent Installation : 

Before going into the details of webagent installation, lets understand about the webagent.
What is a webagent? It’s an agent installed on the web or application servers which intercepts the requests and redirects the requests to SSO login page for the protected resources.

Pre-requisites for installing web agent :
a) Webagent binary have to be selected depending on the webserver bit version and the operating system bit version. You can choose it from CA platform matrix.
b) There will also be some other pre requisites like patches & redistributable patches which are required to be installed depending on the type of operating system.

Steps for installing webagent :

  1. Download the siteminder binary from CA website.
  2. Navigator to the folder where the binary is downloaded and run the binary.
  3. Read the license agreement and select an option to accept the agreement to proceed.
  4. Choose the installation path where you want web agent to be installed.
        If we don’t specify a path, it will be installed in a default path.
  5. Review the information in the pre-installation summary and click on Install.
  6. This will complete the installation process of siteminder/web agent.

2) Webagent configuration 

Once the webagent installation completes, we need to configure the webagent in such a way that it establishes a secure communication between the webserver where the webagent is installed to locate and make a connection to the policy server.

How to configure webagent?

  1. Navigate to the folder install_config_info in the siteminder installation path.
  2. Run the executable ca-wa-config.bin if it’s a windows machine. In Unix/ Linux machines, it can be run with  “./ca-wa-config.bin -i console” command.
  3. Follow the prompts in the configuration program. We need to enter all these values to complete the siteminder configuration.

Register Host :  This field provides an option to register trusted host now or later. It indicates the host name which you will be registering to create a trusted host on the siteminder policy server which will also create SmHost.conf on the webservers. This will establish the trusted communication between the webserver and the policy server.

Admin User Name :  Specifies a siteminder user name which has administrator privileges and already defined in the siteminder policy server.

Admin Password :  Specifies a password for siteminder Admin User Name.

Trusted host Object Name : Specifies a unique name for the trusted host you are registering. This object is stored in the siteminder policy server.

Host Configuration Object : It specifies the name of a host configuration object which is already defined in the policy server. The webagent, for the first time, connects to the policy server through SmHost.conf file and the subsequent connections use the settings in the host configuration object.

Policy Server IP address & Port : It specifies the IP address of the policy server to which webagent needs a connection to. Port details also need to be entered if the policy server is behind a firewall.

FIPS Mode setting :

There are 3 modes in which we can use different algorithms for encrypting the sensitive data.
We can select one of these modes.

a. FIPS Compatibility (Default one)
b. FIPS Migration
c. FIPS Only

Shared Secret rollover :  Select this option to change the shared secret that the siteminder policy server uses to encrypt communications to the webagent.
Select Servers : During the configuration, the system can recognize the webserver instance(e.g Apache, IIS etc..) which is running. All the siteminder modules will be loaded into httpd.conf files and it will create WebAgent.conf file with all the necessary details. If it doesn’t recognize the webserver, all the siteminder modules and the configuration data can be added manually for protecting the webserver instance with webagent.
Agent Configuration Object Name : Specifies the name of the agent configuration object which is already defined in the policy server configuration (gets loaded in WebAgent.conf file).

3) Policy Server Configuration

For every application which needs to be protected with SSO, application teams provide the requirement on what all URIs/resources have to be protected for a particular application.

Depending on the requirement, we have to protect/unprotect the resources using siteminder ADMINUI console. This console is an interface for viewing all the policy server objects created in the policy store.

The below objects are mandatory to create for protecting any resource for any web application.

  • AgentName: It defines the identity of the agent. This identity links the name and the fully qualified domain name of each webserver instance. The policy server uses this identity to tie policies to an agent.
  • Agent group : Agent group creation is not mandatory for every application. Agent group is a collection of Agents of the same type grouped together for common resource protection.
  • Agent Configuration Object : An agent configuration object holds the parameters that define the agent configuration.

We can create a new agent configuration object by taking a copy of the existing configuration which have the default parameters or create a completely new configuration object by adding the parameters manually.

There are some parameters which have be modified depending on the type of the webserver. It includes some important parameters like below.

  1. DefaultAgentName : It’s the name of the installed webagent. AgentName created  above can be added here as a defaultagentname.
  2. Logfile  :  This should be set to Yes for capturing the webagent log.
  3. LogFilePath :  We can refer to the path on the webserver where it will generate webagent log.
  4. TraceFile : Default is No. It can be set to Yes whenever its needed for capturing the trace.
  5. TraceFilePath: We can refer to the path on the webserver where it will generate trace log. This will help in validating the user’s authentication & authorization.
  6. AgentName : We use this parameter when we have more than one DNS to be protected for a single application/instance.
  7. CookieProvider :  This parameter value varies with the type of application and the environment in which application has to be configured

We will create/modify the other parameters like BadCssChars, BadUrlChars and other Parameters in the Agent Configuration Object based on the application teams requirements.

Policy Domain :  It’s a logical grouping of resources that are associated with one or more directories. We will create one domain for an application. Policy domains contain realms, rules, responses and policies(and optionally rule groups & the response groups). By grouping realms and the rules in a policy domain, we can provide secure domain for their resources.

The following lists the process for creating a new policy domain.

  • DomainName :    Enter the name for the policy domain you are creating.
  • User directories :  You can add one or more user directories to the policy domain. These user directories store the user data which will be used during user authentication and authorization while logging into SSO login page.
  • Realms : There can be one or more realms which can be created under each domain. For each realm creation, the below details are needed.
        Realm Name :   Name the realm with a proper naming convention
        Agent :   This is the agentname which was created earlier during the configuration.
        Resource Filter : The actual resource to be protected (E.g: /abc)
        Defalut Resource Protection : We need to select Protected or unprotected option
        Authentication Scheme :  SSO login page gets triggered depending on the authentication scheme we use here.
        Rules :  Rules identify specific resources and either allow or deny access to the resources.
        Session timeout :   SSO maximum or Idle timeout can be set for a realm using this parameter.
  • Responses :   All the user attributes in the form of cookies and the headers which have to sent to the application end will be configured under responses with a response name.
  • Rule groups :    There can be a case where we have different realms and many rules are created for each realm. All the same type of rules present in different realms can be tagged to the same response instead of tagging the rule individually to the same response.
  • Policies:    Policies define how users interact with resources. When you configure a policy, you can select users and groups from the user directories available in the policy domain. Policies define whether the user accessing the resource has proper access to login the application. Different responses/error pages can be triggered using the policies if the user is denied the access.

Authored By - Umasankar Bonumaddi
TCS Cyber Security Pratice

Rate this article: 
Average: 3.1 (12 votes)
Article category: