Advanced Password Services (APS) is an add-on component for SiteMinder and requires an existing SiteMinder installation. Some additional configuration of the SiteMinder Policy Server is also required.
Note: Installation Checklists for Solaris and Windows are supplied with the APS Installation kit as separate documents. This section exists for clarity and detail, but those documents break these instructions into concrete steps. You may wish to refer to those documents while reading this chapter.
This section contains the following topics:
Before you install Advanced Password Services, install and configure the following CA SiteMinder components:
Note: For more information about which component versions APS supports, see the Advanced Password Services Support Matrix.
Although a version of the SmTransact library is part of SiteMinder itself, APS requires a later version of this package. This version is included and installed with the APS installation kit.
The service name for the SmPortal.cfg file is smaps (case is significant).
See the chapter entitled SmPortal/SmTransact Installation and Configuration for information about how to configure and troubleshoot these modules.
See the chapter entitled Internationalization & Localization (APSXLate) for information about how to install, configure, and troubleshoot the APSXLate module.
See the instructions on how to configure the APS Mail module.
Note: Any instructions included in the readme or in release notes supercede instructions included here.
r12.5 and 12.51
The Policy Server installer installs the required shared library and all other required APS server files as part of the Policy Server installation.
Follow these steps:
smaps.rename4aps.dll
Specifies the Policy Server installation path.
smaps.dll
Note: The Policy Server installer installed all of the other required APS server files as part Policy Server installation.
r6.x and r12.0.x
Follow these steps:
Specifies the latest version of the zip.
Consider the following:
r12.5 and 12.51
The Policy Server installer installs the required shared library and all other required APS server files as part of the Policy Server installation.
Follow these steps:
libsmaps_rename4aps.so
Specifies the Policy Server installation path.
libsmaps.so
r6.x and r12.0.x
Each kit supplies two installation scripts. One script for the Policy Server–side components and one kit for web–side components. These scripts are supplied in a single file, tarred, and compressed.
The installation program does the following:
siteminder_home/apsinstall_datestamp.log
Follow these steps:
Consider the following:
r12.5 and 12.51
The web agent installer installs the Change Password Interface client component. You do not have to use the APS installation kit to install it.
Follow these steps to complete the installation:
Note: For more information, see the SmPortal/SmTransact Installation and Configuration chapter.
Note: For more information, see your vendor–specific documentation.
r6.x and r12.0.x
Follow these steps:
Specifies the latest version of the zip.
Note: You can install all web–side components at the same time.
Consider the following:
After you complete the installation:
Note: For more information, see the SmPortal/SmTransact Installation and Configuration chapter.
Note: For more information, see your vendor–specific documentation.
r12.5 and 12.51
The web agent installer installs the Change Password Interface client component. You do not have to use the APS installation kit to install it.
Follow these steps to complete the installation:
Note: For more information, see the SmPortal/SmTransact Installation and Configuration chapter.
Note: For more information, see your vendor–specific documentation.
The full path to the SmPortal.cfg file.
The path to the Language directory.
Note: Update LD_LIBRARY_PATH to let SmCPW find the SmPortal library. For more information, see your vendor–specific documentation.
Important! Do not put the definitions in to a user profile. Place them in to a special configuration file that the web server uses.
r6.x and r12.0.x
Each kit supplies two installation scripts. One script for the Policy Server–side components and one kit for web–side components. These scripts are supplied in a single file, tarred, and compressed.
The installation program does the following:
agent_home/cpwinstall_datestamp.log
Follow these steps:
Consider the following:
Example: If you installed the agent in /opt/smuser/ca/webagent, enter the following when prompted:
/opt/smuser/ca
After you complete the installation:
If an SmPortal configuration file existed before the installation, the installer renames it with the date of installation as an extension. The new version is installed in the same directory. Modify the new version by merging changes forward from the old version. Verify that the file references a service named smaps.
Note: For more information, see your vendor–specific documentation.
The full path to the SmPortal.cfg file.
The path to the Language directory.
Note: Update LD_LIBRARY_PATH to let SmCPW find the SmPortal library. For more information, see your vendor–specific documentation.
Important! Do not put the definitions in to a user profile. Place them in to a special configuration file that the web server uses.
r12.5 and 12.51
The web agent installer installs the Forgotten Password Interface client component. You do not have to use the APS installation kit to install it.
Follow these steps to complete the installation:
Note: For more information, see the SmPortal/SmTransact Installation and Configuration chapter.
Note: For more information, see your vendor–specific documentation.
Note: For more information, see the Forgotten Password Interface chapter.
r6.x and r12.0.x
Follow these steps:
Specifies the latest version of the zip.
Note: You can install all web–side components at the same time.
Consider the following:
After you complete the installation:
Note: For more information, see the SmPortal/SmTransact Installation and Configuration chapter.
Note: For more information, see your vendor–specific documentation.
Note: For more information, see the Forgotten Password Interface chapter.
r12.5 and 12.51
The web agent installer installs the Forgotten Password Interface client component. You do not have to use the APS installation kit to install it.
Follow these steps to complete the installation:
Note: For more information, see the SmPortal/SmTransact Installation and Configuration chapter.
Note: For more information, see your vendor–specific documentation.
The full path to the SmPortal.cfg file.
The path to the Language directory.
Note: Update LD_LIBRARY_PATH to let SmCPW find the SmPortal library. For more information, see your vendor–specific documentation.
Important! Do not put the definitions in to a user profile. Place them in to a special configuration file that the web server uses.
Note: For more information, see the Forgotten Password Interface chapter.
r6.x and r12.0.x
Each kit supplies two installation scripts. One script for the Policy Server–side components and one kit for web–side components. These scripts are supplied in a single file, tarred, and compressed.
The installation program does the following:
agent_home/fpsinstall_datestamp.log
Follow these steps:
Consider the following:
Example: If you installed the agent in /opt/smuser/ca/webagent, enter the following when prompted:
/opt/smuser/ca
After you complete the installation:
If an SmPortal configuration file existed before the installation, the installer renames it with the date of installation as an extension. The new version is installed in the same directory. Modify the new version by merging changes forward from the old version. Verify that the file references a service named smaps.
Note: For more information, see your vendor–specific documentation.
The full path to the SmPortal.cfg file.
The path to the Language directory.
Note: Update LD_LIBRARY_PATH to let SmCPW find the SmPortal library. For more information, see your vendor–specific documentation.
Important! Do not put the definitions in to a user profile. Place them in to a special configuration file that the web server uses.
Note: For more information, see the Forgotten Password Interface chapter.
r12.5
The web agent installer installs the Help Desk Interface client component. You do not have to use the APS installation kit to install it.
Follow these steps to complete the installation:
Note: For more information, see the SmPortal/SmTransact Installation and Configuration chapter.
Note: For more information, see your vendor–specific documentation.
r6.x and r12.0.x
Follow these steps:
Specifies the latest version of the zip.
Note: You can install all web–side components at the same time.
Consider the following:
After you complete the installation:
Note: For more information, see the SmPortal/SmTransact Installation and Configuration chapter.
Note: For more information, see your vendor–specific documentation.
r12.5
The web agent installer installs the Help Desk Interface client component. You do not have to use the APS installation kit to install it.
Follow these steps to complete the installation:
Note: For more information, see the SmPortal/SmTransact Installation and Configuration chapter.
Note: For more information, see your vendor–specific documentation.
The full path to the SmPortal.cfg file.
The path to the Language directory.
Note: Update LD_LIBRARY_PATH to let SmCPW find the SmPortal library. For more information, see your vendor–specific documentation.
Important! Do not put the definitions in to a user profile. Place them in to a special configuration file that the web server uses.
r6.x and r12.x
Each kit supplies two installation scripts. One script for the Policy Server–side components and one kit for web–side components. These scripts are supplied in a single file, tarred, and compressed.
The installation program does the following:
agent_home/APSAdmininstall_datestamp.log
Follow these steps:
Consider the following:
Example: If you installed the agent in /opt/smuser/ca/webagent, enter the following when prompted:
/opt/smuser/ca
After you complete the installation:
If an SmPortal configuration file existed before the installation, the installer renames it with the date of installation as an extension. The new version is installed in the same directory. Modify the new version by merging changes forward from the old version. Verify that the file references a service named smaps.
Note: For more information, see your vendor–specific documentation.
The full path to the SmPortal.cfg file.
The path to the Language directory.
Note: Update LD_LIBRARY_PATH to let SmCPW find the SmPortal library. For more information, see your vendor–specific documentation.
Important! Do not put the definitions in to a user profile. Place them in to a special configuration file that the web server uses.
From this point, the installation of this add-on component requires manual steps. After installing DMS, please make a backup of the following eight files (as mentioned in sections 1, 2, and 3 below) before copying them to the directories mentioned.
Note: working-dir is the directory where SiteMinder is installed.
The generic name format of the question property file is: questions_language_country.properties, where language is the LANGUAGE concerned and country is the COUNTRY concerned. For example the name of the property file may look like questions_en_US.properties, where en signifies the language "English" and US signifies the country "USA".
working-dir/DMS/java/questions.jar
After APS Version 2.x, APS no longer uses an existing LDAP attribute to hold all of its data for a given user (the "Blob"). It now stores its data in separate attributes with specific names that need to be added to your LDAP schema. These attributes are described in detail in the chapter entitled User Directories: Schema, Storage and Capabilities.
Version 4.0 of APS requires a new attribute, smapsNextAction, that did not exist in APS 3.0. APSExpire will automatically set this attribute the first time that it is run.
Note: APSExpire, while its performance is greatly enhanced with Version 4, will still take some time to perform the process of initializing smapsNextAction for the entire directory. In your rollout schedule, plan for this additional time. Since the performance enhancements for APSExpire in Version 4 involve the use of smapsNextAction (which is not yet set at this point), do not use timings for this initial APSExpire run for planning for later operations.
The installation kit installs two .conf files to the APS_Docs directory. These files describe, in iPlanet (Netscape) terms, the schema changes required. They can be used (by an iPlanet LDAP Server-savvy administrator) to automate the update to the schema on iPlanet LDAP Version 4.x servers. These files should be appended to the end of the existing slapd.user_at.conf and slapd.user_oc.conf files (be sure to back up the existing files first). After appending the files, restart your LDAP server.
For iPlanet Directory Server version 5.0 (and later), these .conf files cannot be used. Instead, you must use the 56NetegrityAPS.ldif file installed onto the SiteMinder/APS_Docs directory. To use this file, perform the following steps:
These steps only need to be performed on a single Master Directory. The changes will be propagated to other masters and consumers (though the changes will be recorded in subsidiary servers in the 99user.ldif file).
The schema can also be updated manually, using the user interface provided with your LDAP implementation (this will certainly be required for non-LDAP native implementations, such as Active Directories and X.500 implementations). The chapter on the Schema defines each of the required attributes.
It is not sufficient to merely add the new attributes to your schema. You must also make these attributes available for your user objects. This can be done in three different ways.
Your choice of the three options may have serious implications. You should read the next several sections before deciding.
You may be able to use the supplied smaps.user_oc.conf file to create a smapsInfo object class, or modify it to create a new object class with a different name. Use the file as described in the previous section. This will only work for iPlanet (Netscape) directories prior to version 5. Other implementations will require that you perform the object class updates manually. All attributes for the object class should be marked in the schema as optional (as opposed to mandatory).
Just because the schema is updated does not mean that the changes are available for your user entries. The object class that allows the attributes must be part of every user entry in the system. If you have an existing object class that is already referenced by every user entry, then you should add the attributes to that object class.
Something to consider is your user maintenance tool. When creating new user entries, the tool must create new entries with the object class. Failure to do so will prevent APS from working with the new users, since it will be unable to update the user’s entry as required.
Even if your site is not upgrading from a prior version of APS, it will still be necessary to run the APSExpire utility against your existing LDAP directory after updating your schema. APSExpire will update all of the users in your directory, initializing the smapsBaseDate and smapsNextAction attributes.
If your site is using an ODBC (RDBMS) User Directory, you will also need to update the ODBC Queries used by APS to read, add, update and delete information from the directory. The queries are defined in APS Configuration File (APS.CFG).
You must ensure that every new LDAP and ODBC user has access to the new attributes in order for APS to function properly. If you are using some sort of User Administrator Tool, such as Distributed Management Services (DMS2) or CA Identity Manager, you need to ensure two things:
APS is configured using a standard text editor. Configuration settings are stored in a file called APS.cfg. Under Windows NT, this file must be located in the same directory as the SMAPS library (SmAPS.dll, installed under the SiteMinder/Bin directory). Under Solaris, this file is pointed to by an environment variable called APS_SETTINGS. This environment variable points to the file itself, not just the directory containing the file. The configuration file controls all behavior of APS.
Under Solaris, if the APS_SETTINGS environment variable is not set, APS will look for the file at $SMHOME/siteminder/bin/APS.cfg.
If the file does not exist, an error will be logged to the SiteMinder console and default settings will be used. If any parsing errors occur, such errors will be written to a file with the same name as the APS.cfg file, with the date and .LOG appended to the file name. This file will be placed in the same directory with the APS.cfg file. If the process does not have the rights to create this file, no file will be created. If errors are logged to this file, APS will display a warning in the SiteMinder console log identifying that such errors were logged.
The format of the APS configuration file is described, in detail in the chapter APS Configuration File (APS.CFG).
Users may become frustrated attempting to find a new password if they are not presented with all of the criteria that a password must meet ahead of time. It is possible to restrict permissible passwords such that it is extremely difficult or even impossible for users to randomly pick a valid password. For this reason, we do not recommend setting all Advanced Password Service password policy options without care and need.
SmCPW (SmCPW.EXE on Windows) is a CGI program that can be accessed through a Web Server so that end users can request a password change. This program can be installed on any Web-agent protected Web Server. The Web Agent need not be installed on the same Web Server with SmCPW. However, the Web Server upon which SmCPW resides must be protected by a Web Agent. This Web Agent may be plugged in to the local Web Server, may be the Secure Proxy Server or some similar configuration.
SmCPW communicates with the SmAPS library (running on a SiteMinder Policy Server) via the APS API, which uses CA’s SmPortal/SmTransact communications module.
When running under a Web Server, SmCPW runs in two modes: GET and POST, defined by the type of request from the client browser. In GET mode, SmCPW displays a default HTML form for changing the password. In POST mode, SmCPW calls the APS API, passing the data posted by the change password form (either the default form or a custom form). The APS API uses CA’s SmPortal/SmTransact module to communicate with the SmAPS library (running on the SiteMinder Policy Server). SmAPS checks the password and changes it, if allowed. If an error occurs, it will be returned (reversing the same communications path) to SmCPW and a message displayed to the user.
SmCPW can also be run from the command line (not under a Web Server). If run with no arguments (or just switches), SmCPW simulates a GET request from the browser, displaying the default form (command line arguments can be used to specify the language for the default form). Additional command line arguments can be used to simulate a POST operation. This allows a site to automate testing without using a browser.
If a new password is the same as the previous password, or the password is invalid, reused, insecure, or fails to pass APS’s many tests for any other reason, the user is presented with an error message and asked to try a different password. The error message is not a concatenated list of problems; rather, it presents the first encountered problem with the password, such as "New password exceeds maximum length". It is possible that a user will have to try several passwords before finding one that meets all of the criteria.
All text that is displayed by SmCPW is subject to translation using two different APSXlate translation files. SmCPW.lang exists as a file on the Web Server and contains translations for all locally generated messages (including password confirmation) and for text to be displayed on the default form. APS.lang exists on the Policy Server and it contains translations for all messages that can be generated during password validation and update.
By default, SmCPW displays error and confirmation messages in a JavaScript message box (or, for browsers that do not support JavaScript, on a standard HTML page). If the translated message looks like a URL (starts with "http:", "https:", or "/"), SmCPW will redirect the browser to the URL instead of displaying the message.
This URL can have replacement parameters contained within it. SmCPW will process its own argument list as a set of key/value pairs. A target URL is examined for values contained within angle brackets ("<" and ">"). The text between the brackets is used as a key and replaced, along with the angle brackets, with the value associated with the key. Thus, values, including the originally requested URL, or target, can be passed to the page that will display the message.
Specific examples are included later in this section.
When running under a Web Server, the syntax of SmCPW is as follows. Note that APS can and will automatically construct these arguments if the redirection events are properly configured (see The APS Configuration File).
SmCPW{.exe}?
[Optional] [&][DaysLeft=<daysleft>] [&][GraceLogins=<grace logins left>] [&][DaysRemaining=<days remaining>] [&][CancelTo=<cancelURL>] [&][Target=<targetURL>] [&][<additional args>]
The .exe component is required on Windows.
If "Optional" is specified, then the default form displayed by SmCPW will have a "Cancel" button. If the user clicks this button, the browser will be redirected back to the page that invoked the form (or <cancelURL>, if specified). The "Cancel" button is dependent on JavaScript support by the browser. If the Browser does not support JavaScript, a standard hyperlink labeled "Cancel" will be displayed instead.
DAYSLEFT=<daysleft> may be supplied to indicate how long the password has left before it expires. There are two cases:
Example:
The TARGET=<target URL> argument identifies the page to which the user should be directed upon completion of the password change. The <target URL> should be passed in a URL-encoded format to avoid problems with embedded characters.
GRACELOGINS and DAYSREMAINING are used when the password has expired, but a grace period or a number of grace logins is configured. SmCPW will modify its displayed text to communicate these values to the user.
Additional key/value pairs may also be supplied, each set separated from its predecessor by an ampersand ("&"). These key/value pairs will be parsed and saved by SmCPW.
When SmCPW redirects to the next page, either by redirecting the specified target or to a custom message page, these key/value pairs will be used to replace macros in the target of the redirection. The URL is examined for text between angle brackets ("<" and ">"). The text and the angle brackets are replaced by the value associated with the text.
For example, if the SmCPW invocation is:
SmCPW?Target=%2FMyPage%2Easp%3F<lang>&Lang=EN
would be redirected to:
/MyPage.asp?EN
When APS builds the redirection because of an event, it can construct complex URLs with such query strings and can include user attributes in that query string. See the section about Redirections later in this document.
SmCPW must be placed into a directory that is visible to a SiteMinder Web Agent protected Web Server. This directory must have execute privileges (under Microsoft’s Internet Information Server, use the Microsoft Management Console, under Netscape Enterprise Server, modify the obj.conf or magnus.conf file to create a CGI-bin directory). The installation program will usually place this file into a directory called
SiteMinder Web Agent/Bin/Web/CPW.
It is not necessary that the program actually be called SmCPW.EXE (though for troubleshooting purposes, it is desirable that it be so named). You may rename the program (maintaining the .EXE extension on Windows) to anything that you desire. For the remainder of this document, the program will be referred to as SmCPW.
A response attribute may be required to be passed when posting to SmCPW. This attribute explicitly identifies the user changing the password. With normal Web Agent configuration, this response is not needed (versions of APS prior to version 4 required this response). If SmCPW complains that it cannot identify the user, then this response will be required. If this response exists, SmCPW will use it, so it does not hurt to have it set up even when it is not needed.
See your SiteMinder documentation for how to set up Response Attributes. The active expression required is as follows:
<@ lib="smaps" func="SMCPW" param=""" @>
This is set up as a standard HTTP-Variable type of attribute, though you do not specify an attribute name. You must select "Active Expression" as the attribute type, then select the "Manual Entry" page in order to create this Active Response, since there is no variable name.
This attribute is only required on the POST rule for the SmCPW program. The GET rule does not need it.
Custom forms can be written for password changes. They can be written in any language that can display an HTML form. The form must POST to SmCPW and may pass any or all command line arguments to it. If command line arguments are passed, the TARGET=<targetURL> should be passed, so that SmCPW knows where to send the user when the process is complete.
Prior to APS version 2.1, custom forms had to pass their query string on to SmCPW during the posting process. Thus, such custom forms had to be written in some server-side scripting language or as a CGI program. Since version 2.1, this is no longer required; custom forms can be written in "vanilla" HTML, if desired. If SmCPW receives a POST without any query string (the HTML form posts just to SmCPW), it will use its "caller’s" (referrer’s) query string.
SmCPW, when presented with an HTTP GET request, will generate an HTML form so that user may enter password information.
SmCPW need not be used to produce the form. You may provide your own HTML for the form, if special processing is desired.
Any form that you desire can be used, as long as it provides three text fields called "OldPassword", "NewPassword" and "VerifyPassword". The last two must contain identical values. Set up your form to post its data to SmCPW.EXE (or to whatever you have renamed that file).
An easy way to start is to run SmCPW.EXE through a browser and to select "View Source" from the browser’s menu. This will display the raw HTML used by the form. You can save this HTML into a file and modify it as desired.
As an alternative, SmCPW can be run from the command line with no arguments. In this case, the default HTML can be captured to a file and used.
SmCPW also supports a considerable amount of customization on the default form. It uses the SmCPW.lang file to determine all of the text to be displayed on the form. In addition, some keys exist in the language file that are used to inject arbitrary HTML into the default form at various places in the output.
Forgot (Forgot.EXE on Windows NT) is a CGI program that is accessed from a Web interface to drive the FPS process.
FPS requires many forms to be presented to the user. As supplied by CA, FPS does not include these forms, though sample forms are provided in both ASP and JSP. It is up to the site to create the production forms (though CA’s Professional Services can be contracted to produce these forms for you).
Furthermore, the architecture of FPS requires that these pages exist on the same Web Server as the FPS stub (FORGOT), since cookies are used extensively and they will only be visible to the pages served up from the same Web Server. All such forms must be installed on a web server, visible to the user base (inside or outside the DMZ) and must not be protected by SiteMinder (since unauthenticated users will be accessing these pages).
Note: Many sites use cascading style sheets (CSS) to standardize the look and feel of their forms. If cascading style sheets are to be shared with protected pages, they must be unprotected (or aliases or copies made) so that they will be accessible to unauthenticated users.
If a user is asked to authenticate during FPS operation, it is because either the target page itself or one of its components (graphic, frame or style sheet) is protected.
Note: FPS only works the user through the forgotten password process. It does not provide any mechanism for putting forgotten password questions into the user entry in the User Directory. It is up to the site to provide this mechanism. Delegated Management System (DMS) and CA Identity Manager are highly suited for this process. APS includes sample code to do this with DMS2.
APSAdmin (APSAdmin.EXE on Windows NT) is a CGI program that is accessed from a Web interface to provide help desk access to APS data in the users’ entries.
APSAdmin uses the APSAdmin portion of the APS API. It does not access APS in any other way. All APSAdmin functionality can be duplicated by custom code, if desired.
For full details of all customizations possible and the configuration it requires, please refer to the APSAdmin utility chapter in this manual.
SmAPS, the Policy Server component of APS, requires that all User Directories have administrator credentials stored within the policy server database. This is required because APS uses the connection to the User Directory maintained by SiteMinder (for almost all operations). APS needs to be able to write to the User Directory such information as the date of the user’s last login and needs to be able to disable user accounts.
To enter User Directory credentials, edit the properties of the User Directory. Check the box marked "Require Credentials" and then enter the "Administrator" and "Password" values. This set of credentials should have sufficient access to the directory. After applying the changes, you should press the "View Contents" button to test the credentials. If nothing is displayed after pressing the button, then the credentials are incorrect.
For iPlanet/Netscape LDAP directories, CA strongly recommends the use of cn=Directory Manager as the administrator account. This account is hard-coded within iPlanet LDAP servers to bypass all Access Control Information (ACI). If any other account is used, it is possible that an ACI will prevent APS (or SiteMinder, for that matter) from reading or writing an attribute value.
There are implications to using the cn=Directory Administrator account under iPlanet that you should be aware of. Not only does it bypass all internal access controls, but it has unrestricted time and size limits on its server-side process and will be given priority by the Directory Server over all other user requests. APS’ use of the Directory Server is highly optimized and is very resource-economic.
Minimally, two Rules are required for changing passwords (one to GET the form, the other to POST the change) and must be protected in a separate Realm from all other pages on the site. This is easiest to create and maintain by creating a special "Change Password" Policy Domain.
This Realm must not have authentication and authorization events enabled. This prevents the possibility of infinite loops (where the user is redirected while being redirected to the change password page).
There should be two Rules defined within this realm, one to GET the form, the other to POST the change. Even if your site is using the default form produced by SmCPW (thus the GET and POST are the same resource) and though SiteMinder 3.6 (and later) allows multiple actions for a single resource, CA recommends that two separate Rules be created.
There should be a rule (within the Change Password Realm) for the form resource and an action of GET. If you are using the default form supplied with APS, this resource should be set to SmCPW*. If you are using your own form, be sure to append the wildcard to the resource definition so that various query strings can be passed to the page.
A second Rule for SmCPW* should be defined with an action of POST. Even if you are using a custom form, you will use SmCPW* for posting. Be sure to include the wildcard ("*") in the resource definition, so that the query string arguments can be passed.
A response attribute may be required to be passed when posting to SmCPW. This attribute explicitly identifies the user changing the password. With normal Web Agent configuration, this response is not needed (versions of APS prior to version 4 required this response). If SmCPW complains that it cannot identify the user, then this response will be required. If this response exists, SmCPW will use it, so it does not hurt to have it set up even when it is not needed.
See your SiteMinder documentation for how to set up Response Attributes. The active expression required is as follows:
<@ lib="smaps" func="SMCPW" param=""" @>
This is set up as a standard HTTP-Variable type of attribute, though you do not specify an attribute name. You must select "Active Expression" as the attribute type, then select the "Manual Entry" page in order to create this Active Response, since there is no variable name.
This attribute is only required on the POST rule for the SmCPW program. The GET rule does not need it.
Finally, a single Policy must be created. Both Rules should be defined for the Policy and the Response should be assigned only to the POST Rule. All users in all directories should be allowed to access this policy.
No special SiteMinder Policy configuration is required for FPS. However, all pages involved with the FPS process, including both custom pages and the Forgot CGI program itself, must be entirely unprotected by SiteMinder. If cascading style sheets or client-side includes are used, they must be unprotected as well.
The Help Desk Interface (APSAdmin) is designed to be a highly flexible, very secure tool that can be used by your Help Desk personnel to reset passwords and enable/disable user accounts. It also has some more generic user view/update capabilities.
APSAdmin is not intended to replace a full CRM system. It is designed so that it can augment an existing system or to provide limited such functionality.
There are three parts of APSAdmin configuration.
Using the SiteMinder Policy Server User Interface (the Policy GUI), create a new Policy Domain called "APS Help Desk Interface".
Within the new Policy Domain, define a Realm named APSAdmin. This realm should be associated with the Agent or Agent Group corresponding to the Web Server(s) upon which this code was installed, not the APSAdmin agent defined in the SmPortal.cfg file. Be sure to use this agent/agent group for this realm. The Resource Filter is /APSAdmin/. The Authentication Scheme is whatever is appropriate for your site.
Define a Rule within this Realm called Help Desk Interface. The Resource will be APSAdmin*. The Action is GET and POST.
Define a Response called Administrator Credentials. This response needs a single Attribute. This attribute needs to have a type of "WebAgent-HTTP-Header-Variable". Select "Static" as the Attribute Kind. The Variable Name field should be set to "APSAdmin". The Variable Value must contain a SiteMinder Administrator name, followed by a semicolon, followed by that administrator’s password. Note that this is a SiteMinder Policy Server User Interface administrator (the credentials used to log into the SiteMinder Policy Server GUI, not into the Web Site).
Create a Policy called Help Desk Administration. Select those users that should have access to this interface. The "Help Desk" rule defined above should be specified. The "Administrator Credentials" response should be tied to the rule.
The following configuration is required for the redirections supported by APS. These should be set up regardless of which events are set up for APS. Later, if an event is enabled in the configuration file, everything will work properly if this setup was performed initially. None of this setup has any affect on email notification of events.
Every single Realm defined in the Policy Database must have Authentication and Authorization events enabled, except the Change Password realm.
There must be three Rules defined in every Realm, except the Change Password realm.
An OnAuthAccept rule to catch password expiration, password change warnings and other events that occur, even though the user properly authenticates.
An OnAuthReject rule to catch "three strikes you’re out" and other events that occur when SiteMinder accepts, but APS rejects, the user.
An OnAccessAccept rule to process forced password change requests.
Three Rule Groups should be defined in each Policy Domain except the Change Password domain.
Each Rule Group should collect all of the rules within the Policy Domain that are alike. That is, all of the OnAuthAccept rules should be collected together into a single Rule Group, all of the OnAuthReject rules together into a single Rule Group and all of the OnAccessAccept rules into their own Rule Group.
Three Responses must be created in every Policy Domain except the Change Password domain.
The first response, for the OnAuthAccept events, should contain a single Active Attribute. This attribute must be of the type OnAccept-Redirect and invoke the following active attribute:
<@ lib="smaps" func="SmApsRedirect" param="" @>
The second response, for the OnAuthReject events, should contain a single Active Attribute. This attribute must be of the type OnReject-Redirect and invoke the following active attribute:
<@ lib="smaps" func="SmApsRedirect" param="" @>
The third response, for the OnAccessAccept events, should contain a single Active Attribute. This attribute must be of the type OnAccept-Redirect and invoke the following active attribute:
<@ lib="smaps" func="AZRedirect" param="" @>
For all three responses, you can access additional functionality by providing values for the param argument. See the section entitled Redirection for a complete discussion of these options.
Each Policy Domain, except the Change Password domain, will need one additional Policy (in addition to its own). This policy will bind each of the three Rule Groups to the three responses. The Policy should apply to all users.
You will need to install and configure the APS Authentication Scheme if you expect to use:
A complete description of the Authentication Scheme and how to configure it is can be found in the chapter entitled Authentication Scheme.
|
Copyright © 2013 CA.
All rights reserved.
|
|