An access control realm is a group of authentication properties and authorization policies you can associate with a user or group of users. Realm data is stored in a proprietary information tree that Access Manager creates within a data store you specify. The Access Manager framework aggregates policies and properties contained in each realm within the Access Manager information tree. By default, Access Manager automatically inserts the Access Manager information tree as a special branch in Sun Java Enterprise System Directory Server, apart from the user data. You can use access control realms while using any LDAPv3 database.
For more information on realms, see the Sun Java System Access Manager 7.1 Technical Overview.
In the Realms tab, you can configure the following properties for access control:
This section describes how to create and manage realms.
Select New from the Realms list under the Access Control tab.
Define the following general attributes:
Enter a name for the Realm.
Defines the location of the realm that you are creating. Select the parent realm under which the new realm will exist.
Define the following realm attributes:
Choose a status of active or inactive. The default is active. This can be changed at any time during the life of the realm by selecting the Properties icon. Choosing inactive disables user access when logging in.
Allows you to add alias names for the DNS name for the realm. This attribute only accepts “real” domain aliases (random strings are not allowed).
Click OK to save or Cancel to return to the previous page.
The General Properties page displays the basic attributes for a realm. To modify these properties, click the realm from the Realm Names list under the Access Control tab. Then, edit the following properties:
Choose a status of active or inactive. The default is active. This can be changed at any time during the life of the realm by selecting the Properties icon. Choosing inactive disables user access when logging in.
Allows you to add alias names for the DNS name for the realm. This attribute only accepts “real” domain aliases (random strings are not allowed).
Once you edit the properties, click Save.
The recursive=true flag in the AMAdmin.dtd does not work for searching for objects in sub-realms in realm mode. This flag only works in legacy mode because all sub-organizations are located under the same root suffix. In realm mode, each sub-realm can have a different root suffix and may even be located on a different server. If searching for objects, such as groups, in a sub-realm, you must specify the sub-realm in which you are searching in the XML data file.
The general authentication service must be registered as a service to a realm before any user can log in using the other authentication modules. The core authentication service allows the Access Manager administrator to define default values for a realm's authentication parameters. These values can then be used if no overriding value is defined in the specified authentication module. The default values for the Core Authentication Service are defined in the amAuth.xml file and stored in Directory Server after installation.
For more information, see Managing Authentication
In Access Manager, a service is a group of attributes that are managed together by the Access Manager console. The attributes can be just bits of related information such as an employee's name, job title, and email address. But attributes are typically used as configuration parameters for a software module such as a mail application or payroll service.
Through the Services tab, you can add and configure a number of Access Manager default services to a realm. You can add the following services:
Administration
Discovery Service
Globalization Settings
Password Reset
Session
User
Access Manager enforces that required attributes in service .xml files have some default values. If you have services with required attributes with no values, you need to add default values and reload the service.
Click the name of the realm for which you wish to add a new service.
Select the Services tab.
Click Add in the Services list.
Select the service you wish to add for the realm.
Click Next.
Configure the service by defining the realm attributes. See Configuration in the online help for a description of the service attributes.
Click Finish.
To edit the properties of a service, click the name in the Service list.
The delegation model in Access Manager is based on privileges (or entitlements) that have been assigned to the administrators. A privilege is an operation (or action) that can be performed on a resource; for example, a READ operation on Policy objects. The set of operations that are defined are READ, MODIFY and DELEGATE. The resources are objects on which the actions can be performed, and can be either a configuration object or an identity object.
Examples of configuration objects are Authentication Configuration, Policies, Data Stores, and so forth. Examples of identity objects are Users, Groups, Roles, and Agents. A set of privileges can be dynamically created and added to Access Manager dynamically, however during installation, a small set of privileges are added to get Access Manager to properly run. Once the privileges are loaded, the privileges can be assigned to roles and groups. Users belonging to these roles and groups would be the delegated administrators and would be able to perform the assigned operations. Basically, administrators are users who are members of roles and groups to which a set of one or more privileges are assigned.
Access Manager 7.1 allows you to configure permissions for the following administrator types:
Realm administrators — Realm administrators have all the permissions for READ, MODIFY and DELEGATE operations for all objects (both configuration and identity objects). Realm administrators can be considered as “root” within a Unix system. Realm administrators can create sub-realms, modify configurations for all the services and also create, modify and delete Users, Groups, Roles and Agents.
Policy administrators — Policy administrators have permissions to manage policies and policy service configurations only. They can create, modify and delete policies which consists of Rules, Subjects, Conditions and Response Attributes. However in order to manage policies, these administrators need read permissions for Identity Repository Subjects and also Authentication configuration. These administrators are able to view the identities and authentication configurations.
Log administrators — Log administrators have permissions to read and/or write log records which can be used to protect the audit logs from being maliciously abused by rouge applications. Since logging interfaces are public, it is possible that any authenticated user can read and write logs records, and this privilege is added to prevent such abuse. The main users of logging interfaces are J2EE and Web Agents and these require only MODIFY privilege, and should not have READ privilege. Similarly, administrators who view the logs should have only READ privilege, and should not have MODIFY privilege. In order to cater for the these types of usages, the logging privileges are further sub-divided as follows:
Log administrators with Write Access – These administrators have permissions to write all log files.
Log administrators with Read Access – These administrators have permissions to read all log files.
Log administrators with Read and Write Access – These administrators have permissions to read and write to all log files.
A new installation instance of Access Manager 7.1 provides access permissions for policy administrators, realm administrators (or organization administrators in Legacy mode) and Log Administrators. To assign or modify privileges, click the name of the role or group you wish to edit. You can select from the following:
Defines both read and write access privileges to log administrators.
Defines only write access privileges to log administrators.
Defines only read access privileges to log administrators.
Defines read and write access privileges for policy administrators.
Defines read and write access privileges for realm administrators.
If you have upgraded Access Manager from version 7.0 to 7.1, the privilege configuration differs from that of a new Access Manager 7.1 installation, however privileges for policy administrators, realm administrators and log administrators are still supported. To assign or modify privileges, click the name of the role or group you wish to edit. You can select from the following:
Defines read access privileges to datastores for policy administrators.
Defines both read and write access privileges for log administrators.
Defines only write access privileges for log administrators.
Defines only read access privileges for log administrators.
Defines read and write access privileges for policy administrators.
Defines read and write access privileges for realm administrators.
Defines read access privileges to all properties and services for policy administrators.
Access Manager does not support the following definitions used either separately or together:
Read only access to data stores
Read only access to all properties and services
These privilege definitions must be used with the “Read and write access only for policy properties” definition to define delegation control for policy administrators.