Admin Security Dept Mental Level Delegated Admin

The Implementation of a
Departmental Level User

Provisioning Model in
OracleAS Portal 10g
An Oracle White Paper
November 2004
The Implementation of a Departmental User
Provisioning Model in OracleAS Portal 10g
INTRODUCTION
The introduction of web technology as a method to facilitate
communication within an organization, has frequently lead to an
explosive growth in the size of the user community being managed.
Furthermore, as identity management moves from a being an
application specific function to a centralized resource, the issue arises
of how to allow the central IT department to maintain ownership of
the information (and the infrastructure), without them being a
bottleneck in the User provisioning process.
More and more the issue of a growing and distributed user community
is solved by the use of a “Self-Service” methodology. That is, rather
than have a centralized DBA maintain the user community, move the
process of user provisioning to the individual organizations to which
the users belong. Thus, removing the burden (and subsequent
bottleneck) from the central IT department.
Granting local administrators global privilege to create and modify
users in the central repository however introduces some serious
security questions, such as:
• How would one limit the list of users an administrator may see
and subsequently edit?
• How would one prevent the creation of users/groups outside
of the local administrator’s sphere of influence? For example,
creating a DBA in another department.
This white paper looks at this issue, and describes how the various
components of the Oracle Application server may be configured to
support scoping of the delegated user administration to a specific area
of responsibility.
To illustrate the process, this paper will use the scenario of a state
Education department where an administration hierarchy naturally
exists. This can be summarized as follows;
1. The administrator of a given school may only view student
details from their own school (or even at a lower level, an
individual class). Likewise they may only define a new student
within scope of their school.
The Implementation of a Departmental User Provisioning Model in OracleAS Portal 10g Page 2
2. The administrator of a school district is responsible for several
schools and hence may view the details from any school, and is
also free to create/edit students in any school within their
district.
Note: In other countries a school district is commonly
referred to as a “School cluster”. For the purposes of
this white paper, the two may be seen as synonymous.
3. The State administrator oversees all the schools in the state and
hence works across several districts. He has the ability to view
and edit any student in the state, regardless of the school and
district to which they belong.
Depart ment of E ducation

Stat e A dmi nistrator
District
Administrator
Sc hool
Adminis trator
A n administrators ability to provision users is limited to their specific area of responsibility
Figure I: Requirement for Departmental Delegation of Administration
DIRECTORY INFORMATION TREE

The successful implementation of the Departmental Delegation model
revolves around modification to the default Directory Information
Tree (DIT) to more closely resemble the administration hierarchy
desired. The following sections discuss the structure of the DIT used
by OracleAS Portal and how multiple user communities may be
represented within Oracle Internet Directory.
Oracle Internet Directory Identity Management Realms

Within OID, an Identity Management Realm defines the scope over
which security policies are defined and enforced (eg for example,
password policy, naming policy, self-modification policy etc). A realm
also contains the user and group definitions, as well as the Identity
Management authorizations enabling those users & groups to access
certain privileged services in the directory. Furthermore, these
privileges define whether the user/group may use the delegated
administration services of the directory.
Effectively an Identity Management Realm defines a specific enterprise
community, it is isolated from other realms and the information within
it cannot (in general) be directly accessed from outside the realm. Each
Identity Management Realm is uniquely named to distinguish it from
other realms, and has a realm-specific administrator with complete
administrative control over that realm.
Note: All Oracle products, which store information in the
Oracle Internet Directory, require a pre-defined Identity
Management Realm to function. As such, the Oracle Universal
Installer automatically creates a realm during installation of
Oracle Internet Directory. This “default Identity Management
Realm” is where Oracle products expect to find users, groups,
and associated policies if the realm is not explicitly named.
Default DIT used by portal

When the OracleAS Portal is first associated with the Oracle
Application Server Infrastructure a default DIT is created under as the
default Identity Management Realm. The structure of which may be
seen in Figure II.
Default Directory Information Tree

DSE Root
dc=com cn=OracleContext cn=Oracle Internet Directory
dc=MyCompany cn=Portal cn=ChangeLog subscriber
dc=au orclapplicationcommonname=portal.nn.nn.nn cn=Provisioning Profile
orclODIPProfileName=subguid_appguid
cn=Users cn=groups cn=OracleContext
cn=orcladmin
cn=PUBLIC cn=portal.nn.nn.nn
cn=portal cn=products cn=Groups
cn=portal_admin
... cn=dba
cn=authenticated_users cn=common cn=OracleDAScreateGroup
cn=portlet_publisher cn=OracleDASEditGroup
cn=portlet_administrators cn=OracleDASDeleteGroup
cn=rw_basic_user orclcommonusersearchbase cn=OracleDASCreateUser
cn=rw_power_user orclcommongroupsearchbase cn=OracleDASDeleteUser
... orclcommonusercreatebase ...
orclcommongroupcreatebase
...
cn=portal
cn=IFS
cn=OCA
cn=DAS
cn=wireless
...
Figure II: Default Directory Information Tree (DIT) Structure installed as used by OracleAS Portal 10g
Note: The default Identity Management Realm name is
determined by the domain name of the server on which the
system is installed. For example, if the domain name of the server
was “oracle”, the default Identity Management Realm name
would be dc=oracle, dc=com. If the domain name cannot be
determined, the default name assigned by the directory is
dc=Default Company, dc=com
As may be seen in Figure II, the location within the DIT of portal
Users differs from that of Groups. The default user accounts
(cn=PUBLIC, cn=PORTAL, cn=PORTAL_ADMIN), and any
subsequently registered users are created in the Identify Management
Realm’s User base (cn=Users, dc=MyCompany, dc=com). These
accounts are effectively global to the realm, rather than tied to a
specific application. The rational being, it is likely that a user would be
access more than a single application within realm.
In comparison Portal groups are created within a specifically named
Portal container under the Realm’s Group base. If another Portal
instance were subsequently associated with this infrastructure, another
named portal container would be created under the Realm’s group base
(e.g. portal.041130.1102).
Note: In OracleAS Portal 10g, the name of the group container
is derived from
(Portal schema name) + (Date and time of association with
OracleAS Infrastructure)
i.e., cn=schema_name.yymmdd.hhmi
While OracleAS Portal can utilize Groups defined anywhere in the

current Identity Management Realm, locating the groups under named
portal container effectively scopes the groups to the portal as this is
where the Group List of Values (LOV) will look for named groups.
Groups may be defined as either Public or private and access is defined
by ownership/membership in the specific group. In order to simplify
the discussion, this white paper will focus on User provisioning.
Group provisioning may be handled in the same manner.
Search and Create Bases

In order to allow Oracle Components to efficiently interact with the
Oracle Internet directory, a number of specific locations are defined for
the realm and held within the OracleContext subtree (cn=common ,
cn=products). These definitions define the default locations from
which to perform a number of standard tasks including;
• Where to look in the DIT for User information.
(orclcommonusersearchbase).
• The default location to create a new user in the DIT
(orclcommonusercreatebase)
• Where to look in the DIT for Group information.
(orclcommongroupsearchbase).
• The default location to create groups in the DIT
(orclcommongroupcreatebase)
These are only default locations and a product may query any point
within the Realm for user/group information. However, the use of the
Create and Search bases allow for quicker retrieval of information as
the List of Values (LOV) used by the Portal (actually part of the DAS
console) begins the LDAP query from the location specified.
Given the requirements of a Departmental Delegation model the way
in which the Portal uses these values will be modified (in part).
Default Directory Privilege Groups

When the Oracle Identity Management Repository is created as part of
the Infrastructure installation, the installer creates a default
configuration and defines a series of access control policies (ACPs) at
various points in the directory information tree (DIT). In particular
access controls are placed on the user and group containers within the
default realm (cn=Users & cn=groups respectively).
The access control policies defined on the Users container specify

which privileged roles can create or edit a user within the realm. To
create a user, an Administrator must be a member of the
OracleDASCreateUser group. Likewise to edit or delete any user in
the system, they must be a member of the OracleDASEditUser and
OracleDASDeleteUser groups respectively
Note: For a complete list of the DAS privilege groups please
refer to the Oracle Internet Directory Administrators guide.
Within the directory tree privileged roles are defined as “public groups”
under the OracleContext node of the realm. Groups defined at this
location are utilized by Directory Access Control Items (ACI) as a
privilege definition rather than a aggregation. On the other hand
groups defined under the cn=portal.nn.nn.nn container are seen as
aggregations and may be used within a Portal Access Control List.
IDENTIFYING USER COMMUNITIES
In order to apply varying security characteristics to different groups of

users, defined within the Oracle Internet Directory (OID), there needs
to be a method in which to uniquely identify a given community. It is
this community definition against which appropriate policies may be
defined.
Using Multiple Identity Management Realms
The Oracle Internet Directory supports the creation of totally
independent user communities, through the ability to create Multiple
Identity Management Realms within the one directory. Each Realm is
a fully scoped area, which consists of a well-defined and independent
set of user identities, security polices and groups.
By default, the values within a realm are only accessible to

objects/users also within the same realm. That is, a LDAP Query may
only function within a given Identity Management Realm not across
them. Further more each Identity Management Realm has its own
OracleContext subtree and hence will have its own definitions of the
Search and Create base attributes.
As such, it may the very thing that makes Multiple Identity

Management Realms useful for defining independent communities
which prevents their use for a Departmental Administration Model for
use with portal. That is their inability to share an application across the
Realm. As the Groups used by Portal are held within the default realm
it would not be possible for users in another Realm to be able to query
those groups or be made members of them. Likewise, the values of the
Search and Create bases would be pointing to the wrong area of the
Directory Tree.
Multiple Security Realms

DSE Root
Realms are independent

dc=com dc=com cn=OracleContext
dc=MyCompany dc=MyCompany cn=Portal
dc=au dc=us orclapplicationcommonname=portal.nn.nn.nn
8
cn=Users cn=groups cn=OracleContext cn=Users cn=portal.nn.nn.nn cn=OracleContext
cn=orcladmin cn=orcladmin
cn=PUBLIC cn=portal.nn.nn.nn cn=products cn=PUBLIC ...
cn=portal cn=portal
cn=portal_admin cn=portal_admin
... cn=dba cn=common ...
cn=authenticated_users
cn=portlet_publisher
cn=portlet_administrators orclcommonusersearchbase
cn=rw_basic_user orclcommongroupsearchbase
cn=rw_power_user orclcommonusercreatebase
... orclcommongroupcreatebase
...
cn=portal
cn=IFS
cn=OCA
cn=DAS
cn=wireless
...
Figure III; A Portal Infrastructure Cannot Span Identity Management Realms.
Note: The Hosted Model for Portal does use multiple Identity
Management Realms to define multiple hosted communities. In
this case the Portal component is automatically copied to each
realm. That is, each is still independent.
Segmenting a Single Realm

As the functionality of the application requires the use of a single
realm, a simple way to represent user communities is to convert the flat
list of users found in cn=Users, into a tree structure that represents the
administrative hierarchy. That is, create a subtree below the Users
container, where each community is defined by its parent container.
These are also the point of administration for the community.
In the example of the Education department, this would be expressed
as a hierarchy of containers (objectclass=orclcontainer) that mapped
to the State, District and individual school.
DSE Root
Realm
(dc=au,dc=DeptOfEducation,dc=gov)
cn=orcladmin cn=State1 cn=State2 cn=State(n)

cn=PUBLIC
cn=portal
cn=portal_admin cn=StateAdmin cn=SchoolDistrict100 cn=SchoolDistrict200 cn=SchoolDistrict300
...
cn=SD100Admin cn=SD100 School 1 cn=SD100 School 2 cn=SD100 School 3

cn=SD100 Admin1 cn=SD200 School 1 cn=SD200 School 2 cn=SD300 Admin cn=SD300 School 1 cn=SD300 School 2
cn=SD100-1 AdminUser cn=SD100-1 Student1 cn=SD100-2 Student 1 cn=SD100-3 Student1

cn=SD100-2 Admin cn=SD100-3 Admin cn=SD200-1 Admin SD200-2 Admin cn=SD300-1 Admin cn=SD300-2 Admin
cn=SD100-1 AdminUser2 cn=SD100-1 Student2 cn=SD100-2 Student 2 cn=SD100-3 Student2
cn=SD100-1 Student3 cn=SD100-2 Student 3 cn=SD100-3 Student3
cn=SD100-1 Student4
Figure IV: Example Segmented User Subtree With Areas of Administration Privilege Highlighted.
A user at the Branch level therefore has the subtree below the branch
as their defined scope of responsibility.
As can be seen from Figure IV the user cn=StateAdmin is defined in
the cn=State1 container. That is, at the same level as the School
Districts themselves, and as such they subsequently have those School
Districts within their administration domain. The School district
Admin is limited to the schools within their district, and so on.
Once the administrative hierarchy is defined, the use of Privileged role
membership and Access Control Polices (ACP) allows for the
definition of differently secured groups of users. (See below for
descript/and use of Access Control Items (ACI) to define appropriate
access polices.)
Note: It is required that the segmented tree structure should be in place
before the definition of the ACIs. If the OID server is not able to
resolve a Distinguished Name referenced when the ACI is applied it
will fail and an error returned.
The fastest method to create a complex administrative hierarchy (as
shown in Figure IV) is through the use of an LDIF file and the LDAP
add or bulk load utilities.
Example LDIF file to create School District 100.

--State Level --
dn: cn=State1, cn=Users, dc=au, dc=DepartOfEducation, dc=gov
objectclass: top
objectclass: orclContainer
cn: Students
--District Level --
dn: cn=SchoolDistrict100, cn=State1, dc=au, dc=DepartOfEducation, dc=gov
objectclass: top
cn: cn=SchoolDistrict100
-- School Level --
dn: cn=SD100School1, cn=SchoolDistrict100, cn=State1, cn=Users, dc=au,
dc=DepartOfEducation, dc=gov
objectclass: top
cn: cn=SD100School1
-- State Administrator --
dn: cn=StateAdmin, cn=State1, cn=Users,dc=au,dc=oracle,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgperson
objectclass: orcluser
objectclass: orcluserV2
mail: adminuserc@test.com
cn: StateAdmin
givenname: Admin
uid: StateAdmin
description: The user Administrator for the entire State for the Dept. of Education
… and so on down the sub tree.
Redefine Default Privilege Definitions
As previously discussed membership in the OracleDAS public groups

allows the user to have global privilege to create and/or edit any user in
the system. This is based on the Access Control Policy defined on the
Users container and any created beneath it. As the goal of the
Departmental Delegation model is to limit an administrator to a
“privilege scope”, (in our case a School District and/or individual
school) it is necessary to remove direct privilege assignment to the
OracleDAS Roles and implement a Privilege Group structure that
closely represents the scope of privileges required. (The roles may be
represented either as a tree, as in Figure IV, or as a flat list.)
Note: As these groups will specify the access rights to the
directory, they should be seen as Privileged Roles rather than
aggregation groups and hence should be created under the
Realm’s OracleContext (e.g. cn=Groups, cn=OracleContext,
dc=au,dc=DeptOfEducation,dc=gov).
Membership in these roles along with the use of Access Control
Policies (discussed in next the section) will define the scope in which an
administrator has create/edit privileges. As such the following should
be defined;
• An appropriate administration Role defined for each
administrative level of the hierarchy. (e.g. cn=SD100School1 &
cn=SchoolDistrict100)
• The Administration user at each departmental administration
level is a “Unique Member” of the Role defined for that level.
(e.g. cn=SD100-1 Admin)
• Administration Group of the Parent is a “Unique Member” of
those departments within it administration scope. (e.g.
cn=SD100 Admin)
• Each specified administrative role should be made a
UniqueMember of the OracleDAS group relating to the desired
Action on the directory.
In order to allow for the definition of a Global Administrator able to
access/manage users across each state subtree it is necessary to have a
Global Privilege group defined.
The Global Administration Group (cn=GlobalStudentAdmin) is
• A “Unique Member” of each Departmental Subtree Root
administration group (e.g. cn=SD100-Admin, cn=SD200-
Admin, cn300-Admin).
• Contains all users who are defined in the default user container
(cn=Users) who have admin responsibility over the subtree
structure of the segmented User container (e.g.StateAdmin).
• The Global Administration group is made a UniqueMember of
the appropriate OracleDAS privilege groups
Figure V presents an example privilege group structure to implement
the Department of Education example used in this white paper.
DSE Root
Realm
(eg. dc=au, dc=DeptOfEducation, dc=gov)
cn=products cn=Groups
cn=common
cn=OracleDAScreateGroup cn=GlobalStudentAdmin
cn=OracleDASEditGroup
orclcommonusersearchbase cn=OracleDASDeleteGroup
orclcommongroupsearchbase cn=OracleDASCreateUser
orclcommonusercreatebase cn=OracleDASDeleteUser cn=State1Admin cn=State(nn)Admin
orclcommongroupcreatebase ...
...
cn=portal
cn=SD100-Admin cn=SD200-Admin cn=SD300-Admin
cn=IFS
cn=OCA
cn=DAS
cn=wireless SD100-1-Admin SD100-2-Admin SD100-3-Admin SD200-1-Admin SD200-2-Admin ...
...
Figure V: Privilege Role Structure for Department Level User Provisioning
Note: While the departmental administration roles, will be used
to define the scope of user provisioning, it is important that the
users are still members of the Oracle DAS privilege groups
themselves. This is due to the fact that membership in these
groups determines the users ability to access the appropriate
administration functions within the Portal itself. That is, only a
user who is a member of the OracleDASCreateUser,
OracleDASEditUser, or OracleDASDeleteUser privilege groups
will have the User portlet displayed on the OracleAS Portal’s
administration page. Likewise, the hyperlink used to create a new
user is rendered only if the user is a member of the
OracleDASCreateUser group (with “Edit” privilege they would
still see the portlet itself).
USING ACCESS CONTROL ITEMS
Access to the various nodes within the Directory tree is defined by the
implementation of Access control Policies within the Tree itself.
These Policies map the available privileges, such as Browse Delete,
Write to named entities within the directory. These may be Groups,
Users or even Wild cards based on a specific attribute such as DN.
Directory policies are defined by the setting of the orclACI attribute.
This represents the access policies that are to be inherited by the
subtree of beneath the node in which the Policy was defined. When
there is a security hierarchy, as in the School District example, with
multiple ACPs existing at different levels a subordinate container (such
as an individual school or student) will inherit the access policies from
all of the superior ACPs. Unless explicitly over ridden at a lower level.
Put simply, Access policies will be inherited down the branch, but they
are evaluated from the leaf back. That is, if access is denied at the root
node, it can be reversed at a specific point without having to define the
policy at each level in the hierarchy
The Departmental Delegated Administration model uses the ACI in
this manner to prevent school administrators from accessing containers
(e.g. students from other schools) out side of their scope, while still
having full access to their own areas.
The access control directive may be defined against an entire Container
or specified against individual attributes within it.
The basic structure of the ACI is as follows;

OrclACI:
access to Entry | Attribute ([filter=(< ldapFilter>)]
by * | dn="expression" | group="<dn>" | self |
(identity of the entity or an attribute of it)
dnAttr=(dn_attrib) | guidattr=(guid_attrib) |
groupattr=(group_atttrib)
(Access list)
The values of (Access list) will depend on whether the ACI applies to
access to the container or the attributes within it. (e.g. none | compare
| search | browse | proxy | read ).
Note: For a further description of the Syntax of Access Control

items please refer to The Oracle Internet Directory
Administration Guide (Part III)
LDIF File example

dn: cn=Users,dc=au,dc=oracle,dc=com
changetype: modify
add: orclaci
orclaci: access to entry by
dn=".*,cn=State1,cn=Users,dc=oracle,dc=com" (none)
Defining the Departmental Delegation model via ACIs
In order to limit a given administrator to a specific branch (or leaf) of

the Directory tree, the default Access Policies on the User container
need to be changed to match the Privilege role definitions described
above. As ACPs are implemented down a directory tree, but access
rights evaluated from the leaf node (e.g. individual school) up the
branch to the root, this privilege may be achieved as follows;
1. Add an ACI entry filter to remove all access to the cn=Users, and
entire subtree beneath it, to any user defined under the
Departmental Users container through an ACI entry filter.
e.g.
dn: cn=Users,dc=au,dc=DeptOfEducation,dc=gov
orclaci: access to entry filter=(objectclass=inetorgperson)
by dn=".*, cn=State1, cn=Users, dc=au, dc=DeptOfEducation,
dc=gov" (none)
2. Remove ACI entry filters from cn=Users which grant Browse,

Add, Delete, Proxy privilege to the OraclDAS privilege groups.
e.g. Remove the following from the User container

(dn: cn=Users,dc=au,dc=DeptOfEducation,dc=gov)
orclaci: access to entry filter=(objectclass=orcluser*)
by group="cn=oracledascreateuser, cn=groups, cn=oraclecontext,
dc=au, dc=DeptOfEducation, dc=gov " (privilege list)
by group="cn=oracledasedituser, cn=groups, cn=oraclecontext,
dc=au, dc=DeptOfEducation, dc=gov " (privilege list)
3. Remove ACI attribute filters from cn=Users which grant " (read,
search, write, selfwrite, compare) privilege to the OracleDAS
privilege groups
e.g. Remove the following from the User container
orclaci: access to attr=(*) filter=(objectclass=inetorgperson)

by group="cn=oracledasedituser, cn=groups, cn=OracleContext,
dc=au,dc=DeptOfEducation,dc=gov " (read,search,write,compare)
4. Add an ACI entry filter to grant Browse, Add, Delete, Proxy

privileges on the cn=Users container to the New Global
Administrator Privilege role defined.
e.g.
dn: cn=Users, dc=au,dc=DeptOfEducation,dc=gov
by group="cn=GlobalAdmin, cn=StudentAdminPrivs, cn=groups,
cn=OracleContext, dc=au,dc=DeptOfEducation,dc=gov"
(browse, add , delete, proxy)
5. Add an ACI Attribute filter to cn=Users to grant to the new

Global Admin Role the same attribute privileges previously held
by the OracleDAS privilege groups
e.g.
dn: cn=Users, dc=au,dc=DeptOfEducation,dc=gov
by group=" cn=GlobalAdmin, cn=StudentAdminPrivs, cn=groups,
cn=OracleContext, dc=au,dc=DeptOfEducation,dc=gov "
(read,search,write,compare)
6. Add an ACI entry filter on the individual school container to

grant Browse, Add, Delete, Proxy privileges to the appropriate
administration group defined.
e.g.
dn: cn=SD100School1, cn=SchoolDistrict100, cn=State1, cn=Users,
dc=au, dc=DeptOfEducation, dc=gov
by group="cn=SD100-1-Admin, cn=SD100-Admin,
cn=StudentAdminPrivs, cn=groups, cn=OracleContext,
dc=au,dc=DeptOfEducation,dc=gov"
(browse, add , delete, proxy)
7. Add an ACI Attribute filter on the individual school container to
grant attribute Read, Write, Search, Compare privileges to the
appropriate administration group defined.
e.g.
dn: cn=SD100School1, cn=SchoolDistrict100, cn=State1, cn=Users,
dc=au, dc=DeptOfEducation, dc=gov
by group cn=SD100-1-Admin, cn=SD100-Admin,
cn=StudentAdminPrivs, cn=groups, cn=OracleContext,
dc=au,dc=DeptOfEducation,dc=gov " (read,search,write,compare)
8. Repeat Steps 6 & 7 for each individual school container.
9. Repeat Steps 6 & 7 for the each School District container
(using the District level administration Group) until reaching
the level of the Global Admin.
Note: The Oracle Internet Directory 10g supports the definition
of multiple orclaci attributes in a single container (one after
another). However, this can lead to unpredictable results where
the Access Policies defined result in a contradiction.
As such it is recommended to update the current orclaci
attributes on the cn=Users container rather than simply add new
ACI attributes to the container.
USER PROVISIONING
One of the major advantages of centralizing the scope of the Directory

through the use of ACIs, is that it dramatically reduces the requirement
for the application (or even to a degree, the end user) to be aware of
the segmentation of the user community.
Finding Users (within limits)

The LDAP search syntax requires the definition of a point in the
directory tree from which to start the query (the “basedn”). Likewise,
one has to define the scope of the query. That is, how many levels of
the tree should be accessed in order to satisfy the query criteria
specified.
Scope = base (the container specified by basedn) | one-level (it’s
immediate children) |subtree (the entire subtree from the basedn
down)
As the default scope is to traverse the entire sub tree, it removes the
need to define a separate starting point for each School district and/or
school. By starting at the top node (cn=Users) we can perform a
single open query across all schools and effectively traverse all students.
The impact of the ACIs defined above, and the current user’s
membership of a given privilege group, is to effectively skip any node
to which the current user does not have Browse privilege. Resulting in
a “result set” that maps to the District/Schools to which they have
responsibility. Thus, from the application’s perspective the
segmentation of the tree is transparent.
Access to the appropriate list of students is greatly simplified within the
Portal by use of the User provisioning Portlet. When the Portlet’s
LOV icon is clicked, the DAS LOV component uses the
OrclCommonUserSearchBase defined for the realm, as the starting
point for its LDAP search. Hence, without having to modify the LOV
or the portlet, the list of students returned will be scoped to the area of
responsibility of the current administrator.
Figure VI: Segmentation of the User Community is transparent to the LDAP Query
User Creation within the correct departmental location

Whereas the implementation of a segmented user tree has little effect
on the LDAP searching functions of an application, the same cannot
be said for creating a new user in the system.
By default the OrclCommonUserCreateBase points to the
cn=Users container, and hence the DAS console will open pointing to
that location, and explicitly try to create the user there. As ACIs
preventing browse and write capability have been associated with this
container, an error would occur when the new student was submitted
to the directory. Hence for the creation of new users into the
segmented User tree (in this case students into different school
districts/schools), it is necessary for the application to explicitly define
where, based on the current administrator’s scope, the new user should
be created.
Note: Oracle Internet Directory supported the definition of
multiple values for the OrclCommonUserCreateBase attribute.
If multiple values are defined, the DAS console presents the user
with a pop-list of full DNs as possible locations in which to
create the user.
Likewise the parent DN may be determined by setting multiple
values for the organizational unit (ou) attribute (as a list). The
administrator may then choose the organization unit under which
to place the new user. For a limited number of locations, and
with Directory aware end-users, these options may suffice, hence
removing the need for further customization.
Although the application is now explicitly defining where the user is to

be created, if a location is chosen to which the current administrator
does not the appropriate privileges, the action is disallowed and an
error returned. Hence the security of the DIT is maintained. (This is
also the case if an inappropriate DN is chosen from the DAS console,
where multiple create base values are defined)
In order to limit the number of errors presented to the end users, the
application should determine the administration scope of the current
user and present only those locations, which would be valid. For
example a School district Administrator should be presented with a list
of the containers representing, the district and each school with in it
(cn=SchoolDistrict100, cn=SD100School1, cn=SD100School2,
cn=SD100School3). A student created by an individual school’s
administrator should be directly inserted into the container for that
school.
The steps to achieve this are as follows;
1. Query the full DN of the current user based on their unique ID
(SSO username)
e.g. “cn=SD100Admin” =>
“cn=SD100Admin, cn=SchoolDistrict100, cn=State1, cn=Users,
dc=au, dc=DeptOfEducation, dc=gov”
2. Determine the full DN of the Parent container by simply
removing the Relative Distinguished Name (RDN) from the
full DN of the user (by default the RDN will be the SSO
username).
e.g. “cn=SchoolDistrict100, cn=State1, cn=Users, dc=au,
dc=DeptOfEducation, dc=gov”
3. Determine the list of possible locations within the scope of the
current administrator, by querying for the DNs of the
browsable “container” nodes in the subtree.
• Search base: DN of Parent Container
• Search Filter: objectclass=orclcontainer
4. Once the appropriate location is chosen the application need
only define the DN of the new user in the appropriate LDAP
add command. Therefore preventing an attempt to create a user
in an invalid location.
Prevention of Duplicate Usernames

The Oracle Single Sign On environment requires that every username
defined in the system is unique, and when all users are co-located in the
same container (cn=Users) this is a fairly straightforward exercise, as
the Directory automatically prevents duplicate Distinguished Names.
However in a Departmental delegation model, where each local Admin
chooses the username, there is a high likelihood of collision on the user
name space. For example, in the case of a School system, it is most
likely that there will be two or more students with the same name
somewhere in the system (if not, the same school). As such, extra
steps must be taken to prevent the creation of duplicate Username
entries.
Note: OID by default will not prevent this, as the full Distinguished
Names of the students will still be Unique. However the SSO server
requires the SSO username, defined by the Nickname attribute
(orclCommonNickNameAttribute) to be unique.
This issue may be prevented by a number of steps;

1. Define a Organization Wide Naming Convention
2. Enforce Uniqueness on the attribute being used for the SSO
credential (normally cn=username) by use of a unique
attribute constraint in the Directory Information Tree
itself.
The first step is operational in nature, and is dependent on the
Administrators having an understanding of the naming structure,
and sticking to it. Whereas the use of Firstname.Initial.Lastname
is generally acceptable with a small user base, with a large population
it is unlikely to be sufficiently granular to ensure uniqueness. It is
then necessary to append an appropriate suffix (or Prefix such as the
school or district ID) to uniquely identify the student (this can be
seen in such Public Websites as Yahoo!, MSN etc.)
The unique attribute constraint, as the name would suggest, prevents
duplication of an attribute value, both when adding the entry and when
subsequently if it is edited. If a duplicate value is identified for the
attribute in question, the operation is cancelled and an error returned to
the user. In this manner an administrator can be alerted that the name
by which they are registering a student is not unique.
Note: Use of a School or District based Prefix would greatly
reduce the likelihood of namespace collisions in the first place.
An Attribute may de defined as unique:
• Across the entire directory
• Across a given scope (subtree, container/s)
• Across a given object class
• Or a combination of the above.
To implement an “Attribute Uniqueness Constraint” an entry is created

under the Directory Trees root OracleContext (cn=unique,
cn=common, cn=products, cn=oraclecontext) naming the attribute to
be monitored, the scope of uniqueness and optionally to which object
class this applies.
The following LDIF file entry shows the definition of a unique
constraint on the UID attribute from the inetOrgPerson object class,
for all entries in the cn=Users container and the School Districts
defined beneath it. The nickname attribute is used to define the SSO
username and by default this will be based on the Common Name.
Example LDIF structure for implementing a Uniqueness Constraint
dn: cn=constraint1, cn=unique, cn=common, cn=products,

cn=oraclecontext
objectclass: orclUniqueConfig
orcluniqueattrname: uid
orcluniquesubtree: cn=Users,dc=au,dc=DeptOfEducation,dc=gov
orcluniquescope: sub
orcluniqueobjectclass: InetOrgPerson
Note: For a further description of the Syntax of Attribute

Uniqueness Constraints items please refer to The Oracle Internet
Directory Administration Guide (Chapter 8).
Using DAS Console for the Provisioning Interface

While the needs of a specific user community may require a fully
custom interface, the creation of the provisioning UI against a
segmented User tree is greatly simplified by the ability to dynamically
specify where the DAS console will attempt to create the new user.
This is achieved by adding the parentDN argument to the URL issued
to launch the console. The value of which is the full DN of the
container in which the user will be created.
Eg.
http://ptlsrv1.au.oracle.com:7777/oiddas/ui/oracle/ldap/
das/user/DASCreateUserInfoAdmin?clearcache=true&parentD
N=
“cn=SD100School1,cn=SchoolDistrict100,cn=State1,
cn=Users,dc=au,dc=DeptOfEducation,dc=gov”
If the parentDN is not specified the location will default to that

specified in the User Search base.
For further information on the available URL arguments to use with

the DAS console please refer to the Oracle® Internet Directory,
Application Developer’s Guide 10g (9.0.4).
Note: The use of the parentDN argument with the DAS

console is currently only documented for the creation of Groups
within the Realm’s Group container. Given the default container
structure for Users is flat, and not hierarchical, the use of the
parentDN argument in the provisioning of users has not been
fully tested by the DAS development team and may result in
inconsistent behaviour.
Departmental Provisioning within OracleAS Portal 10g

The User portlet on the Portal tab under the Administration link
enables the creation and subsequent modification of users through
calling a service unit (sub-set) of the DAS console. The standard
portlet will, as previously discussed, will support the querying of users
in a segmented tree; it will not support the creation of a user. However
modification of the Portlet using the steps defined above enables both
the query and provisioning of users to be exposed through the same
simple interface.
Figure VII: Modified User Portlet to Support Departmental User Provisioning.
Figure VII shows this modified functionality, where the current user’s
sphere of responsibility is exposed in the Portlet. By selecting the
appropriate location prior to clicking the Create New Users link, the
School district administrator can automatically provision the user at the
appropriate point in the tree. For individual school administrators the
UI appears as per the normal portlet and the Student is explicitly placed
in the appropriate school container.
Note: The location displayed in the User Interface may be based
on the Relative Distinguished Name, however for ease of
understanding (the common name (cn) may not be descriptive)
the containers Description Attribute may be used, as is the case
in Figure VII.
CONCLUSION
The explosive growth in the number of users having to be managed
within an organization’s Identity management Repository, has lead
many administrators to look at Self-Service as the solution to the
Provisioning bottle-neck. The primary concern has always been one of
security. How can the central portal administrator allow individual
departments the ability to provision users (with all the rights that
entails) but at the same time limit the scope to only the departments in
question?
As discussed in this paper, modifications of the default Directory
Information Tree, as well as minor changes in the OracleAS Portal,
make it possible to implement a delegated administration Model in
which user provisioning is moved out to the organizations to which the
users belong, while allowing the information to remain a centralized
resource.
The Implementation of a Departmental User Provisioning Model in OracleAS Portal 10g
November 2004
Author: Barry Hiern
Contributing Authors: Paul Encarnación, Sunil Marya, Peter Lubbers
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
www.oracle.com
Oracle is a registered trademark of Oracle Corporation. Various

product and service names referenced herein may be trademarks
of Oracle Corporation. All other product and service names
mentioned may be trademarks of their respective owners.
Copyright © 2000 Oracle Corporation

All rights reserved.

Admin Security Dept Mental Level Delegated Admin

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Admin Security Dept Mental Level Delegated Admin

Загружено:

Авторское право:

Доступные форматы

The Implementation of a

Departmental Level User

Depart ment of E ducation

A n administrators ability to provision users is limited to their specific area of responsibility

Figure I: Requirement for Departmental Delegation of Administration

DIRECTORY INFORMATION TREE

Oracle Internet Directory Identity Management Realms

Default DIT used by portal

Default Directory Information Tree

dc=com cn=OracleContext cn=Oracle Internet Directory

dc=MyCompany cn=Portal cn=ChangeLog subscriber

dc=au orclapplicationcommonname=portal.nn.nn.nn cn=Provisioning Profile

While OracleAS Portal can utilize Groups defined anywhere in the

Search and Create Bases

Default Directory Privilege Groups

The access control policies defined on the Users container specify

IDENTIFYING USER COMMUNITIES

In order to apply varying security characteristics to different groups of

By default, the values within a realm are only accessible to

As such, it may the very thing that makes Multiple Identity

Multiple Security Realms

Realms are independent

dc=MyCompany dc=MyCompany cn=Portal

dc=au dc=us orclapplicationcommonname=portal.nn.nn.nn

Figure III; A Portal Infrastructure Cannot Span Identity Management Realms.

Segmenting a Single Realm

cn=Users cn=groups cn=OracleContext

cn=orcladmin cn=State1 cn=State2 cn=State(n)

cn=SD100Admin cn=SD100 School 1 cn=SD100 School 2 cn=SD100 School 3

cn=SD100-1 AdminUser cn=SD100-1 Student1 cn=SD100-2 Student 1 cn=SD100-3 Student1

Example LDIF file to create School District 100.

Redefine Default Privilege Definitions

As previously discussed membership in the OracleDAS public groups

cn=Users cn=groups cn=OracleContext

USING ACCESS CONTROL ITEMS

The basic structure of the ACI is as follows;

Note: For a further description of the Syntax of Access Control

LDIF File example

Defining the Departmental Delegation model via ACIs

In order to limit a given administrator to a specific branch (or leaf) of

2. Remove ACI entry filters from cn=Users which grant Browse,

e.g. Remove the following from the User container

e.g. Remove the following from the User container

orclaci: access to attr=(*) filter=(objectclass=inetorgperson)

4. Add an ACI entry filter to grant Browse, Add, Delete, Proxy

5. Add an ACI Attribute filter to cn=Users to grant to the new

6. Add an ACI entry filter on the individual school container to

One of the major advantages of centralizing the scope of the Directory

Finding Users (within limits)

User Creation within the correct departmental location

Although the application is now explicitly defining where the user is to

Prevention of Duplicate Usernames

This issue may be prevented by a number of steps;

To implement an “Attribute Uniqueness Constraint” an entry is created

Example LDIF structure for implementing a Uniqueness Constraint

dn: cn=constraint1, cn=unique, cn=common, cn=products,

Note: For a further description of the Syntax of Attribute

Using DAS Console for the Provisioning Interface

If the parentDN is not specified the location will default to that

For further information on the available URL arguments to use with

Note: The use of the parentDN argument with the DAS

Departmental Provisioning within OracleAS Portal 10g

Figure VII: Modified User Portlet to Support Departmental User Provisioning.