This section contains the following topics:
How to Configure Responses to Produce WS-Security Headers
How to Configure Responses to Produce SAML Session Tickets
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.
Web Agent response attributes are response attributes that CA SiteMinder® agents can interpret and pass on to other applications. The following list describes the generally available Web Agent response attributes:
Indicates an attribute that is reserved for future use.
Generates a SetCookie header, which then sets a nonpersistent cookie in a web browser. The cookies only exist in the cookie domain where the agent is configured. You can enter multiple WebAgent-HTTP-Cookie-Variables.
Limits: Use in accept or reject responses. Multiple instances of this attribute are allowed per response.
Specifies an arbitrary dynamic name/value pair for use by a web application. You can enter multiple WebAgent-HTTP-Header-Variables.
The agent does not include header variables in the responses that it sends back to a web browser. Instead, these responses reside in the request headers of the web server.
Consequently, the header variables are not visible in the debug logs that you can enable from the Policy Server Management Console.
Limits: Use in accept or reject responses. Multiple instances of this attribute are allowed per response.
Generates a response with an open format cookie that is then set in a web browser. The open format cookie provides identity information about a user. You can select multiple identity attributes to include specific identity information in the cookie.
Options: Use in an OnAuthAccept or OnAccessAccept response. Multiple instances of this attribute are allowed per response.
Defines one of the following URLs, depending on the type of response in which it is used:
To specify whether an authorization response or authentication response, include it in a policy with a rule that specifies an OnAuthAccept or OnAccessAccept event action.
Limits: Use in accept responses. Only one instance of this attribute is allowed per response.
Specifies text that the Web Agent puts in the HTTP_ONACCEPT_TEXT environment variable when it redirects the user after a successful authorization or authentication attempt.
Limits: Use in accept responses. Only one instance of this attribute is allowed per response.
Note: When configuring a Web Agent OnAcceptText response, set the FCC Compatibility Mode parameter (fcccompatmode) corresponding to the Web Agent to yes. This action ensures that user authentication takes place at the Web Agent and that the text is available for display in the browser. If the FCC Compatibility Mode parameter is set to no, user authentication takes place at the Forms Credential Collector (FCC). The response is triggered, but the text in the response is lost.
Overrides the number of seconds a user session can be idle. When this limit is reached, the user is forced to authenticate again. Associate this response with a rule configured with an OnAuthAccept authentication event.
Limits: Use in accept responses. Only one instance of this attribute is allowed per response.
Overrides the total number of seconds a user session can be active. When this limit is reached, the user session is terminated and the user is forced to authenticate again. Associate this response with a rule configured with an OnAuthAccept authentication event.
Limits: Use in accept responses. Only one instance of this attribute is allowed per response.
Specifies an AuthContext response attribute for an authentication scheme. The value of this response attribute is added to the session ticket as the value of the SM_AUTHENTICATIONCONTEXT user attribute. The value is not returned to the client as a user response.
Note: The response attribute value is truncated to 80 bytes in length.
Limits: Used in accept responses. Only one instance of this attribute is allowed per response.
Stores a particular Session Variable in the session store when an administrator has decided against persisting all authentication data.
Limits:Used in accept responses. Persistent Sessions are enabled.
Defines one of the following URLs:
To specify an authorization response or authentication response, include it in a policy with a rule that specifies an OnAuthReject or OnAccessReject event action.
Limits: Use in reject responses. Only one instance of this attribute is allowed per response.
Specifies text that the Web Agent puts in the HTTP_ONREJECT_TEXT environment variable when it redirects the user after a failed authorization or authentication attempt.
Limits: Use in reject responses. Only one instance of this attribute is allowed per response.
Generates a response that specifies that the requested resource is sensitive and requires that a user must validate their identity before being granted access. This validation is required each time the user requests access, even if they have a valid session.
Options: Use in accept responses. Only one instance of this attribute is allowed per response.
The following response attributes are also available but only applicable for use with CA SiteMinder® Web Services Security 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® Web Services Security 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® Web Services Security 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® Web Services Security 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® Web Services Security 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® Web Services Security 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® Web Services Security would validate the assertion subject (the web service consumer that made the initial web service request) and the assertion issuer (a CA SiteMinder® Web Services Security-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® Web Services Security 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 © 2013 CA.
All rights reserved.
|
|