—indicates that you have run out of persistent search connections (30 by default) from Directory Server.

Note: Persistent searching applies only to the full SDK and J2EE Policy Agents 2.1 only; 2.2 Agents do not establish persistent searches.

Unlike regular directory searches, persistent searches receive notifications from Directory Server when additions, updates, or deletions occur in Directory Server. That way, the caches in the Access Manager and Access Manager SDK instances are kept up to date.

Each Access Manager instance requires four persistent search connections and four connections. J2EE Policy Agents 2.1 requires three connections. Calculate the number of persistent search connections required and add at least 4 to the final result. If the total exceeds the default value of 30, do the following:

1. Increase the number of maximum persistent searches by modifying the attribute nsslapd-maxpsearch in Directory Server's dse.ldif file.
   
   
2. Increase the number of threads that are available to process the persistent searches by updating the searchnsslapd-threadnumber attribute, also in the dse.ldif file.

For details, see the Directory Server documentation.

Tuning the number of maximum threads for Directory Server is a bit tricky; a rule of thumb is approximately 15 threads per CPU. Since each search consumes a thread, to optimize performance, keep the number of maximum persistent searches to a lower limit.

It is also a good idea to correctly tune the maximum number of connections and file descriptors so as to avoid running out of file descriptors. Perform thorough testing but do not test in a production environment. Having too many threads adversely impacts performance and causes troubleshooting problems for Directory Server instances.

Check out Access Manager's amtune script, which tunes configuration parameters.

Q: What happens if I modify the user password through Java Naming and Directory Interface (JNDI) calls?

The caches in the Access Manager layer are synchronized through the LDAP Version 3 Plug-in or, depending on your configuration, the Access Manager SDK with persistent searches to Directory Server. Changes to passwords trigger notifications and an update of the caches. However, the session stays active until the user logs out or until the session is terminated by the administrator.

Q: What is IdRepo and what are its benefits?

IdRepo stands for Access Manager Identity Repository, which, along with the related APIs, was introduced in Access Manager 7.0. The IdRepo framework is a pluggable model in which you can develop plug-ins for data stores. Once you have configured the plug-ins, IdRepo instantiates and executes them for the operations they support.

IdRepo also supports caching of identity attributes by relying on the plug-ins to notify the framework cache of changes in the data store. By default, the IdRepo APIs are in use by all the other components in Access Manager.

IdRepo offers many benefits:

• Independence of data stores — You are no longer required to use only Directory Server for managing users or for evaluating users. role-group memberships.
  
  
• Common identifier — IdRepo accords a universal representation of an identity (user, group, role, or agent) and hence a way to access the identity across multiple data repositories, if required.
  
  
• Improved caching — Caching as supported by IdRepo enhances read performance.
  
  
• Simplicity — IdRepo offers a generic and simpler set of APIs for searching, modifying, and creating memberships and services.
  
  
• Support for other data stores — Out of the box, Access Manager supports the default Directory Server-based plug-in and a generic LDAP Version 3 Plug-in. You can develop custom plug-ins to support other data stores.

Q: What's a realm? Please cite a use case.

An access-control realm is a group of authentication properties and authorization policies that you can associate with a user, a group of users, or a collection of protected resources. Realm-based architecture is an independent tree structure that stores an organization's configuration data that might mimic the organization's directory information tree (DIT).

By default, apart from the user data, Access Manager automatically inserts the Access Manager DIT as a special branch in Directory Server. Realm data resides in a proprietary information tree created by Access Manager within a specified data store.

Access Manager follows a delegation model to manage the organization configuration data of the realm tree. In service management, the concept of storing the organization's configuration data independently of the organization's DIT is known as realm-based configuration support.

As a use case, an enterprise can create an access-control realm to apply policies to a group of related services or servers, for example, a realm that groups all the servers and services that are accessed regularly by the employees in one region. And within that region or realm, the enterprise can perform such grouping in a specific division, such as Human Resources. A policy might state that all Human Resources administrators can access the URL http://HR.example.com/HRadmins/. The enterprise can also add a constraint to the policy, for example, limit access of the URL to only Monday through Friday between 9:00 a.m. and 5:00 p.m.

Q: What is the difference between the Access Manager Client SDK and the full Access Manager SDK?

The Access Manager client SDK supports applications for authentication, SSO, policy evaluation (enforcement of fine-grained policies), and management of user profiles (attributes, roles, and such)—basically, all applications that use identity APIs at runtime.

The Access Manager client SDK is not aimed for applications that manage policies or identities. Compared to the full SDK, it lacks these two capabilities:

• Policy management — Policy management requires a number of plug-ins for the subject, resource, conditions, and such; these plug-ins are not abstracted for the client SDK. For the same reason, the client SDK does not support the server-side policy evaluator com.sun.identity.policy.PolicyEvaluator.
  
  
• Federation and Liberty Alliance — The client SDK does not support Liberty Alliance APIs.

From the deployment standpoint, the client SDK offers the following advantages over the full SDK:

• The client SDK does not require administrator credentials such as amadmin and dsameuser.
  
  
• The client SDK, which uses only the HTTP and HTTPS protocols and communicates with only Access Manager, does not require the serverconfig.xml file and does not use LDAP. As a result, you can deploy applications in DMZs and install a firewall between the applications and the Access Manager server without allowing LDAP access through the firewall.
  
  In addition, the three persistent search connections set up by the full SDK are not required, reducing the load on Directory Server and enhancing its performance. Consequently, the client SDK can support hundreds instead of only tens of applications that are supported by the full SDK.
  
  
• The size of the client SDK of approximately 1 Mbyte is considerably smaller than that of the full SDK, whose size is approximately 10 Mbytes.
  
  
• The client SDK is better suited for deployment of J2EE Web archive (WAR) files and requires only a single Java archive (JAR) file (amclientsdk.jar) and the AMConfig.properties file within the WAR file.

We recommend that you use the client SDK and switch to the full SDK only if the requirements do not match.

Q: How do I configure an LDAP Version 3 data store to point to Directory Server with the Access Manager schema installed?

The Access Manager SDK Directory Server contains a set of predefined schemas as reflected in the XML and schema files, such as amAgent.xml, amUser.xml, and ds_remote_schema.ldif. If you use your own directory server, its schema file must correspond to the predefined schemas specified by Access Manager. Alternatively, you can edit the Access Manager XML and schema files to match the schema file defined in your directory server. With the LDAP Version 3 Repository Plug-in, you can map attribute names between the Access Manager SDK and your directory server. However, this approach might not work if the object classes are not defined in your directory server.

For details, see Chapter 3, Data Stores, in the Sun Java System Access Manager Administration Guide.

Q: How do I configure an LDAP Version 3 data store to point to a newly installed Active Directory Server instance?

Out of the box, Access Manager defines a set of object classes and attributes that are required in Active Directory Server for its management on Access Manager. Alternatively, you can modify Access Manager's object classes and attributes to match those in Active Directory Server. In the Access Manager Administration Console, you can manage users according to Access Manager's predefined object classes and attributes as specified in the XML files. If Active Directory Server does not have the necessary object classes or attributes defined, then any access that involves the missing classes or attributes will fail.

For example, when you create a user on the Administration Console, the Administration Console writes to the Active Directory Server Access Manager's predefined object classes and attributes for that user. If Active Directory Server is not configured with the same classes and attributes, the create operation fails. Nor can you edit the user's information on the Administration Console.

LDAP Version 3 Repository supports mapping of attribute names. That means you can refer to an attribute name as, say, X on Access Manager and Y on Active Directory Server. As a result, you need not define all the Access Manager attributes in Active Directory Server. However, if Access Manager contains more attributes than Active Directory Server, you cannot perform one-to-one mapping; moreover, some Access Manager read-write operations will fail because of missing attributes on Active Directory Server.

For details on the configuration parameters, see Appendix C in the Sun Java System Access Manager Postinstallation Guide. See also Chapter 3, Data Stores in the Sun Java System Access Manager Administration Guide.

Q: How do I configure an LDAP Version 3 data store to point to a newly installed Sun Java System Directory Server instance?

The procedure below assumes that you have installed Directory Server with the default sample data and the example organization directory information tree (DIT). You can select both options during installation. It is also assumed that you did not install Access Manager on Directory Server.

Out of the box, Access Manager defines a set of object classes and attributes that are required in Directory Server for its management on Access Manager. Alternatively, you can modify Access Manager's object classes and attributes to match those in Directory Server. In the Access Manager Administration Console, you can manage users based on Access Manager's predefined object classes and attributes as specified in the XML files. If Directory Server does not have the necessary object classes or attributes defined, then any access that involves the missing classes or attributes will fail.

For example, when you create a user on the Administration Console, the Administration Console writes to Directory Server Access Manager's predefined object classes and attributes for that user. If Directory Server is not configured with the same user object classes and attributes, the create operation fails. Nor can you edit the user's information on the Administration Console.

For details on the Access Manager object classes and attributes, see Appendix A in the Sun Java System Access Manager Postinstallation Guide. See also Chapter 3, Data Stores in the Sun Java System Access Manager Administration Guide.

Back to top