Components and Stores

A  environment includes multiple components. Some components are required to secure resources, while others are optional, or only required to implement specific features. These components work with the resources, applications, directories, and databases in your organization to provide secure access to resources in your enterprise network.
casso127
CA Single Sign-On
 environment includes multiple components. Some components are required to secure resources, while others are optional, or only required to implement specific features. These components work with the resources, applications, directories, and databases in your organization to provide secure access to resources in your enterprise network.
All
CA Single Sign-On
components are supported on several operating systems. Your
CA Single Sign-On
implementation is highly dependent on the environment to which you are deploying it.
Be aware of issues associated with clock synchronization and multiple operating systems. Unsynchronized clocks can result in unexpected
CA Single Sign-On
behavior.
Your implementation does not have to reflect the following diagram. Rather, the purpose of the following diagram is to illustrate the major components in a 
CA Single Sign-On
 environment and their general relationships with each other.
product components overview
product components overview
Use the previous diagram and the following component descriptions as a resource when considering the architectural questions.
2
Policy Server
(Required) A Policy Server (Policy Server) acts as the Policy Decision Point (PDP). The purpose of the Policy Server is to evaluate and enforce access control policies, which it communicates to a 
CA Single Sign-On
 Agent. A Policy Server provides the following features:
  • Policy-based user management
  • Authentication services
  • Authorization services
  • Password services
  • Session management
  • Auditing services
The Policy Server interacts with all other major components to perform these tasks.
CA Single Sign-On
Agents
(Required) An Agent can reside on a web server, a J2EE application server, an Enterprise Resource Planning (ERP) system, or custom application. An Agent acts as the Policy Enforcement Point (PEP), intercepting user requests for resources and communicating with a Policy Server to determine if the resource is protected.
If the resource is not protected, the Agent allows access. If the resource is protected, the Agent continues to communicate with the Policy Server to authenticate and authorize users. A successful authorization prompts the Agent to let the resource request proceed to the server. Agents also:
  • Provide information to web applications to enable content personalization
  • Cache information about authenticated users and protected resources to allow quicker access to resources
  • Enable single sign–on (SSO)
 
CA Single Sign-On
Web Services Security Agents
(Required for
CA Single Sign-On
Web Services Security).  Web Services Security (WSS) Agents act as Policy Enforcement Points (PEPs) that work with the following platforms:
  • Web server
  • J2EE application server
  • Custom application
WSS Agents intercept requests for "big" (SOAP-based) web services. The WSS Agents then communicate with a Policy Server to determine whether the resource is protected.
The
CA Single Sign-On
Agent for JBoss includes
CA Single Sign-On
and
WSS agent functionality.
If the resource is not protected, the agent allows access. If the resource is protected, the agent continues to communicate with the Policy Server to authenticate and authorize users. A successful authorization prompts the agent to let the resource request proceed to the server.
Agents also perform the following other functions:
  • Cache information about authenticated users and protected resources to allow quicker access to resources
  • Enable single sign–on (SSO)
CA Business Intelligence
(Optional) CA Business Intelligence is a set of reporting and analytic software that various CA products use for the purposes of presenting information and supporting business decisions. CA products use CA Business Intelligence to integrate, analyze, and then present, through various reporting options, information that is required for effective enterprise IT management.
CA Business Intelligence includes SAP BusinessObjects Enterprise which provides a complete suite of information management, reporting, and query and analysis tools. CA Business Intelligence installs SAP BusinessObjects Enterprise as a stand–alone component. In this article, this stand–alone component is referred to as the Report Server. Installing the Report Server is a separate step within the overall installation process. Installing the Report Server separately from
CA Single Sign-On
–specific components lets other CA products share Business Intelligence Services.
The Report Server compiles reports to help you analyze your
CA Single Sign-On
environment. The purpose of this component it to create the following types of reports:
  • Audit
  • Policy analysis
The Report Server communicates with the following components to compile reports:
  • The Central Management Server (CMS) database (report database)
  • An Administrative UI
  • A Policy Server
  • CA Single Sign-On
     audit database
Data Stores
CA Single Sign-On
 implementation contains multiple data stores. Some stores are required, while others are optional, or only required to implement specific features.
The following descriptions detail:
  • If the store is required or optional
  • The purpose of the store
Policy Store
(Required) The
CA Single Sign-On
policy store (policy store) is an entitlement store that resides in an LDAP directory server or ODBC database. The purpose of this component is to store all policy-related objects, including the:
  • Resources
    CA Single Sign-On
    is protecting
  • Methods used to protect those resources
  • Users or groups that can or cannot access those resources
  • Actions that must take place when users are granted or denied access to protected resources
The Policy Server uses this information, collectively known as an Enterprise Policy Management (EPM) application or policy, to determine if a resource is protected and if an authenticated user is authorized to access the requested resources.
User Store
(Required) A
CA Single Sign-On
user store connection (user store connection) is a connection to an existing user directory or database in your enterprise network. You are not required to use a proprietary
CA Single Sign-On
user store. The purpose of the user store connection is to make user data available to the Policy Server, which includes the following:
  • Organizational information
  • User and group attributes
  • User credentials, such as passwords
  • User attributes, such as first and last name
The Policy Server uses these connections to:
  • Verify user credentials when an Agent submits a request for a protected resource
  • Retrieve user attributes for the
    CA Single Sign-On
    features that require specific user data
For more information about configuring a user store connection, see the documentation roadmap.
External Administrative User Store
(Optional) By default, the Administrative UI uses the policy store as its source for
CA Single Sign-On
administrator credentials. This default configuration lets you manage the environment immediately after configuring a policy store and installing the Administrative UI. When you configure a policy store, the default
CA Single Sign-On
super user account that is named siteminder is created. This account has maximum system privileges, and is used to access the Administrative UI for the first–time and to create additional
CA Single Sign-On
administrators.
You can configure the Administrative UI to use an external administrator user store, for example, a corporate directory. An external administrative user store is a connection to an LDAP directory server or ODBC database in your enterprise network. Consider the following information:
  • An Administrative UI can only connect to a single external administrative user store.
  • An Administrative UI can be configured to managed multiple Policy Servers. If an Administrative UI is to manage multiple Policy Servers, a connection to an external administrator user store is required.
  • If you configure more than one Administrative UI for high–availability, the same external administrative user store makes all administrators available to each Administrative UI.
For more information about
CA Single Sign-On
administrators and configuring an external administrative user store, see the documentation roadmap.
Key Store
(Required) The purpose of this component is to store the encryption keys that the Policy Servers and the agents use to encrypt sensitive data, which include:
  • The keys that the agents use to encrypt
    CA Single Sign-On
    cookies.
  • The keys that the Policy Servers use to encrypt sensitive policy store information, such as administrator passwords.
  • The keys the Policy Servers use to encrypt session tickets that contain credentials and other information that is related to user sessions.
You can collocate the key store with the policy store or you can store encryption keys in a separate directory or database. The need to deploy a separate key store depends on:
  • How you implement Policy Servers and policy stores.
  • Single sign–on requirements.
If you use the Policy Server Configuration wizard to configure a policy store, the key store is automatically collocated with the policy store.
Certificate Data Store
(Optional) The certificate data store (CDS) makes the following components and functions available to a 
CA Single Sign-On
 environment:
  • Certificate authority (CA) certificates
  • Public and private keys
  • Certificate revocation lists (CRL)
  • OCSP revocation checks
CA Single Sign-On
federation features use the certificate data store. The user certificates that the X.509 certificate authentication scheme uses for authentication are not stored in the certificate data store. These user certificates are stored in an LDAP/AD user directory or ODBC store.
By default, the certificate data store is automatically configured and colocated with the policy store. As a result:
  • A separate external store is not required.
  • All Policy Servers sharing a common view into the same policy store have access to the same keys, certificates, and certificate revocation lists.
  • All administrators that manage the same policy store can manage the certificate data store centrally using the Administrative UI.
CA Single Sign-On
Audit Database
(Optional) By default, the Policy Server writes audit events to a text file, which is known as the Policy Server log. The purpose of audit logs is to track information about all user activity, including:
  • All successful authentications
  • All failed authentications
  • All successful authorization attempts
  • All failed authorization attempts
  • All administrative login attempts
  • All administrative actions, such as changes to administrator passwords, the creation of policy store objects, and changes to policy store objects
However, you can configure a stand–alone audit database (audit database). When deciding where to store audit events, consider that:
  • The Report Server requires a connection to an audit database to create audit–based reports. The Report Server cannot create audit–based reports from a Policy Server log written to a text file.
  • Storing audit logs to a database is more secure than logging the information to a text file.
  • If supported, a policy store can also function as an audit database.
For more information about configuring an audit database, see the documentation roadmap.
Session Store
(Optional) When
CA Single Sign-On
authenticates a user, the Policy Server issues a session ticket. A session ticket contains basic information about the user and authentication information for the user. By default,
CA Single Sign-On
implements session management through non–persistent sessions. If non–persistent sessions are enabled, an Agent writes the session ticket to a cookie on the browser of the users. However, some
CA Single Sign-On
features require persistent sessions.
If persistent sessions are enabled, an Agent must write the session ticket to a stand–alone database.
You deploy a session store (session store) for the following primary reasons:
  • If a log off URI is implemented, a session store prevents a session from being used again after a user logs off.
  • To provide support for features that require persistent user sessions.
Agents use this information to identify users and provide session information to the Policy Server.
For more information about configuring a session store, see the documentation roadmap.
CA Single Sign-On
Administrative UI
(Required) The
CA Single Sign-On
Administrative UI (Administrative UI) is a web–based administration console that is installed independent of the Policy Server. The Administrative UI is intended for managing all tasks that are related to access control, federation, reporting, and policy analysis.