Previous
Contents
Index
Next
|
| Sun ONE Identity Server Programmer's Guide |
Appendix B Directory Server Concepts
Sun™ One Identity Server uses Sun ONE Directory Server to store its data. Certain features of the LDAP-based Directory Server are also used by Identity Server to help manage the 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 directory server to function, it has been built to work with Sun ONE Directory Server. They are complementary in architecture and design data. Use of the directory, 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 ONE Directory Server documentation.
This appendix explains three Directory Server functions that are used by the Identity Server. Roles are an identity grouping mechanism, access control instructions define a type of permission and class of service are an attribute grouping mechanism. They are more fully defined below. For more specific information on these features, see the Sun ONE Directory Server documentation.
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.
Note
The other Directory Server role types can still be used in a directory deployment; they just can not be managed by Identity Server.
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.
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-3 below, the DN identifies Code Example 12-2 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 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-3 includes this virtual attribute when returned by Directory Server only.
How Identity Server Uses Roles
Identity Server uses roles to apply access control instructions. When first installed, the Identity Server configures access control instructions (ACIs) that define administrator permissions. These ACIs 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 access permissions. For a list of roles created for each Identity Server object configured, see "Access Control Instructions (ACIs)".
Role Creation
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:
If the user has no administrator roles, the User profile page will display. If the user has an administrator role, the console will start the user at the top-most administrator page based on which value is present.
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.
Note
Alternately, an administrator might go to the user profile and add the role to the user.
Displaying The Correct Login Start Page
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.
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".
Access Control Instructions (ACIs)
Access control in Identity Server is implemented using Directory Server roles. Users inherit access permissions based on their role membership and parent organization. Identity Server installs pre-configured administrator roles that define access permissions for administrators; these roles are dynamically created when a group, organization, container or people container object is configured. They are:
Organization Admin
Note
This section refers to ACIs as they are applied to administrative roles only. There are other ACIs which are created and used in Identity Server but do not apply to this topic or to roles.
These default roles, when possessed by a user entry, apply a set of default access control instructions (ACIs) that define read and write access to the entries in the object for which the roles were created. 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 organization entries and read access to all organization entries, respectively.
Defining ACIs
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
ACIs defined using Identity Server for use in administrator-type roles follow a different format than those defined using the 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 these ACIs allow.
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 ONE Directory Server documentation.
Note
If there are duplicate ACIs 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";)
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.
Note
For additional information on the CoS feature, see the Sun ONE Directory Server documentation.
CoS Definition Entry
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.
Note
When possible, definition and template entries should be located at the same level for easier management.
Conflicts and CoS
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 6 "Service Management" or the Sun ONE Directory Server documentation.
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.
Application Schema
If a customer is using an existing application and wants to manage its attributes using the Identity Server console, a LDAP schema is probably defined and has been loaded into the Directory Server. If Directory Server does not already have the existing application's attributes and object classes loaded, then it needs to be updated using the Directory Server console or the ldapmodify command line interface. The schema update needs to be completed before loading the application's created XML service file. Other options for adding or modifying Directory Server schema can be found in the Sun ONE Directory Server documentation or in the Sun ONE Identity Server Installation and Configuration Guide.
Previous Contents Index Next
Copyright 2002 Sun Microsystems, Inc. All rights reserved.
Last Updated December 02, 2002