Appendix E Directory Server Concepts

Sun Java™ System Identity Server uses Sun Java System Directory Server to store its data. Certain features of the LDAP-based Directory Server are used by Identity Server to help manage its data. This chapter contains information on these Directory Server features and how they are used. It contains the following sections:

Overview

Because Identity Server needs an underlying data store, it has been built to work with Sun Java System Directory Server. They are complementary in architecture and design data. Use of Directory Server, though, may not be exclusive to Identity Server and therefore, needs to be treated as a completely separate deployment. For more information on Directory Server deployment, see the Sun Java System Directory Server documentation.

This appendix explains three Directory Server functions that are used by the Identity Server. A role is an identity grouping mechanism; an access control instruction (ACI) defines rules to allow or deny access to Directory Server data, and class of service is an attribute grouping mechanism.

Roles

Roles are a Directory Server entry mechanism similar to the concept of a group. A group has members; a role has members. A role’s members are LDAP entries that are said to possess the role. The criteria of the role itself is defined as an LDAP entry with attributes, identified by the Distinguished Name (DN) attribute of the entry. Directory Server has a number of different types of roles but Identity Server can only manage one of them: the managed role.

Users can possess one or more roles. For example, a contractor role which has attributes from the Session Service and the URL Policy Agent Service might be created. Thus, when new contractors start, the administrator can assign them this role rather than setting separate attributes in the contractor entry. If the contractor were then to become a full-time employee, the administrator would just re-assign the user a different role.

Managed Roles

With a managed role, membership is defined in each member entry and not in the role definition entry. An attribute which designates membership is placed in each LDAP entry that possesses the role. This is in sharp contrast to a traditional static group which centrally lists the members in the group object entry itself.


Note	The other Directory Server role types can still be used in a directory deployment; they just can not be managed by Identity Server.


Note	By inverting the membership mechanism, the role will scale better than a static group. In addition, the referential integrity of the role is simplified, and the roles of an entry can be easily determined.

An administrator assigns the role to a member entry by adding the nsRoleDN attribute to it. The value of nsRoleDN is the DN of the role definition entry. The following apply to managed roles:

Multiple managed roles can be created for each organization or sub-organization.

A managed role can be enabled with any number of services.

Any user that possesses a role with a service will inherit the service attributes from that role.



Note	All Identity Server roles can only be configured directly under organization or sub-organization entries.

Definition Entry

A role’s definition entry is a LDAP entry in which the role’s characteristic attributes are defined. These attributes are passed onto the member entry. Below is a sample LDAP entry that represents the definition entry of a manager role.

The nsManagedRoleDefinition object class inherits from the LDAPsubentry, nsRoleDefinition and nsSimpleRoleDefinition object classes.

Member Entry

A role’s member entry is a LDAP entry to which the role is applied. An LDAP entry that contains the attribute nsRoleDN and its value DN indicates that the entry has the characteristics defined in the value DN entry. In Code Example 12-2 below, the DN identifies Code Example 12-1 above as the role definition entry: cn=managerrole,dc=siroe,dc=com.

Virtual Attribute

When a member entry that contains the nsRoleDN attribute is returned by a Directory Server search, nsRoleDN will be duplicated as the nsRole attribute in the same entry. nsRole will carry a value of any managed, filtered or nested roles assigned to the user (such as ContainerDefaultTemplateRole). Code Example 12-2 includes this virtual attribute when returned by Directory Server only.

Code Example 12-2 LDAP Member Entry


dn: uid=managerperson,ou=people,dc=siroe,dc=com
objectclass: top
objectclass: person
objectclass: inetorgperson
uid: managerperson
gn: manager
sn: person
nsRoleDN: cn=managerrole,ou=people,dc=siroe,dc=com
nsRole: cn=managerrole,ou=people,dc=siroe,dc=com
nsRole: cn=containerdefaulttemplaterole,ou=people,dc=siroe,dc=com
description: manager person within company

How Identity Server Uses Roles

Identity Server uses roles to apply Access Control Instructions. When first installed, the Identity Server configures ACI that define administrator permissions to directory data. These ACI are then designated in roles (such as Organization Admin Role and Organization Help Desk Admin Role) which, when assigned to a user, define the user’s level of access. For a list of roles created for each Identity Server object configured, see Access Control Instructions.

Role Creation


Note	Managed groups in Identity Server are modeled almost the same as roles. They add an attribute to an LDAP entry to make the entry a member of the dynamic group

When a role is created, it contains the auxiliary LDAP object class iplanet-am-managed-role. This object class, in turn, contains the following allowed attributes:

iplanet-am-role-managed-container-dn contains the DN of the identity-related object that the role was created to manage.

iplanet-am-role-type contains a value used by the Identity Server console for display purposes. After authentication, the console gets the user’s roles and checks this attribute for the correct page to display based on which of the following three values it has:

1 for top-level administrator only.

2 for all other administrators.

3 for user.

Role Location

All roles in an organization are viewed from the organization’s top-level. For example, if an administrator wants to add a user to the administrator role for a people container, the administrator would go to the organization above the people container, look for the role based on the people container’s name, and add the user to the role.

Displaying The Correct Login Start Page


Note	When Identity Server attempts to process two templates that are set to the same priority level, Directory Server arbitrarily picks one of the templates to return. For more information, see the Sun Java System Directory Server documentation.


Note	Alternately, an administrator might go to the user profile and add the role to the user.

The attribute iplanet-am-user-admin-start-dn can be defined for a role or a user; it would override the iplanet-am-role-type attribute by defining an alternate display page URL. Upon a user’s successful authentication:

Identity Server checks the iplanet-am-user-admin-start-dn for the user.

This attribute is contained in the User service. If it is set, the user is started at this point. If not, Identity Server goes to step 2.



Note	The value of iplanet-am-user-admin-start-dn can override the administrator’s start page. For example, if a group administrator has read access to the top-level organization, the default starting page of the top-level organization, taken from iplanet-am-role-type, can be overridden by defining iplanet-am-user-admin-start-dn to display the group’s start page.

Identity Server checks the user for the value of iplanet-am-role-type.

If the attribute defines an administrator-type role, the value of iplanet-am-role-managed-container-dn is retrieved and the highest point in the directory tree is displayed as a starting point. For more information on the iplanet-am-role-type attribute, see Role Creation.



Note	If the attribute has no value, a search from Identity Server root is performed for all container-type objects; the highest object in the directory tree that corresponds to the iplanet-am-role-type value is where the user starts. Although rare, this step is memory-intensive in very large directory trees with many container entries.

Access Control Instructions

Control over access to directory information is implemented in Identity Server using roles. Users inherit access permissions based on their role membership and parent organization. Identity Server installs pre-configured administrator roles that define different levels of permission for administrators to access directory information; these roles are dynamically created when a group, organization, container or people container object is configured. They are:

Organization Admin

Organization Help Desk Admin

Group Admin

Container Admin

Container Help Desk Admin

People Container Admin.



Note	This section refers to ACIs as they are applied to administrative roles only. Policy is another form of access control which are created and used in Identity Server but apply to web resources not Directory Server data.

These default roles, when possessed by a user entry, define that user’s level of access to Directory Server data. For example, when an organization is created, the Identity Server SDK creates an Organization Admin role and an Organization Help Desk Admin role. The permissions are read and write access to all entries in the organization and read access to all entries in the organization, respectively.

Defining ACIs


Note	The Identity Server SDK gets the ACIs from the attribute iplanet-am-admin-console-dynamic-aci-list (defined in the amAdminConsole.xml service file) and sets them in the roles after they have been created.

ACIs are defined in the Identity Server console administration XML service file, amAdminConsole.xml. This file contains two global attributes that define ACIs for use in Identity Server: iplanet-am-admin-console-role-default-acis and iplanet-am-admin-console-dynamic-aci-list.

iplanet-am-admin-console-role-default-acis

This global attribute defines which Access Permissions are displayed in the Create Role screen of the Identity Server console. By default, Organization Admin, Organization Help Desk Admin and No Permissions are displayed. If other default permissions are desired, they must be added to this attribute.

iplanet-am-admin-console-dynamic-aci-list

This global attribute is where all of the defined administrator-type ACIs are stored. For information on how ACIs are structured, see Format of Predefined ACIs.

Format of Predefined ACIs


Note	Because ACIs are stored in the role, changing the default permissions in iplanet-am-admin-console-dynamic-aci-list after a role has been created will not affect it. Only roles created after the modification has been made will be affected.

ACIs defined in Identity Server for use with administrator-type roles follow a different format than those defined using Directory Server. The format of the predefined Identity Server ACI is permissionName | ACI Description | DN:ACI ## DN:ACI ## DN:ACI where:

permissionName—The name of the permission which generally includes the object being controlled and the type of access. For example, Organization Admin is an administrator that controls access to an organization object.

ACI Description—A text description of the access the ACI allows.

DN:ACI—There can be any number of DN:ACI pairs separated by the ## symbols. The SDK will get and set each pair in the entry named by DN. This format also supports tags which can be dynamically substituted when the role is created. Without these tags, the DN and ACI would be hard-coded to specific organizations in the directory tree which would make them unusable as defaults. For example, if there is a default set of ACIs for every Organization Admin, the organization name should not be hard-coded in this role. The supported tags are ROLENAME, ORGANIZATION, GROUPNAME, and PCNAME. These tags are substituted with the DN of the entry when the corresponding entry type is created. See the Default ACIs for examples of ACI formats. Additionally, more complete ACI information can be found in the Sun Java System Directory Server documentation.



Note	If there are duplicate ACI within the default permissions, the SDK will print a debug message.

Default ACIs

Following are the default ACIs installed by Identity Server. They are copied from a Identity Server configuration whose top-level organization is configured as o=isp.

Top Level Admin|Access to all entries|o=isp:aci: (target="ldap:///o=isp")(targetattr="*")(version 3.0; acl "Proxy user rights"; allow (all) roledn = "ldap:///ROLENAME";)

Organization Admin|Read and Write access to all organization entries|o=isp:aci:(target="ldap:///($dn),o=isp")(targetfilter=(!(|(nsroledn=cn=Top Level Admin Role,o=isp)(nsroledn=cn=Top Level Help Desk Admin Role,o=isp))))(targetattr = "*")(version 3.0; acl "Organization Admin Role access allow"; allow (all) roledn = "ldap:///cn=Organization Admin Role,[$dn],o=isp";)##o=isp:aci: (target="ldap:///cn=Organization Admin Role,($dn),o=isp")(targetattr="*")(version 3.0; acl "Organization Admin Role access deny"; deny (write,add,delete,compare,proxy) roledn = "ldap:///cn=Organization Admin Role,($dn),o=isp";)

Organization Help Desk Admin|Read access to all organization entries|ORGANIZATION:aci:(target="ldap:///ORGANIZATION")(targetfilter=(!(|(nsroledn=cn=Top Level Admin Role,o=isp)(nsroledn=cn=Top Level Help Desk Admin Role,o=isp)(nsroledn=cn=Organization Admin Role,ORGANIZATION))))(targetattr = "*") (version 3.0; acl "Organization Help Desk Admin Role access allow"; allow (read,search) roledn = "ldap:///ROLENAME";)##ORGANIZATION:aci: (target="ldap:///ORGANIZATION")(targetfilter=(!(|(nsroledn=cn=Top Level Admin Role,o=isp)(nsroledn=cn=Organization Admin Role,ORGANIZATION))))(targetattr = "userPassword") (version 3.0; acl "Organization Help Desk Admin Role access allow"; allow (write)roledn = "ldap:///ROLENAME";)

Container Admin|Read and Write access to all organizational unit entries|o=isp:aci:(target="ldap:///($dn),o=isp")(targetfilter=(!(|(nsroledn=cn=Top Level Admin Role,o=isp)(nsroledn=cn=Top Level Help Desk Admin Role,o=isp))))(targetattr = "*")(version 3.0; acl "Container Admin Role access allow"; allow (all) roledn = "ldap:///cn=Container Admin Role,[$dn],o=isp";)o=isp:aci: (target="ldap:///cn=Container Admin Role,($dn),o=isp")(targetattr="*")(version 3.0; acl "Container Admin Role access deny"; deny (write,add,delete,compare,proxy) roledn = "ldap:///cn=Container Admin Role,($dn),o=isp";)

Container Help Desk Admin|Read access to all organizational unit entries|ORGANIZATION:aci:(target="ldap:///ORGANIZATION")(targetfilter=(!(|(nsroledn=cn=Top Level Admin Role,o=isp)(nsroledn=cn=Top Level Help Desk Admin Role,o=isp)(nsroledn=cn=Container Admin Role,ORGANIZATION))))(targetattr = "*") (version 3.0; acl "Container Help Desk Admin Role access allow"; allow (read,search) roledn = "ldap:///ROLENAME";)##ORGANIZATION:aci: (target="ldap:///ORGANIZATION")(targetfilter=(!(|(nsroledn=cn=Top Level Admin Role,o=isp)(nsroledn=cn=Container Admin Role,ORGANIZATION))))(targetattr = "userPassword") (version 3.0; acl "Container Help Desk Admin Role access allow"; allow (write) roledn = "ldap:///ROLENAME";)

Group Admin|Read and Write access to all group members|ORGANIZATION:aci:(target="ldap:///GROUPNAME")(targetattr = "*") (version 3.0; acl "Group and people container admin role"; allow (all) roledn = "ldap:///ROLENAME";)##ORGANIZATION:aci: (target="ldap:///ORGANIZATION")(targetfilter=(!(|(!FILTER)(|(nsroledn=cn=Top Level Admin Role,o=isp)(nsroledn=cn=Top Level Help Desk Admin Role,o=isp)(nsroledn=cn=Organization Admin Role,ORGANIZATION)(nsroledn=cn=Container Admin Role,ORGANIZATION)))))(targetattr != "iplanet-am-web-agent-access-allow-list || iplanet-am-web-agent-access-not-enforced-list || iplanet-am-domain-url-access-allow || iplanet-am-web-agent-access-deny-list")(version 3.0;acl "Group admin's right to the members"; allow (read,write,search) roledn = "ldap:///ROLENAME";)

People Container Admin|Read and Write access to all users|ORGANIZATION:aci:(target="ldap:///PCNAME")(targetfilter=(!(|(nsroledn=cn=Top Level Admin Role,o=isp)(nsroledn=cn=Top Level Help Desk Admin Role,o=isp)(nsroledn=cn=Organization Admin Role,ORGANIZATION)(nsroledn=cn=Container Admin Role,ORGANIZATION))))(targetattr != "iplanet-am-web-agent-access-allow-list || iplanet-am-web-agent-access-not-enforced-list || iplanet-am-domain-url-access-allow || iplanet-am-web-agent-access-deny-list") (version 3.0; acl "People container admin role"; allow (all) roledn = "ldap:///ROLENAME";)



Note	Identity Server generates a Top Level Admin and Top Level Help Desk Admin during installation. These roles can not be dynamically generated for any other identity-type objects but the top-level organization.

Class Of Service

Both dynamic and policy attributes use class of service (CoS), a feature of the Directory Server that allows attributes to be created and managed in a single central location, and dynamically added to user entries as the user entry is called. Attribute values are not stored within the entry itself; they are generated by CoS as the entry is sent to the client browser. Dynamic and policy attributes using CoS consist of the following two LDAP entries:

CoS Definition Entry—This entry identifies the type of CoS being used (Classic CoS). It contains all the information, except the attribute values, needed to generate an entry defined with CoS. The scope of the CoS is the entire sub-tree below the parent of the CoS definition entry.

Template Entry—This entry contains a list of the attribute values that are generated when the target entry is displayed. Changes to the attribute values in the Template Entry are automatically applied to all entries within the scope of the CoS.

The CoS Definition entry and the Template entry interact to provide attribute information to their target entries; any entry within the scope of the CoS. Only those services which have dynamic or policy attributes use the Directory Server CoS feature; no other services do.

CoS Definition Entry


Note	For additional information on the CoS feature, see the Sun Java System Directory Server documentation.

CoS definition entries are stored as LDAP subentries under the organization level but can be located anywhere in the DIT. They contain the attributes specific to the type of CoS being defined. These attributes name the virtual CoS attribute, the template DN and, if necessary, the specifier attribute in target entries. By default, the CoS mechanism will not override the value of an existing attribute with the same name as the CoS attribute. The CoS definition entry takes the cosSuperDefinition object class and also inherits from the following object class that specifies the type of CoS:

cosClassicDefinition

The cosClassicDefinition object class determines the attribute and value that will appear with an entry by taking the base DN of the template entry from the cosTemplateDN attribute in the definition entry and combining it with the target entry specifier as defined with the cosSpecifier attribute, also in the definition entry. The value of the cosSpecifier attribute is another LDAP attribute which is found in the target entry; the value of the attribute found in the target entry is appended to the value of cosTemplateDN and the combination is the DN of the template entry. Template DNs for classic CoS must therefore have the following structure cn=specifierValue,baseDN.

CoS Template Entry

CoS Template entries are an instance of the cosTemplate object class. The CoS Template entry contains the value or values of the virtual attributes that will be generated by the CoS mechanism and displayed as an attribute of the target entry. The template entries are stored under the definition entries.

Conflicts and CoS


Note	When possible, definition and template entries should be located at the same level for easier management.

There is the possibility that more than one CoS can be assigned to a role or organization, thus creating conflict. When this happens, Identity Server will display either the attribute value based on a pre-determined template priority level or the aggregate of all attribute values defined in the cosPriority attribute. For example, an administrator could create and load multiple services, register them to an organization, create separate roles within the organization and assign multiple roles to a particular user. When Identity Server retrieves this user entry, it sees the CoS object classes, and adds the virtual attributes. If there are any priority conflicts, it will look at the cosPriority attribute for a priority level and return the information with the lowest priority number (which is the highest priority level). For more information on CoS priorities, see cosQualifier Attribute of Chapter 7, "Service Management" or the Sun Java System Directory Server documentation.

Previous Contents Index Next
Sun Java System Identity Server 2004Q2 Developer's Guide


Note	Conflict resolution is decided by the Directory Server before the entry is returned to Identity Server. Identity Server allows only the definition of the priority level and CoS type.