Agents are network entities that act as filters to enforce network access control or web access control. They are considered Policy Enforcement Points (PEPs). Agents monitor requests for resources. Users request protected resources. The agent prompts the user for credentials that are based on an authentication scheme. The agent sends the credentials to a Policy Server.
The Policy Server determines whether a user can be authenticated based on the credentials, and whether the user is authorized for the requested resource. The Policy Server then communicates with the Agent, which allows or denies access to the requested resource.
Web Agents, Affiliate Agents, EJB Agents, Servlet Agents, and RADIUS Agents are available by default. All other Agents are considered Custom Agents that must be created using the Agent APIs. Once created, you can configure Custom Agents in the Administrative UI.
Agents operate with web servers. When a user requests a page from the web server, the Web Agent communicates with the Policy Server. The agent processes the authentication and authorization requests before the user can access the resource. The Policy Server can also provide information for the agent to provide personalized for the user.
The following diagram illustrates the three most basic transactions that an Agent and Policy Server handle. These transactions can contain more detailed information to enable customized content and support other features of the product. The process is similar whenever a user attempts to access a resource through a web server that an agent manages.
The previous figure assumes that a user requests a protected resource for which the user is authorized. The agent checks with the Policy Server to determine whether the resource is protected. For protected resources, the agent gathers credentials from the user and forwards them to the Policy Server.
The Policy Server authenticates the user and informs the Web Agent that the user has been properly identified. Finally, the Web Agent determines whether the user is authorized for the resource by checking with the Policy Server. Once the Policy Server verifies authorization, the agent is notified. The agent allows the web server to display the protected resource to the user.
Agents that control the same resources and are of the same Agent type (all Web Agents, or all RADIUS Agents) can be grouped.
The SAML Affiliate Agent is part of the legacy federation solution, which enables business partners to share user identity information.
Note: Legacy Federation and the SAML Affiliate Agent are packaged as separately licensed items.
The SAML Affiliate Agent is installed only at the consumer site. This Agent enables a site to consume assertions that are sent from a producer, facilitating seamless single sign-on between a producer and a consumer. The assertion confirms that a user has been authenticated at the producer. The consumer uses the information in the assertion to provide user information to a web server for access to resources and web applications.
If CA SiteMinder® is at the producer, you configure legacy federation components that identify each partner for which CA SiteMinder® can generate assertions.
Note: In the Administrative UI, you can select an Affiliate Agent as the Agent type. This option is not for the SAML Affiliate Agent. The option is only applicable for 4.x Affiliate Agents. Do not select it.
If you install a SAML Affiliate Agent at an affiliate site, it is the only CA SiteMinder® component that is required at that site for federated transactions. A full CA SiteMinder® installation is not required at the consumer site because an application at the partner can enforce access control.
If CA SiteMinder® is serving as the SAML 1.0 producer, the following producer-side components are required to support legacy federation:
The following graphic shows a federated network with SAML Affiliate Agents.
In the pictured network, company.com has a full CA SiteMinder® installation and can generate assertions. When a user requests a federated resource, the user initially authenticates at company.com. Company.com generates an assertion and redirects the user to the appropriate affiliate partner. At the partner, the SAML Affiliate Agent consumes the assertion and passes the necessary information to the web application. The user experiences a single sign-on transaction and gains access to the requested resource.
The remote Authentication Dial-In User Service (RADIUS) protocol exchanges session authentication and configuration information between Network Access Servers (NAS) and RADIUS authentication servers. Proxy services, firewalls, or dial-up security devices often use the RADIUS protocol.
A RADIUS Agent secures an entire application that communicates using the RADIUS protocol.
The Policy Server can be used as a RADIUS authentication server. RADIUS Agents allow the Policy Server to communicate with the NAS client devices.
The Application Server Agent is a collection of Java components that provide a full-featured agent for securing WebLogic and WebSphere application server resources. The Application Server Agent integrates the product with the J2EE platform.
The Application Server Agent can protect the following components:
The Application Server Agent is a single Agent. From the perspective of the Policy Server, there are different Agent types that protect application server resources. The Agent types offer the flexibility to protect servlets, and EJB components in the following ways:
WSS (formerly SOA) Agents integrate with web and application servers to authenticate and authorize requests for access to SOAP/XML-based web services resources on those servers.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|