Using a SiteMinder Server

index.html - {keywords1}- Authentication events occur when a user accesses a resource protected by a rule that includes an On-Auth event. Unlike Web Agent actions or authorization events ...


Skip To Main Content Account Settings Logout placeholder Account Settings Logout

Ivanti Policy Secure 9.1R14 Administration Guide

Home

Using a SiteMinder Server

This topic describes integration with the SiteMinder server.

SiteMinder Server Overview

This section describes support for using IPS with the SiteMinder server.

Understanding SiteMinder Server

CA SiteMinder server is an authentication and authorization server.

When you configure the Pulse Secure access management framework to authenticate users with a SiteMinder policy server, the system passes the user’s credentials to SiteMinder during authentication. Once SiteMinder receives the credentials, it may use standard username and password authentication, RSA Authentication Manager SecurID tokens, or client-side certificates to authenticate the credentials.

The system also passes a protected resource URL to SiteMinder during authentication to determine which SiteMinder realm it should use to authenticate the user. When the system passes the protected resource URL, SiteMinder authorizes the user’s URL against the realm that is associated with the resource and allows the user to seamlessly access any resources whose protection levels are equal to or less than the URL that was passed.

Feature Support

The Pulse Secure access management framework supports the following SiteMinder features:

Single Sign-on Using SMSESSION Cookies

The Pulse Secure access management framework enables single sign-on (SSO) to SiteMinder-protected resources using SMSESSION cookies. An SMSESSION cookie is a security token that encapsulates SiteMinder session information. Depending on your configuration, either the SiteMinder Web agent or the system creates an SMSESSION cookie and then posts the cookie to the following locations so the user does not have to reauthenticate to access additional resources.

Pulse Secure access management framework-If the user tries to access a SiteMinder resource within the session (for example, from the system file browsing page), the system passes its cached SMSESSION cookie to the Web agent for authentication. The user’s Web browser-If the user tries to access a SiteMinder resource from outside the session (for example, when using a protected resource on a standard agent), SiteMinder uses the cached SMSESSION cookie stored in the user’s Web browser to authenticate/authorize the user.
Automatic Sign-In

If you enable the Automatic Sign-In option, the system can use an SMSESSION cookie generated by another agent to enable single sign-on from a SiteMinder resource. When a user accesses the system sign-in page with an SMSESSION cookie, the system verifies the SMSESSION cookie. Upon successful verification, the system establishes a session for the user. You can use the following authentication mechanisms when you enable automatic sign-in through the system:

Custom agent-The system authenticates the user against the policy server and generates a SMSESSION cookie. When you select this option, you can enable SSO on other SiteMinder agents that use the same policy server. To enable SSO on these agents, update each of them to accept third-party cookies. If you select this option and the user enters his system session with an SMSESSION cookie, the system attempts automatic sign-in when the user enters the session. HTML form post-The system posts credentials to a standard Web agent that you have already configured. The Web agent then creates SMSESSION cookies. If you select this option, you cannot use SecurID New Pin and Next Token modes or client-side certificate authentication. If you select this option and the user enters his session with an SMSESSION cookie, the system attempts automatic sign-in when the user enters the session. Delegated authentication-The system delegates authentication to a standard agent. If this option is enabled, the system tries to determine the FCC URL associated with the protected resource. The system then redirects the user to the FCC URL with the system sign-in URL as the target. Upon successful authentication, the user is redirected back to the system with an SMSESSION cookie and the system does an automatic sign-in for the user.
Authentication Schemes

The Pulse Secure access management framework works with the following types of SiteMinder authentication schemes:

Basic username and password authentication —The user’s name and password are passed to the SiteMinder policy server. The policy server authenticates them to another server for authentication. RSA Authentication Manager SecurID token authentication —The SiteMinder policy server authenticates users based on a username and password generated by an RSA Authentication Manager SecurID token. Client-side certificate authentication —The SiteMinder policy server authenticates users based on their client-side certificate credentials. If you choose this authentication method, the Web browser displays a list of client certificates from which users can select. If you choose to authenticate users with this method, you must import the client certificate through the System Certificates Trusted Client CAs tab.

Interoperability Requirements and Limitations

The following requirements and limitations apply:

The Automatic Sign-in feature is not supported for administrator roles. This feature is only available for end users. If you use the Authenticate using custom agent option, update all other Web agents to accept the device generated cookie, and apply a software patch to all other Web agents. Ivanti Policy Secure ( IPS ) supports SiteMinder server version 6.0, version 5.5, and version 12.0. If you run older agents than the supported agents, you might experience cookie validation problems, including crossed log entries and intermittent user timeouts. You can choose which SiteMinder server version you want to support when you create a server instance. You can choose version 5.5, which supports both versions 5.5 and 6.0, or you can choose version 6.0, which supports only version 6.0, or version 12.0. There is no difference in the SiteMinder authentication server functionality based on which version you select. This option only controls the version of the SDK to use. We recommend you match the compatibility mode with the version of the policy server. When you use SiteMinder to authenticate, the primary and backup policy servers must run the same SiteMinder server software version. A mixed deployment (where the primary server runs a different server software version than the backup) is not supported. SiteMinder does not store the IP address in the SMSESSION cookie, and therefore cannot pass it to the system. SiteMinder sends the SMSESSION cookie to the system as a persistent cookie. To maximize security, the system resets the persistent cookie as a session cookie once authentication is complete. When you use SiteMinder to authenticate, the Pulse Secure access management framework disregards any system session and idle timeouts and uses session and idle timeouts set through the SiteMinder realm instead. When you use SiteMinder to authenticate, users must access the system using a fully qualified domain name. This is because the SiteMinder SMSESSION cookie is only sent for the domain for which it is configured. If users access the system using an IP address, they might receive an authentication failure and will be prompted to authenticate again. You can update all your standard Web agents to the appropriate SiteMinder Agent Quarterly Maintenance Release (QMR) to accept the cookies. If you are running SiteMinder version 5 Web agents, use the QMR5 hot fix. The system is compatible with version 5.x and later SiteMinder agents. Older versions of SiteMinder agents are susceptible to cookie validation failures. You can set the Accept Third Party Cookie attribute (AcceptTPCookie) to yes in the Web agent’s configuration file (webagent.conf) or to 1 in the Windows Registry for the IIS Web server. The location of the attribute depends on the SiteMinder version and Web server you are using. Refer to the documentation provided with your SiteMinder server.

Configuring the Back-End SiteMinder Server

The following sections do not give complete SiteMinder configuration instructions—they are only intended to help you make SiteMinder work with the Pulse Secure access management framework. For in-depth SiteMinder configuration information, refer to the documentation provided with your SiteMinder policy server.

Configuring the SiteMinder Agent

A SiteMinder agent filters user requests to enforce access controls. For instance, when a user requests a protected resource, the agent prompts the user for credentials based on an authentication scheme and sends the credentials to a SiteMinder policy server. A Web agent is simply an agent that works with a Web server. When configuring SiteMinder to work with the Pulse Secure access management framework, you must configure the system as a Web agent in most cases.

If you select the Delegate authentication to a standard agent option, you must set the following options in the agent configuration object of the standard Web agent to host the FCC URL:

EncryptAgentName=no FCCCompatMode=no

To configure the system as a Web agent on the SiteMinder policy server:

In the SiteMinder Administration interface, click the System tab. Right-click Agents and select Create Agent. Enter a name for the Web agent and a description. You must enter this name when creating a SiteMinder realm. Select the Support 5.x agents option for compatibility with the system. Under Agent Type, select SiteMinder and then select Web Agent from the list. This setting is required for compatibility with the system. Under IP Address or Hostname, enter the name or IP address of the system. In the Shared Secret box, enter and confirm a secret for the Web agent. Note that you must enter this secret when configuring the system. Click OK .

Configuring the Authentication Scheme

Within SiteMinder, an authentication scheme is a way to collect user credentials and determine the identity of a user. You may create different authentication schemes and associate different protection levels with each. For example, you may create two schemes—one that authenticates users based solely on the users’ client-side certificates and provides them a low protection level, and a second that uses RSA Authentication Manager SecurID token authentication and provides users a higher protection level.

To configure a SiteMinder authentication scheme:

In the SiteMinder Administration interface, select the System tab. Right-click Authentication Schemes and select Create Authentication Scheme. Enter a name for the scheme and (optionally) a description. You must enter this name when configuring the SiteMinder realm. Under Authentication Scheme, select one of the following options: Basic Template HTML Form Template SecurID HTML Form Template-If you are using SecurID authentication, you must choose SecurID HTML Form Template (instead of SecurID Template). Choosing this option enables the Policy Server to send ACE sign-in failure codes. X509 Client Cert Template X509 Client Cert and Basic Authentication

- You must select HTML Form Template to handle reauthentication.
- If you select X509 Client Cert Template or X509 Client Cert and Basic Authentication, you must import the certificate through System Certificates Trusted Client CAs.

Enter a protection level for the scheme. Note that this protection level carries over to the SiteMinder realm that you associate with this scheme. Select Password Policies Enabled for this Authentication Scheme if you want to reauthenticate users who request resources with a higher protection level than they are authorized to access. Select Scheme Setup tab, and enter the options required by your authentication scheme type. If you want the system to reauthenticate users who request resources with a higher protection level than they are authorized to access, you must enter the following settings: Under Server Name, enter the hostname (for example, sales.yourcompany.net). Select the Use SSL Connection check box. Under Target, enter the sign-in URL defined plus the parameter “ive=1” (for example, /highproturl?ive=1). The system must have a sign-in policy that uses */highproturl as the sign-in URL and only uses the corresponding SiteMinder authentication realm. Clear the Allow Form Authentication Scheme to Save Credentials check box. Leave Additional Attribute List empty. Click OK .

If you change a SiteMinder authentication scheme on the policy server, you must flush the cache using the Flush Cache option on the Advanced tab.

Configuring the SiteMinder Domain

Within SiteMinder, a policy domain is a logical grouping of resources associated with one or more user directories. Policy domains contain realms, responses, and policies. When configuring the Pulse Secure access management framework to work with SiteMinder, you must give user access to a SiteMinder resource within a realm, and then group the realm into a domain.

To configure a SiteMinder domain

Select the System tab, right-click Domains and select Create Domain, or click Domains and select an existing SiteMinder domain. Add a realm to the domain.

Configuring the SiteMinder Realm

Within SiteMinder, a realm is a cluster of resources within a policy domain grouped together according to security requirements. When configuring SiteMinder to work with the Pulse Secure access management framework, you must define realms to determine which resources the users might access.

To configure a SiteMinder Realm:

In the SiteMinder Administration interface, In the SiteMinder Administration interface, select the Domains tab. Expand the domain that you created. Right-click Realms and select Create Realm. In the Agent field, select the Web agent that you created. In the Resource Filter field, enter a protected resource. This resource inherits the protection level specified in the corresponding authentication scheme. For the default protection level, enter /ive-authentication. You must enter this resource when configuring the system. If you use sign-in policies with nondefault URLs such as */nete or */cert, you must have corresponding resource filters in the SiteMinder configuration. From the Authentication Schemes list, select the scheme that you created. Click OK .

Configuring a Rule or Response Pair to Pass Usernames

Within SiteMinder, you can use rules to trigger responses during authentication or authorization. A response passes DN attributes, static text, or customized active responses from the SiteMinder policy server to a SiteMinder agent. When you configure SiteMinder to work with the Pulse Secure access management framework, you must create a rule that triggers when a user successfully authenticates. Then, you must create a corresponding response that passes the user’s username to the system Web agent.

To create a new rule:

Select the Domain tab. Expand the domain that you created and then expand Realms. Right-click the realm that you created and select Create Rule under Realm. Enter a name and (optionally) description for the rule. Under Action, select Authentication Events and then select OnAuthAccept from the drop down list. Select Enabled . Click OK .

To create a new response:

Expand the domain that you created. Right-click Responses and select Create Response. Enter a name and (optionally) a description for the response. Select SiteMinder and then select the Web agent. Click Create. From the Attribute list, select WebAgent-HTTP-Header-Variable. Under Attribute Kind, select Static. Under Variable Name, enter IVEUSERNAME. Under Variable Value, enter a username. Click OK .

Configuring Authentication with a SiteMinder Server

To configure authentication with SiteMinder server:

Select Authentication Auth.Servers . Select SiteMinder Server and click New Server to display the configuration page. Complete the configuration as described in table. Save the configuration. After you have saved the configuration, the page that is redisplayed includes an Advanced tab. Click the Advanced tab to display the configuration page. Complete the configuration as described in table. Save the configuration.

Settings

Guidelines

Name

Specify a name to identify the server within the system.

Policy Server

Specify name or IP address of the policy server.

Backup Server(s)

(Optional) Specify a comma-delimited list of backup policy servers.

Failover Mode?

Select one of the following failover mode options:

Yes–The device uses the main policy server unless it fails. No–The device does the load balancing among all the specified policy servers.

Agent Name

Specify the agent name configured on the policy server.

Secret

Specify the shared secret configured on the policy server. The value is case sensitive.

Compatible with

Select a SiteMinder server version.

5.5 Policy Servers–Supports version 5.5 and version 6.0. This is the default. 6.0 Policy Servers–Supports only version 6.0 of the SiteMinder server API. 12.0 Policy Servers–Supports only version 12.0.

On log out, redirect to

Specify a URL to which users are redirected when they sign out of the device (optional). If you leave this field empty, users see the default sign-in page.

The On log out, redirect to setting is included in the product release for backwards-compatibility. We strongly recommend that you use the customizable sign-in pages feature instead.

Protected Resource

Specify a default protected resource. If you do not create sign-in policies, the system uses this default URL to set the user’s protection level for the session. The system also uses this default URL if you select the Automatic Sign-In option. If your users are signing in to the “*” URL (default device sign-in page), enter any URL (“/ive-authentication” is the default) to set the protection level to the default value. If you do create sign-in policies, the device uses those sign-in policies instead of this default URL.

You must enter a forward slash (/) at the beginning of the resource. For example, enter /local-authentication.

Resource Action

Displays the resource action configured on the back-end SiteMinder server.

Users authenticate using tokens or one-time passwords

Select this option if you want the device to prompt the user for a token instead of a password; that is, if users submit tokens or one-time use passwords to the device.

For example, you can use this option to dynamically prompt for a password or token based on sign-in policies by configuring two instances of the same authentication server. You can use one instance for wireless users who have this option enabled and it prompts the user for a token, and another instance for wired users who have this option disabled and it prompts the user for a password.

Server Catalog

Use the Server Catalog button to display the Server Catalog in a new window. Add the SiteMinder user attributes (such as the cookiename) that you want to use for role mapping.

SMSESSION cookie settings

When sending cookies to the end-user’s browser

Specify the cookie domain for either the end user or the device. A cookie domain is a domain in which the user’s cookies are active. For example, the system sends cookies to the user’s browser in this domain.

Multiple domains should use a leading period and be comma-separated. For example, .sales.myorg.com, .marketing.myorg.com.

Domain names are case-sensitive. You cannot use wildcard characters

-

Select HTTPS to send cookies securely if other Web agents are set up to accept secure cookies, or HTTP to send cookies non securely.

Cookie Domain and Protocol When the Cookie is Set on the Device

Enter the valid Internet domain for the cookie and where the browser of the user sends cookie contents. This cookie domain should be the same as the host domain. For example, .xyz.net

-

Select HTTPS to send cookies securely if other Web agents are set up to accept secure cookies, or HTTP to send cookies non-securely.

SiteMinder authentication settings

Automatic Sign In

Select this option to automatically sign in users with a valid SMSESSION cookie. Then, select the authentication realm to which the users are mapped. If you select this option, note that:

If the protection level associated with a user’s SMSESSION cookie is different from the protection level of the realm, the protection level associated with the cookie is used. This option uses SMSESSION cookie, which is already present in the browser to enable single sign-on. This option provides a single sign-on experience for users. ·This option enables users to sign in using a standard Siteminder Web Agent that generates an SMSESSION cookie. When you select this option, you must also configure the following sub options: ·To assign user roles, use this user authentication realm–Select an authentication realm for automatically signed-in users. The users are mapped to a role based on the role mapping rules defined in the selected realm. ·If Automatic Sign In fails, redirect to–Enter an alternative URL for users who sign in through the automatic sign-In mechanism. The users are redirected to the specified URL if the authentication fails and if there is no redirect response from the SiteMinder policy server. If you leave this field empty, users are prompted to sign back in.

Authenticate using custom agent

Select this option if you want to authenticate using the custom Web agent. Using this option, the system generates the SMSESSION cookie, just like any other Web agent configured within the organization.

Authenticate using HTML form post

Select this option if you want to post user credentials to a standard Web agent that you have already configured rather than contacting the SiteMinder policy server directly.

If you select this option, the Web agent contacts the policy server to determine the appropriate sign-in page to display to the user.

To configure the system to “act like a browser” that posts credentials to the standard Web agent, you must enter the following information.

Target–Specify the target URL. Protocol–Specify the protocol for communication between the system and the specified Web agent. Select HTTP for non-secure communication. Select HTTPS for secure communication.

· Webagent–Specify the name of the Web agent to obtain SMSESSION cookies. An IP address is not allowed for this field. (Specifying the IP address as the Web agent prevents some browsers from accepting cookies.)

Port– Specify the port for the protocol. Enter port 80 for HTTP or port 443 for HTTPS. Path–Specify the path of the Web agent’s sign-in page. The path must start with a backslash (/) character. In the Web agent sign-in page URL, the path appears after the Web agent. Parameters– Specify the post parameters to be sent when a user signs in. Common SiteMinder variables that you can use include _ _USER_ _, _ _PASS_ _, and _ _TARGET_ _. These variables are replaced by the username and password entered by the user on the Web agent’s sign-in page and by the value specified in the Target field. These are the default parameters for log in.fcc—if you have made customizations, you may need to change these parameters.

Delegate authentication to a standard agent

Select this option to delegate authentication to a standard agent. When the user accesses the system sign-in page, the FCC URL associated with the protected resource’s authentication scheme is determined. The system redirects the user to that URL, setting the system sign-in URL as the target. After successfully authenticating with the standard agent, an SMSESSION cookie is set in the user’s browser and the user is redirected back. The system then automatically signs in the user and establishes a session.

You must enable the Automatic Sign-In option to use this feature. If you enable this option and a user already has a valid SMSESSION cookie when trying to access a resource, the system tries to automatically sign in using the existing SMSESSION cookie. If the cookie is invalid, the SMSESSION cookie and corresponding system cookies are cleared and a “timeout” page is displayed. The system successfully delegates authentication when the user clicks the sign back in option. If you select this option, your authentication scheme must have an associated FCC URL .

Settings

Guidelines

Poll Interval (seconds)

Specify the interval at which the system polls the SiteMinder policy server to check for a new key.

Max. Connections

Control the maximum number of simultaneous connections that the system is allowed to make to the policy server. The default setting is 20.

Max. Requests/ Agent

Control the maximum number of requests that the policy server connection handles before the system ends the connection. If necessary, tune to increase performance. The default setting is 1000.

Idle Timeout (minutes)

Control the maximum number of minutes a connection to the policy server may remain idle (the connection is not handling requests) before the system ends the connection. The default setting of “none” indicates no time limit.

Authorize while Authenticating

Specify that the system should look up user attributes on the policy server immediately after authentication to determine if the user is truly authenticated.

For example, if your SiteMinder server authenticates users based on an LDAP server setting, you can select this option to indicate that the system should authenticate users through the SiteMinder server and then authorize them through the LDAP server before granting them access. If the user fails authentication or authorization, the user is redirected to the page configured on the policy server.

Enable Session Grace Period

Eliminate the overhead of verifying a user’s SMSESSION cookie each time the user requests the same resource by indicating that the system should consider the cookie valid for a certain period.

If you do not select this option, the system checks the user’s SMSESSION cookie on each request. Note that the value entered here does not affect session or idle timeout checking.

Validate cookie every N seconds (seconds)

Specify the time for the system to eliminate the overhead of verifying a user’s SMSESSION cookie each time the user requests the same resource by indicating that the system should consider the cookie valid for a certain period.

Ignore Query Data

Specify that the system does not cache the query parameter in its URLs. Therefore, if a user requests the same resource as is specified in the cached URL, the request should not fail.

Accounting Port

Specify that the value entered in this field must match the accounting port value entered through the Policy Server Management Console in the Web UI. By default, this field matches the policy server’s default setting of 44441.

Authentication Port

Specify that the value entered in this field must match the authentication port value entered through the Policy Server Management Console. By default, this field matches the policy server’s default setting of 44442.

Authorization Port

Specifies that the value entered in this field must match the authorization port value entered through the Policy Server Management Console. By default, this field matches the policy server’s default setting of 44443.

Agent Configuration Settings

Overlook Session for Methods

Compare the request method to the methods listed in this parameter. If a match is found, Web Agent does not create a new or update an existing SMSESSION cookie, nor will it make any updates to the cookie provider for that request.

You can enter multiple methods; use a comma to separate method names.

If Overlook Session for Methods parameter is set but not Overlook Session for URLs, then all requests that match the methods defined in this parameter are processed (SMSESSION cookie creation/update is blocked).

If both Overlook Session for Methods and Overlook Session for URLsparameters are set, both the method and the URL of the request are matched before proceeding. Then, all URLs with specified methods are processed (SMSESSION cookie creation/update is blocked).

Overlook Session for URLs

Compare the request URL to the URLs listed in this parameter. If a match is found, Web Agent does not create a new or update an existing SMSESSION cookie, nor will it make any updates to the cookie provider for that request.

Specify a relative URL. For example: If the URL is http://fqdn.host/MyDocuments/index.html, enter /MyDocuments/index.html

If Overlook Session for URLs is set but not Overlook Session for Methods, then all requests, regardless of the methods, matching the URLs defined in this parameter are processed (SMSESSION cookie creation/update is blocked).

If both Overlook Session for Methods and Overlook Session for URLsparameters are defined, both the method and the URL of the request are matched before proceeding. Then, all URLs with specified methods are processed (SMSESSION cookie creation/update is blocked).

SiteMinder caching

Flush Cache

Select this option to delete the resource cache, which caches resource authorization information for 10 minutes.

Displaying the User Accounts Table

To display user accounts:

Click the link for the authentication server you want to manage. Click the Users tab to display the user accounts table.

The user accounts table includes entries for the accounts that have been created. The Last Sign-in Statistic column shows the last successful sign-in date and time for each user, the user’s IP address, and the agent or browser type and version.

Use the controls to search for users and manage user accounts:

To search for a specific user, enter a username in the Show users named box and click Update.

You can use an asterisk (*) as a wildcard, where * represents any number of zero or more characters. For example, to search for all usernames that contain the letters jo, enter *jo*. The search is case-sensitive. To display the entire list of accounts again, type * or delete the field’s contents and click Update.

To limit the number of users displayed on the page, enter a number in the Show N users box and click Update. To terminate the user session and delete the account, select the check box next to the user account record and click Delete .

Was this article useful?

Copyright © 2022 , Ivanti . All rights reserved.

Privacy and Legal




Vestibulum venenatis

Fermentum nibh augue praesent a lacus at urna congue rutrum.

Etiam posuere

Praesent scelerisque

Vivamus fermentum nibh in augue praesent urna congue rutrum.

Etiam posuere

Donec dictum metus

Vivamus fermentum nibh in augue praesent urna congue rutrum.

Etiam posuere

Mauris vulputate dolor

Rutrum fermentum nibh in augue praesent urna congue rutrum.

Etiam posuere