A response is a container for one or more response attributes which the Policy Server sends to a SiteMinder WSS Agent after processing the response. The Policy Server supports several types of response corresponding to different Agent types, each of which provides a different set of attributes, which take the form of name/value pairs.
SiteMinder WSS Agents accept only accept Web Agent responses, which provide attributes (name/value pairs) that can be used by SiteMinder WSS Agents and other CA SiteMinder® agents.
Policies contains rules and responses which are bound to users and user groups. In a policy, responses are bound to specific rules or rule groups. When a rule fires, the associated response returns information to a SiteMinder WSS Agent, such as user attributes, DN attributes, static text, or customized active responses. Responses can also be used to instruct a SiteMinder WSS Agent to generate WS-Security headers and SAML Session Tickets.
CA SiteMinder® supports different types of response attributes. The types of response attributes determine where the Policy Server finds the proper values for the response attributes.
You can specify the following types of response attributes when you add response attributes to a CA SiteMinder® response:
Returns data that remains constant.
Use a static attribute to return a string as part of a CA SiteMinder® response. This type of response can be used to provide information to a Web application. For example, if a group of users has specific customized content on a Web site, the static response attribute, show_button = yes could be passed to the application.
Returns profile information from a user’s entry in a user directory.
This type of response attribute returns information associated with a user in a directory. A user attribute can be retrieved from an LDAP, WinNT, Microsoft SQL Server or Oracle user directory.
Note: In order for the Policy Server to return values from user directory attributes as response attributes, the user directories must be configured on the CA SiteMinder® User Directory pane.
Returns profile information from a directory object in an LDAP, Microsoft SQL Server or Oracle user directory.
This type of response attribute is used to return information associated with directory objects to which the user is related. Groups to which a user belongs, and Organizational Units (OUs) that are part of a user DN, are examples of directory objects whose attributes can be treated as DN attributes.
For example, you can use a DN attribute to return a company division for a user, based on the user’s membership in a division.
Note: In order for the Policy Server to return values from DN attributes as response attributes, the user directories must be configured on the CA SiteMinder® User Directory pane.
Returns values from a customer supplied library that is based on the CA SiteMinder® Authorization API.
An Active Response is used to return information from an external source. An Active Response is generated by having the Policy Server invoke a function in a customer-supplied shared library. This shared library must conform to the interface specified by the Authorization API (available separately with the Software Development Kit; if installed, see the API Reference Guide for C for more information).
Note: It is up to you to make sure the value returned by an active response is valid. For example, if an active response returns a numeric type, the library and function must return a string whose value is a number.
When you configure a response attribute, the correct Value Type for the response attribute is displayed on the Response Attribute pane.
Returns the value of the specified variable at runtime.
Select Variable Definition when you want to select and use a variable from a list of already-defined variables.
In addition to the CA SiteMinder® Web Agent response attributes, CA SiteMinder WSS provides the following Web Agent response attributes that are only applicable for use with WSS Agents:
Provides Policy Server data that the SiteMinder WSS Agent uses to generate a SAML assertion. The data is inserted into an XML message HTTP or SOAP envelope header or a cookie (as specified by associated response attributes).
When you configure a SAML Session Ticket response, the Policy Server generates the response data. This data instructs the SiteMinder WSS Agent how to build the assertion. The SiteMinder WSS Agent encrypts a session ticket (and optionally, the public key from a web service consumer) and the response data. The agent then generates the assertion. The agent delivers the assertion to the web service. The token can only be encrypted and decrypted by the SiteMinder WSS Agent using its Agent key.
Provides Policy Server data that the SiteMinder WSS Agent uses to generate WS-Security Username, X509v3, or SAML tokens (as specified by associated response attributes). These tokens are added to a SOAP message header.
When you configure a WS-Security response, the Policy Server generates the response data. This data instructs the SiteMinder WSS Agent how to build the token. The agent then generates and adds the token to the SOAP request and delivers it to the web service.
Directory mappings let you specify a separate authorization user directory in application object component or a realm. When you define a separate authorization directory, a user is authenticated based on the information contained in one directory, but authorized based on the information contained in another directory.
When you create a response and associate it with a authentication (OnAuth) event, any information retrieved from a user directory is retrieved from the authentication directory. If you create an authorization (OnAccess) event, any information retrieved from a user directory is retrieved from the authorization directory.
WS-Security responses are typically used to instruct the SiteMinder WSS Agent protecting an authentication web service to create WS-Security headers and, optionally, to perform XML encryption on those headers and the message content.
The following illustration shows the response process in such an environment.
Note: Although any authentication scheme can be configured to obtain credentials from a request, not every authentication scheme is suitable for creating every type of WS-Security token.
However, for a web service that receives requests with XML-encrypted elements, but that does not have the logic to decrypt those requests internally, WS-Security responses can be used to instruct the SiteMinder WSS Agent to pass the web service decrypted versions of those requests (see TXM_WSSEC_ENCRYPT_PUB_KEY_ROLE).
WS-Security headers are generated by a SiteMinder WSS Agent (or a third-party security application) after initial authorization of the request, making the WS-Security authentication scheme the ideal basis for multiple web services at federated enterprises.
For CA SiteMinder WSS to produce WS-Security headers, a web service consumer request must first be authorized by the Policy Server using an appropriate authentication scheme (not every authentication scheme obtains everything that is required from the incoming request to create any type of token). The authorizing policy must have a response configured with it that issues WS-Security response data. This data is used by the SiteMinder WSS Agent to generate WS-Security headers. These headers are inserted into the SOAP message header and delivered to the protected web service application. The web service may then pass these headers to the following locations:
CA SiteMinder WSS can produce SOAP messages with WS-Security headers containing the following supported token types:
Username and Password Digest Token
The Username and Password Digest token provides password element confidentiality without requiring channel-level security for the entire document.
The Username token includes a username and password, a cryptographic nonce (a parameter that varies with time) and, optionally, a timestamp. The password is hashed as an SHA1 digest using the nonce, timestamp, and password:
password_digest = SHA1[nonce + timestamp + password]
When a timestamp is included, creating SHA1 password digests provides protection against replay attacks that prevents an eavesdropper from cutting out and replaying the <wsse:UsernameToken> element in a different document at a later time. Also, hashes of the same password along with the same nonce still resolve to different digest values, assuming that the timestamp has been updated.
The Username and Password Digest Token authentication scheme provides protection against replay attacks (where an eavesdropper might cut out and replay the token at a later time) by imposing a limit (60 minutes by default) on the age of the token. That is, if a token was created more than 60 minutes ago according to its <wsu:Created> timestamp, authentication fails.
Note: The Username and Password Digest token is supported only with LDAP and ODBC-based user directories. For LDAP user directories, CA SiteMinder WSS must be configured (using the Credentials and Connection tab in the Policy Server User Interface) to connect to the user store using an LDAP administrative identity if the directory implementation requires such credentials to return the userPassword attribute. For ODBC user directories, a “password” user property must be added to the SQL query scheme used by the directory.
Note: The password storage schemes used by the Username token-generating site must be consistent with the password storage scheme used by the Username token-consuming site. For instance, if the generating site uses SHA-1 password hashes in its user directory, then the consuming site must do the same.
Username and Password Token (Clear Text)
The Username and Password token provides the token subject’s username and clear-text password.
Note: The password storage schemes used by the Username and Password token-generating site must be consistent with the password storage scheme used by the Username token-consuming site. For instance, if the generating site uses SHA-1 password hashes in its user directory, then the consuming site must do the same.
Important! CA recommends that you always use Username and Password tokens with digital signatures or XML encryption to prevent malicious parties from intercepting the message and obtaining the username and password from it.
X509v3 Certificate Token
The X509v3 certificate security token provides the token subject’s X.509v3 certificate in a SOAP document.
When configured to require X509v3 certificate tokens, the WS-Security authentication scheme provides basically the same functionality as the XML Digital Signature authentication scheme, but without requiring certificate mapping, since the signature and key information are contained in standard header elements.
Using the X509v3 certificate token enables the SiteMinder WSS Agent to do the following:
After the signature is verified, the Policy Server does the following:
When generating X.509v3 tokens, CA SiteMinder WSS uses the host web service enterprise’s certificate, which it obtains from the certificate data store (CDS).
WS-Security SAML Assertion Token
The SAML assertion token specification (see OASIS Working Draft 14, Web Services Security: SAML Token Profile, July 12, 2004) extends the token-independent processing model defined by the core WS-Security specification, allowing SAML assertions to be used to provide secure authentication data.
The SAML assertion includes the identity of the web service consumer (typically as its subject) and, optionally, other associated attributes. Additionally, the SAML token specification provides for the use of digital signatures to guarantee the integrity and authenticity of the SAML assertion, its issuer, and the subject of the assertion, using one of the following:
So, when using the WS-Security authentication scheme to authenticate requests with SAML assertion tokens, CA SiteMinder WSS validates the request, to ensure that the assertion comes from a trusted source, by authenticating the assertion subject and the assertion issuer. For example, in a multiple web service implementation using SAML tokens, CA SiteMinder WSS would validate the assertion subject (the web service consumer that made the initial web service request) and the assertion issuer (a CA SiteMinder WSS-protected authentication service configured to produce SAML WS-Security tokens).
The SAML Session Ticket response provides the data that the SiteMinder WSS Agent uses to create an assertion. The only authentication scheme that can evaluate the assertion is the SAML Session Ticket authentication scheme.
When an XML assertion document arrives at a web service protected by the SAML Session Ticket authentication scheme, the SiteMinder WSS Agent does the following:
The binding of the session ticket and the public key ensures that the XML document is signed by a client that is authenticated by CA SiteMinder WSS and that has a valid session.
Then, if the Agent does not have the session ticket in its cache, the Policy Server validates the client with the session ticket from the assertion. If the Agent does have the session ticket in its cache, the Policy Server is not invoked.
Note: The web service that returns the assertion is not protected by the SAML Session Ticket authentication scheme. Only subsequent services in the single sign-on environment require this authentication scheme.
The following illustration shows the response process.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|