This document contains the release notes for AssureAccess 3.0.16. This release replaces all previous versions of AssureAccess.
AssureAccess 3.0.16.3446 introduces a new feature that is not backwards compatible with earlier versions. Refer to here for more information.
This patch release introduces support for Apache 2.2 on Solaris and Linux.
None.
Patch 16 introduces a backwards incompatibility with earlier releases. In order to support Active Directory logins using the User Principal Name (names of the form 'user@domain') through the LDAP Authentication Provider, support for a new user filter type was added to the implementation. Earlier versions of AssureAccess do not support this new type, and therefore, if the new filter type is configured into an LDAP Authentication Provider AND servers still reside in the domain older than 3.0.16.9446, the servers will fail with an exception in LDAPAuthProvider during initialization. So long as you do NOT configure an LDAP Authentication Provider with the new User by User Principal Name user filter, versions of AssureAccess server components older than 3.0.16.9446 will continue to function.
A problem with the creation of multiple RMI registries within a single JVM in Java 1.4 has been addressed by permitting the use of existing RMI registries. This allows the use of already-existing RMI Registries by AssureAccess adapters that might share a JVM with other libraries and applications that use RMI.
The fix adds an attempt to open an existing RMI registry at the specified port before calling the Java API to create a new RMI registry at the same port. By making this change, an RMI registry already created on the port by another application or by the invocation of the rmiregistry command will be used by AssureAccess instead requiring exclusive access to the port by AssureAccess.
A new implementation of the IIS ISAPI filter has been developed to address problems reported by users of IIS 6.0. The previous filter that had functioned well in IIS 3, 4 and 5 started to exhibit problems in IIS6 in some installations. The cause of the problems was that the IIS filter was unable to invoke a Java Virtual Machine in-process in order to access the Java-based functions of AssureAccess.
The new implementation of the IIS filter shares the Web Daemon used to support the Apache web server, communicating with that process via a named pipe. The Web Daemon (webd) is installed as either a manually invoked program or as a Windows Service and provides the vast majority of the AssureAccess functions and features in a common program. The IIS Filter now contains only those features and functions necessary to support the information needs of the webd and to permit the webd to control the flow of processing of web requests by IIS. A side effect of this new implementation is that IIS can now support SAML processing.
Please be sure to disable the security software on your system while installing or removing AssureAccess on Windows platforms. These operations involve the addition and/or removal of Services that antivirus and antispyware programs typically interfere with. Several customers have reported problems because of this issue. Once the installation or removal is complete, you can enable your security software once again.
Additional information on properly configuring configuring Apache 2.0 and 2.2 - including how to patch your Apache distribution for a problem with returning cookies on a 304 status code - is being added to the installation and configuration documentation in the next release. For your convenience, we are providing the current version of this information as part of this patch. It can be accessed here.
Information is provided below on how to configure the new SAML Attribute Filter feature.
Many installations prefer to run the web server with a non-root identity. Information on how to configure the IPlanet/SunOne web server and AssureAccess to run as Nobody can be found here.
The Custom Headers feature for the Apache Web Adapter has been extended to be on parity with that provided by the other web adapters. For details on configuring the use of custom headers on Apache, go here.
The LDAP Authentication Provider has been enhanced to provide better support for the Microsoft Active Directory Server. A new user filter - User By User Principal Name - supports authentication using the "user@domain" format user name and Active Directory password. This permits the use of the more familiar Microsoft user account name rather than using the Common Name value.
The new IIS Filter implementation adds support for SAML. New properties have been added to the web.properties file in order to configure IIS as either a SAML source site or a SAML destination site. As the vast majority of the functionality is in the common Web Daemon process (shared between Apache and IIS), all the functionality previously unique to the Apache server is now shared by the IIS server. Documentation on how to configure the IIS server to support SAML can be found in Appendix B.
When AssureAccess domains must cross one or more network barriers (firewalls), it is often desireable to require stronger protections on the communications between the separated components. Firewall requirements can also make it difficult to properly identify and properly configure the ports required to support AssureAccess installations. In order to better support installations in these environments, AssureAccess now supports running the Attribute Authority and Audit servers in Proxy mode. In addition, a new server - the LDAP Proxy Server - is now available to be installed. In firewall situations, the new servers greatly reduce the complexity of configuring the firewalls in order to support the transit of traffic necessary to support AssureAccess operation. Configuration information for these new services can be found in a Technical Note available from Entegrity.
Support for the Apache 2.2 http server has been added for Linux and Solaris, and full configuration support for all versions of Apache (1.3, 2.0, and 2.2) is now available. Manual configuration of Apache 1.3 servers is no longer necessary - the configuration tool and the localconfig tool both can configure all three versions of the Apache httpd server.
The watchdog program logs information to the system log
that permits operators and administrators the ability to monitor and
troubleshoot the execution of the AssureAccess daemons. It also
starts the daemons in a manner that isolates them from the invoking
process, preventing unexpected terminations - especially when rc.aa
is invoked from a shell. Finally, should the AssureAccess daemon
terminate unexpectedly, the watchdog program will
restart the daemon automatically. Watchdog logs all
significant events to the system log as a Daemon facility. The
termination of watchdog itself and/or the monitored
process is logged at at least the warning level, and several other
events are logged at the information level. As much information as
available is included in the log messages to indicate why the
monitored process(es) terminated.
For UNIX platforms, a script - rc.aa - is provided to
facilitate startup, monitoring and shutdown of the AssureAccess
daemons installed on the host. When run from the command line,
however, earlier versions did not provide for separating the server
processes from the session and process group of the shell from which
the command was executed, and so the daemons would terminate when the
user logged out or closed the shell. Also, as the AssureAccess
daemons are pure Java programs and use only the standard Java
classes, they do not handle UNIX signals themselves, and so when they
were terminated no record of the reason why they terminated could be
created.
This patch release introduces the use of the watchdog
program to start and monitor the AssureAccess daemons. It is invoked
with the path of the desired program and any arguments to be provided
to that program upon execution. When watchdog is
executed, it:
wait() call is logged using the
syslog() call to the system log. The daemon program is
then restarted. If the child process terminates a large number of
times, watchdog will stop restarting the child process,
log the termination of itself, and exit.
Should watchdog itself receive any of the above-listed
terminating signals, it will log the event to the system log, send a
TERM signal to all the processes in its' process group, and then exit
itself. This will cause the termination of the daemon process as
well.
The product will now install, configure, and protect the combination of the Sun JES Web Server 6.1 and the Sun JES Directory Server 5.2 on a Sun Solaris 10 system. The environment used as the basis for porting and testing are current as of the Q305 Release. Although not yet fully tested, we believe that these JES components will be supported on any UltraSparc platform running Solaris 8, 9, or 10. Testing on the earlier versions of Solaris will be completed for a follow-on release.
A number of improvements have been made to the Artifact Consumer Servlet in order to provide improved support for the requirements of the U.S. Government E-Authentication program. These improvements include the ability to provide detailed error messages in the authentication denied redirection messages, to specify Agency Application IDs and Assurrance Level requirements, and other E-Auth specific capabilities. The exact set of features are included in a separate document that is available upon request.
The product will now support WebLogic Server (WLS) version 8. Installation and configuration is nearly identical to that for WebLogic Server version 7 described by the 3.0 documentation. A new selection has been added to the J2EE configuration menus in the main configuration program and in the localconfig program to permit the specification of WLS version 8 server. Other that selecting version 8 instead of version 7, all other aspects of configuring AssureAccess to work with WLS version 8 are identical to those for WLS version 7.
The product is now supported on the Windows Server 2003 operating system. In addition, the product will install and operate on the Windows XP operating system, however this capability is provided for evaluation purposes only, and is neither intended or supported for production use.
The AssureAccess IIS ISAPI filter module has been ported to work on the IIS 6 server, with the limitation that the IIS server must be set to operate in IIS 5.0 Isolation Mode.
We are investigating the possibility of modifying the implementation in the next release of AssureAccess to eliminate this limitation.
The Apache 2.0 Web Server is now supported by AssureAccess on Solaris 7, 8, 9 & 10.
Limited support for the Apache 1.3 Web Server is now provided by AssureAccess on all supported versions of Solaris and Red Hat Linux. The sole limitation of this implementation is that the AssureAccess localcfg and installer configuration tools have not been modified to configure the AssureAccess Dynamic Shared Object (DSO) into the Apache Web Server configuration file. The filter is otherwise fully functional. Instructions for configuring the DSO into the Apache configuration file are provided below.
AssureAccess has been qualified to run on all versions of Red Hat Linux after version 7 up to the present. In addition, we are currently unaware of any issues with installing and operating AssureAccess components on ANY version of Linux, although we have only qualified the product on the specified versions.
AssureAccess has been qualified to run on Solaris 9, in addition to versions 7 and 8.
AssureAccess have been qualified to run on IBM JVMs of version 1.4.2 or later. Remember that you must download and install the "Unlimited Strength Cryptography Policy" files FROM IBM and install them into the IBM JVM file tree in order for AssureAccess to operate properly. Do NOT try to use the Sun version of the policy files - they will not work.
The Custom Headers feature for the Apache Web Adapter has been extended to be on parity with that provided by the other web adapters. For details on configuring the use of custom headers on Apache, go here.
The improved support for Active Directory requires a new user filter type that is not understood by older versions of AssureAccess. Therefore, if you you intend to utilise the "Users by User Principal Name" user filter, you must ensure that ALL Authentication, Audit, and Management Console Servers have been upgraded to 3.0.16 before configuring the LDAP Adapter. Older versions of these servers will generate exceptions and possible fail upon encountering a configuration record that incorporates the new user filter.
The following is a list of the problems fixed in AssureAccess in version 3.0.1-3.0.16.
This issue is reference number 603.
Several customers have reported problems installing AssureAccess on systems that have antivirus and/or antispyware programs running. AssureAccess installation and removal usually involves the manipulation of Windows Services, an area usually protected by these types of systems. In order to ensure the proper installation and removal of AssureAccess on Windows systems, please disable your antivirus and other security programs for the duration of the process. Once you have installed or removed Assureaccess, you can enable your security software again.
In response to a customer request, we have added the capability for administrators to filter the list of user attributes to be included in an outgoing SAML response. The administrator can specify attributes NOT to be included in the SAML response by adding them to the property
com.entegrity.saml.ignoreAttrs
in the saml.properties file, which can be found in the config subdirectory of the AssureAccess installation directory. The delimiter to be used attributes in this list is, by default, a comma, but a different one can be specified in the
com.entegrity.saml.ignoreAttrsDelim
property in the same file. Note that user attributes identified in this list will never be returned to the requestor, even if they are requested.
There is only one ignoreAttrs property per AssureAccess installation, thus the property applies for all domains protected by the server, and there is no current capability to specify this property on a per-domain basis.
According to the SAML specification, if an Artifact Consumer is configured to use SSL to communicate with a particular SAML Responder, then the Artifact Consumer should require that all requests that it receives for that responder be transmitted via SSL as well. This does not support cases where an external system is being used as the SSL endpoint at a destination site.
In order to support these cases, the administrator can add the ExternalSSL init-param to the web.xml file for the Artifact Consumer, setting it to a value of "True" or "true". For example:
... <init-param> <param-name>ExternalSSL</param-name> <param-value>True</param-value> </init-param> ...
This value is assumed to be false if it is not specified or if the value is not "True".
Many installations prefer to run the web server with a non-root identity. Information on how to configure the IPlanet/SunOne web server and AssureAccess to run as Nobody can be found here.
The Custom Header feature in the Apache Web Adapter has been improved to provide additional support for inserting either attributes from the user's Attribute Certificate OR the basic authentication user name into the request for consumption by backend applications or scripts. This feature, documented in section 3.8 in the Local Configuration Guide and section 3.4.7 in the Administration and Configuration Guide, now behaves almost identically to the features provided for the other web adapters. The only difference is that the properties are in the j2ee.properties file, as opposed to the web.properties file, and that the property names have a different prefix.
This property allows you to specify an attribute whose value you want backend applications or scripts to obtain from a custom header. This capability is often useful if you are using AssureAccess as one product in a chain of applications or processes that need to receive and process an HTTP request. These applications or processes might be legacy systems, applications, and so on that perform authentication or any other function according to a value contained in a custom header in the HTTP request.
To do this, you must first ensure that the AssureAccess filter module is invoked before the module(s)/filters used by your applications. Once that is done, you can configure AssureAccess to add a custom header that the legacy system can subsequently use. The custom header value can set to that of any user attribute contained in the user's AssureAccess attribute certificate (AC). After AssureAccess has finished processing the HTTP request and passes it along to the other downstream systems, that custom header and its value are available to them.
| Configuration File | Example |
| j2ee.properties |
com.entegrity.assureaccess.j2ee.attr.<hdr_name>=<attr_name>
where |
This configuration setting extracts the value of the User attribute from the user's Attribute Certificate and adds it to the HTTP request.
| Configuration File | Example |
| j2ee.properties |
com.entegrity.assureaccess.j2ee.userheader=<value> where<value> is the name of the custom header |
This property adds a user's Basic Authentication username to the HTTP request. The username is taken from the Basic Authentication header and set in REMOTE_USER header. Note that this value can only be provided if the Basic Authentication header is present.
| Configuration File | Example |
|
j2ee.properties |
com.entegrity.assureaccess.j2ee.add=REMOTE_USER |
The table describing the property used to configure the Basic Authentication Username (Section 3.9, Page 43 of the Local Configuration Guide, Section 3.4.8 of the Administration and Configuration Guide) incorrectly identifies the properties file the property resides in. This should read "web.properties" instead of "clientserver.properties."
When using Basic Authentication, the J2EE Adapter does not support Inactivity Timeout. The problem is that once a user logs in with Basic Authentication, the browser continues to send the username/password with each request to the target server. When the user's authentication is revoked due to inactivity, the existing username/password pair automatically allows the user to re-authenticate without the user even knowing that he/she was logged out and without requiring the user to provide the credentials again.
AssureAccess currently supports the Internet Information Service through the use of an ISAPI filter. For various reasons, this filter requires access to the IIS READ_RAW_DATA event in order to perform various functions.
Starting with IIS 6, IIS supports two modes of operation - the worker process isolation mode and the IIS 5.0 isolation mode. The default is the new worker process isolation mode. Unfortunately, when in this mode filters in the individual processes do not have access to the READ_RAW_DATA event, and so the current AssureAccess implementation will not function correctly.
As a result, users MUST put the IIS 6 server into IIS 5.0 Isolation Mode before attempting to use AssureAccess 3.0.9 and later to protect IIS 6 resources. This can be done by checking the "Run WWW Service in IIS 5.0 isolation mode" checkbox in the Services tab of the Web Sites properties box in the IIS Manager, or by setting the LM\W3SVC\IIs5IsolationModeEnabled property to 1 in the IIS Metabase using the Metabase Editor.
The IIS 6 server modes are mutually exclusive. Users should read and understand the IIS documentation regarding this subject, and the documentation for other filters they have installed to determine any dependencies they may have regarding the IIS mode.
We will investigate the possibility of re-implementing our IIS filter or providing a new IIS extension to support IIS 6 worker process isolation mode in the next major release.
AssureAccess provides the capability for administrators so specify that user attribute information be inserted into request headers. This can be used to make user attribute information easily available to applications downstream. Because the user must successfully authenticate before this information can be included, however, the user header information will NOT be included until the client is successfully authenticated by the IIS server. Because of limitations imposed by IIS and how client certificates are processed, no headers may be present in the first request to the server. Refreshing the browser in the same session, or moving to a new page, will generate a new request which will then have the expected headers added to it.
Mailing Address: Entegrity Solutions, 410 Amherst Street, Suite
150, Nashua, NH 03063
Email: support@entegrity.com
Telephone: 603.882.1306
Fax: 603.882.6092
Website: support.entegrity.com
Copyright © 2003-2004 Entegrity Solutions Corporation & its
subsidiaries
Entegrity Solutions Corporation, 410 Amherst Street, Suite 150, Nashua,
NH 03063 U. S. A.
All Rights Reserved.
THIS DOCUMENT AND THE SOFTWARE DESCRIBED HEREIN ARE FURNISHED UNDER A LICENSE, AND MAY BE USED AND COPIED ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE AND WITH THE INCLUSION OF THE COPYRIGHT NOTICE BELOW. TITLE TO AND OWNERSHIP OF THE DOCUMENT AND SOFTWARE REMAIN WITH ENTEGRITY SOLUTIONS CORPORATION OR ITS LICENSEES.
ENTEGRITY SOLUTIONS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
The information contained in this document is subject to change without notice.
Entegrity Solutions shall not be liable for errors contained herein, or for any direct or indirect, incidental, special or consequential damages in connection with the furnishing, performance, or use of this material.
Use, duplication or disclosure by the Government is subject to restrictions as set forth in subparagraph (c) (1) (i) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013.
Entegrity is a registered trademark and AssureAccess is a trademark of Entegrity Solutions Corporation.
WebLogic Server is a trademark of BEA Systems, Inc. iPlanet, Netscape, and Netscape Navigator are trademarks of Netscape Communications Corporation. CORBA is a trademark of The Object Management Group. Microsoft, Windows, Windows NT, Windows 2000, Internet Information Server, Active Directory, and Internet Explorer are registered trademarks of Microsoft Corporation. Java, JavaBeans, JavaServer, JavaServer Pages, JSP, JavaScript, JavaSoft, Javahelp, JDK, Enterprise Java Beans, EJB, RMI, JNI, JNDI, JDBC, and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
Other products and company names referenced in this document are trademarks or registered trademarks of their respective owners.