For a list of new features in the Access Manager patch releases, see Access Manager 7 2005Q4 Patch Releases. The initial release of Access Manager 7 2005Q4 included the following new features:
Access Manager 7 2005Q4 includes Realm mode and Legacy mode. Both modes support:
New Access Manager 7 2005Q4 features
Access Manager 6 2005Q1 features, except for these limitations:
When realms are created, the corresponding organizations are not created in Sun Java System Directory Server.
The new Access Manager 7 2005Q4 Console cannot set a Class of Service (CoS) template priority. See New Access Manager Console cannot set the CoS template priorities (6309262).
Identity repositories in Sun Java System Directory Server and other data stores
Legacy mode is required for:
Sun Java System Portal Server
Sun Java System Communications Services servers, including Messaging Server, Calendar Server, Instant Messaging, or Delegated Administrator
Coexistence deployments when Access Manager 6 2005Q1 and Access Manager 7 2005Q4 access the same Directory Server
The Access Manager Console has been redesigned for this release. However, if Access Manager is deployed with Portal Server, Messaging Server, Calendar Server, Instant Messaging, or Delegated Administrator, you must install Access Manager in Legacy mode and use the Access Manager 6 2005Q1 Console:
For more information, see Compatibility Issues.
An Access Manager identity repository contains information pertinent to identities such as users, groups, and roles. You can create and maintain an identity repository using either Access Manager or another provisioning product such as Sun Java System Identity Manager.
In the current release, an identity repository can reside in either Sun Java System Directory Server or Microsoft Active Directory. Access Manager can have read/write access or read-only access to an identity repository.
The Access Manager information tree contains information pertinent to system access. Each Access Manager instance creates and maintains a separate information tree in Sun Java System Directory Server. An Access Manager information tree can have any name (suffix). The Access Manager information tree includes realms (and sub-realms, if needed), as described in the following section.
A realm and any sub-realms are part of the Access Manager information tree and can contain configuration information that defines a set of users and/or groups, how users authenticate, which resources users can access, and the information that is available to applications after users are given access to resources. A realm or sub-realm can also contain other configuration information, including globalization configuration, password reset configuration, session configuration, console configuration, and user preferences. A realm or sub-realm can also be empty.
You can create a realm using either the Access Manager Console or the amadmin CLI utility. For more information refer to the Console online help or the Chapter 14, The amadmin Command Line Tool, in Sun Java System Access Manager 7 2005Q4 Administration Guide.
Access Manager provides a web container independent session failover implementation using Sun Java System Message Queue (Message Queue) as the communications broker and the Berkeley DB by Sleepycat Software, Inc. as the session store database. Access Manager 7 2005Q4 enhancements includes the amsfoconfig script to configure the session failover environment and the amsfo script to start and stop the Message Queue broker and Berkeley DB client.
The session property change notification feature enables Access Manager to send a notification to the specific listeners when a change occurs on a specific session property. This feature takes effect when the “Enable Property Change Notifications” attribute is enabled in the Access Manager administrator Console. For example, in a single sign-on (SSO) environment, one Access Manager session can be shared by multiple applications. When a change occurs on a specific session property defined in the “Notification Properties” list, Access Manager sends a notification to all registered listeners.
The session quota constraints feature allows the Access Manager administrator (amadmin) to set the “Active User Sessions” attribute to limit the maximum number of concurrent sessions allowed for a user. The administrator can set a session quota constraint at the global level for all users or for an entity such as an organization, realm, role, or user that applies only to one or more specific users.
By default, session quota constraints are disabled (OFF), but the administrator can enable them by setting the “Enable Quota Constraints” attribute in the Access Manager administrator Console.
The administrator can also configure the behavior if a user exhausts the session constraint quota by setting the “Resulting Behavior If Session Quota Exhausted” attribute:
DENY_ACCESS. Access Manager rejects the login request for a new session.
DESTROY_OLD_SESSION. Access Manager destroys the next expiring existing session for the same user and allows the new login request to succeed.
The “Exempt Top-Level Admins From Constraint Checking” attribute specifies whether session constraint quotas apply to the administrators who have the “Top-level Admin Role”.
For more information, see Setting Session Quota Constraints in Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide
Access Manager 7 2005Q4 includes the Distributed Authentication UI, which is a remote authentication UI component that provides for secure, distributed authentication across two firewalls in a deployment. Without the Distributed Authentication UI component, the Access Manager service URLs can be exposed to the end users. This exposure can be avoided by using a proxy server; however, a proxy server is not necessarily an acceptable solution for many deployments.
The Distributed Authentication UI component is installed on one or more servers within the non-secure (DMZ) layer of an Access Manager deployment. A Distributed Authentication UI server does not run Access Manager; it exists only to provide the authentication interface to end users through a web browser.
The end user sends an HTTP request to the Distributed Authentication UI, which in turn presents a login page to the user. The Distributed Authentication component then sends the user's request through the second firewall to an Access Manager server, which eliminates the need to open holes in the firewalls between the end users and the Access Manager server.
For more information, see the Technical Note: Using Access Manager Distributed Authentication.
All authentication modules (out of box) are extended to support the sub-schema with Console UI support. Multiple authentication module instances can be created for each module type (module class loaded). For example, for instances with names of ldap1 and ldap2 for an LDAP module type, each instance can point to a different LDAP directory server. Module instances with the same names as their types are supported for backward compatibility. Invocation is:
A separate name space is created under an Organization/Realm, which is a chain of authentication module instances. The same chain can be reused and assigned to an Organization/Realm, Role, or User. The Authentication Service instance equals the Authentication Chain. Invocation is:
In addition to Rules, Subjects, and Conditions, policies can now have personalization attributes (IDResponseProvider). The policy decision sent to the client from the policy evaluation now includes policy-based response personalization attributes in the applicable policies. Two types of personalization attributes are supported:
Static attributes. You define the attribute name and value in the policy.
Dynamic attributes. You list the attribute names in the policies, and values are fetched from the Identity Repository data stores at policy evaluation time.
Policy Enforcement Points (agents) typically forward these attribute values as HTTP Header or Cookies or Request Attributes to the protected application.
Access Manager 7 2005Q4 does not support custom implementations of the Response Provider interface by customers.
Session Property Condition
The session policy condition implementation (SessionPropertyCondition) decides whether a policy is applicable to the request based on values of properties set in a user's Access Manager session. At policy evaluation time, the condition returns “true” only if the user's Access Manager session has every property value defined in the condition. For properties defined with multiple values in the condition, it is sufficient if the user session has at least one value listed for the property in the condition.
The policy subject implementation (Access Manager Identity Subject) allows you to use entries from the configured Identity Repository as policy subject values.
You can export policies in XML format using the amadmin command. The new GetPolices and RealmGetPolicies elements in the amAdmin.dtd file support this feature.
A policy now has a status attribute, which can be set to active or inactive. Inactive policies are ignored during policy evaluation.
Access Manager 7 2005Q4 introduces the “site concept,” which provides centralized configuration management for an Access Manager deployment. When Access Manager is configured as a site, client requests always go through the load balancer, which simplifies the deployment as well as resolves issues such as a firewall between the client and the back-end Access Manager servers.
Access Manager 7 2005Q4 provides bulk federation of user accounts to applications that are outsourced to business partners. Previously, federating accounts between a Service Provider (SP) and an Identity Provider (IDP) required each user to access both the SP and IDP sites, create accounts if not already there, and federate the two accounts through a web link. This process was time consuming. It was not always suitable for a deployment with existing accounts or for a site that acted as an identity provider itself or use one of its partners as an authenticating provider.
For more information, see the Sun Java System Access Manager 7 2005Q4 Federation and SAML Administration Guide.
Access Manager 7 2005Q4 includes several new logging enhancements:
New fields (or columns): The MessageID field contains the message identifier for the logged event. The ContextID field contains the context identifier, which is analogous to a session identifier and applies to all events for a particular user's login session. For a user's specific login session, ContextID will be the same in all log files for logged events.
Logging API. The API includes additions for reading log records, including from a database (DB), when logging to DB is configured. Refer to LogReaderSample.java in the /opt/SUNWam/samples/logging directory, which shows the retrieval of log records from a flat file or DB table repository.
Database tables tend to be larger than flat file logs. Therefore, in a given request, do not retrieve all of the records in a database table, because the quantity of data can consume all of the Access Manager server resources.