Roles are used as an alternate of static groups. A role is a multivalued virtual attribute (named “nsrole”), generated in each entry. The values are the DN of the roles that the entry is member of. A limitation of the application using the role mechanism is that the scope of a role is the subtree where the role is defined. For example, a role cn=role_rhds_dev,ou=engineering,dc=redhat,dc=com, will apply on all entries under ou=engineering,dc=redhat,dc=com. It exists three types of roles (managed, filtered and nested) and all of them have this limitation.
The purpose of this RFE is to provide an optional role definition attribute ‘nsRoleScopeDN’ that allows a role to apply to a specified subtree of the DIT.
The following limitations applies for this RFE
Quite often, applications and their configurations are deployed in a DIT subtree separated from DIT subtree where are stored the entries. For applications using roles, this is not possible. Usually role definitions are stored at the top of the tree of the entries, but if a role needs to apply to a specific subtree in the tree of the entries then roles definitions are mixed with the entries.
The use case is to allow role definitions to be stored in a subtree not holding the entries. In the following figure, the role cn=support_svc is defined under cn=billing,cn=application,dc=company,dc=com, the attribute ‘nsRoleScopeDN’ makes this role definition to apply on the entries in the subtree ou=service,ou=sales,dc=company,dc=com instead of cn=billing,cn=application,dc=company,dc=com.
A role is a multi valued virtual attribute that is evaluated
The roles definitions are uploaded in memory (in a so called role cache [roles_list]) and organized per suffix. In order to determine the roles that an entry belongs to
In order to trigger the role scoping, administrator needs to add nsRoleScopeDN attribute in the role definition. The following changes are required:
Add the attribute ‘nsRoleScopeDN’ in the schema
( 2.16.840.1.1137220.127.116.11 NAME ’nsRoleDefinition’ DESC ’Netscape defined objectclass’ SUP ldapSubEntry MAY ( description $ nsRoleScopeDN ) X-ORIGIN ’Netscape Directory Server’ ) ( 2.16.840.1.113718.104.22.1681 NAME ’nsRoleScopeDN’ DESC ’Scope of a role’ SYNTAX 22.214.171.124.4.1.14126.96.36.199.12 SINGLE-VALUE X-ORIGIN ’389 Directory Server’ )
There is not impact at the configuration level as the new attribute is stored directly in the entries (roles definition).
There is a change of schema in 02common.ldif, where the others roles related attributes (nsrole, nsroledn and nsrolefilter) are defined (see Design)
In order to enable role scope, the role definition contains the ‘nsRoleScopeDN’ (optional) attribute like:
dn: cn=managed_scope,ou=scope_roles,dc=com objectClass: top objectClass: LDAPsubentry objectClass: nsRoleDefinition objectClass: nsSimpleRoleDefinition objectClass: nsManagedRoleDefinition cn: managed_scope nsRoleScopeDN: ou=entries,dc=com description: managed role on scope ou=entries,dc=com dn: cn=filtered_role_scope,ou=scope_roles,dc=com objectClass: top objectClass: LDAPsubentry objectClass: nsRoleDefinition objectClass: nscomplexroledefinition objectClass: nsfilteredroledefinition cn: filtered_role_scope nsRoleFilter: (telephonenumber=222) nsRoleScopeDN: ou=entries,dc=com description: filtered role on scope ou=entries,dc=com dn: cn=nested,ou=scope_roles,dc=com objectClass: top objectClass: LDAPsubentry objectClass: nsRoleDefinition objectClass: nscomplexroledefinition objectClass: nsNestedRoleDefinition cn: nested nsRoleScopeDN: ou=entries,dc=com nsRoleDN: cn=filtered_role_scope,ou=scope_roles,dc=com nsRoleDN: cn=managed_scope,ou=scope_roles,dc=com description: nested role on scope ou=entries,dc=com
A replication session starts with schema replication. So the definition of the attribute ‘nsRoleScopeDN’ will be propagated on consumers schema.
A role definition entry containing ‘nsRoleScopeDN’ attribute, will be replicated as any others entries. Once schema and role definition have been replicated, they can be updated on the replica because the entry conforms the schema.
The role scoping mechanism will not been enforced on replicas installed with older version. When parsing the role definition, old version of directory will keep this attribute but it will not be used to trigger any scoping. If a customer wants to use role scoping on a full replication topology, all replicas must be installed with a version that support RFE Role scoping
Update or upgrade will push the schema change, adding these definitions in 02common.ldif
( 2.16.840.1.1137188.8.131.52 NAME 'nsRoleDefinition' DESC 'Netscape defined objectclass' SUP ldapSubEntry MAY ( description $ nsRoleScopeDN ) X-ORIGIN 'Netscape Directory Server' ) ( 2.16.840.1.1137184.108.40.2061 NAME 'nsRoleScopeDN' DESC 'Scope of a role' SYNTAX 220.127.116.11.4.1.1418.104.22.168.12 SINGLE-VALUE X-ORIGIN '389 Directory Server' )
Note: this schema update also occurs with a replication session
When a Directory Server not supporting RFE Role scoping is updated/upgraded to a version implementing that RFE
The attribute name nsRoleScopeDN is defined in the Sun Microsystems patent (http://www.google.com/patents/US7194472). Can it be used in that RFE ?