admin security dept mental level delegated admin

8/14/2019 Admin Security Dept Mental Level Delegated Admin

1/22

The Implementation of aDepartmental Level UserProvisioning Model in

OracleAS Portal 10g

An Oracle White Paper

November 2004


2/22

The Implementation of a Departmental User Provisioning Model in OracleAS Portal 10g Page 2

The Implementation of a Departmental User

Provisioning Model in OracleAS Portal 10g

INTRODUCTION The introduction of web technology as a method to facilitatecommunication within an organization, has frequently lead to anexplosive growth in the size of the user community being managed.Furthermore, as identity management moves from a being anapplication specific function to a centralized resource, the issue arisesof how to allow the central IT department to maintain ownership ofthe information (and the infrastructure), without them being abottleneck in the User provisioning process.

More and more the issue of a growing and distributed user communityis solved by the use of a Self-Service methodology. That is, ratherthan have a centralized DBA maintain the user community, move theprocess of user provisioning to the individual organizations to whichthe users belong. Thus, removing the burden (and subsequentbottleneck) from the central IT department.

Granting local administrators global privilege to create and modifyusers in the central repository however introduces some serioussecurity questions, such as:

How would one limit the list of users an administrator may seeand subsequently edit?

How would one prevent the creation of users/groups outsideof the local administrators sphere of influence? For example,creating a DBA in another department.

This white paper looks at this issue, and describes how the variouscomponents of the Oracle Application server may be configured tosupport scoping of the delegated user administration to a specific area

of responsibility. To illustrate the process, this paper will use the scenario of a stateEducation department where an administration hierarchy naturallyexists. This can be summarized as follows;

1. The administrator of a given school may only view studentdetails from their own school (or even at a lower level, anindividual class). Likewise they may only define a new studentwithin scope of their school.


3/22


2. The administrator of a school district is responsible for severalschools and hence may view the details from any school, and isalso free to create/edit students in any school within theirdistrict.

Note: In other countries a school district is commonlyreferred 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 andhence works across several districts. He has the ability to viewand edit any student in the state, regardless of the school anddistrict to which they belong.

DIRECTORY INFORMATION TREE

The successful implementation of the Departmental Delegation modelrevolves around modification to the default Directory Information Tree (DIT) to more closely resemble the administration hierarchydesired. The following sections discuss the structure of the DIT usedby OracleAS Portal and how multiple user communities may berepresented 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 realmalso contains the user and group definitions, as well as the Identity

Figure I: Requirement for Departmental Delegation of Administration

An administrators ability to provision users is limited to their spec ific a rea of responsibility

Department of Education

State A dministrator

DistrictAdministrator

School

Adminis trator


4/22


Management authorizations enabling those users & groups to accesscertain privileged services in the directory. Furthermore, theseprivileges define whether the user/group may use the delegatedadministration services of the directory.

Effectively an Identity Management Realm defines a specific enterprisecommunity, it is isolated from other realms and the information within

it cannot (in general) be directly accessed from outside the realm. EachIdentity Management Realm is uniquely named to distinguish it fromother realms, and has a realm-specific administrator with completeadministrative control over that realm.

Note: All Oracle products, which store information in theOracle Internet Directory, require a pre-defined IdentityManagement Realm to function. As such, the Oracle UniversalInstaller automatically creates a realm during installation ofOracle Internet Directory. This default Identity ManagementRealm 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 OracleApplication Server Infrastructure a default DIT is created under as thedefault Identity Management Realm. The structure of which may beseen in Figure II.

Default Directory Information Tree

cn=orcladmin

cn=PUBLIC

cn=portal

cn=portal_admin

...

cn=Users

cn=dba

cn=authenticated_users

cn=portlet_publisher

cn=portlet_administrators

cn=rw_basic_user

cn=rw_power_user

...

cn=portal.nn.nn.nn

cn=groups

orclcommonusersearchbase

orclcommongroupsearchbase

orclcommonusercreatebase

orclcommongroupcreatebase

...

cn=common

cn=portal

cn=IFS

cn=OCA

cn=DAS

cn=wireless

...

cn=products

cn=OracleDAScreateGroup

cn=OracleDASEditGroup

cn=OracleDASDeleteGroup

cn=OracleDASCreateUser

cn=OracleDASDeleteUser

...

cn=Groups

cn=OracleContext

dc=au

dc=MyCompany

dc=com

orclapplicationcommonname=portal.nn.nn.nn

cn=Portal

cn=OracleContext

orclODIPProfileName=subguid_a

cn=Provisioning Profile

cn=ChangeLog subscribe

cn=Oracle Internet Directo

DSE Root

Figure II: Default Directory Information Tree (DIT) Structure installed as used by OracleAS Portal 10g


5/22


Note: The default Identity Management Realm name isdetermined by the domain name of the server on which thesystem 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 bedetermined, 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 portalUsers differs from that of Groups. The default user accounts(cn=PUBLIC, cn=PORTAL, cn=PORTAL_ADMIN), and anysubsequently registered users are created in the Identify ManagementRealms User base (cn=Users, dc=MyCompany, dc=com). Theseaccounts are effectively global to the realm, rather than tied to aspecific application. The rational being, it is likely that a user would beaccess more than a single application within realm.

In comparison Portal groups are created within a specifically namedPortal container under the Realms Group base. If another Portalinstance were subsequently associated with this infrastructure, anothernamed portal container would be created under the Realms group base(e.g. portal.041130.1102).

Note: In OracleAS Portal 10g, the name of the group containeris derived from(Portal schema name) + (Date and time of association withOracleAS Infrastructure)i.e., cn=schema_name.yymmdd.hhmi

While OracleAS Portal can utilize Groups defined anywhere in thecurrent Identity Management Realm, locating the groups under namedportal 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 definedby ownership/membership in the specific group. In order to simplifythe 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 theOracle Internet directory, a number of specific locations are defined forthe realm and held within the OracleContext subtree (cn=common ,cn=products). These definitions define the default locations fromwhich to perform a number of standard tasks including;

Where to look in the DIT for User information.(orclcommonusersearchbase).


6/22


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 pointwithin the Realm for user/group information. However, the use of theCreate and Search bases allow for quicker retrieval of information asthe List of Values (LOV) used by the Portal (actually part of the DASconsole) begins the LDAP query from the location specified.

Given the requirements of a Departmental Delegation model the wayin 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 ofthe Infrastructure installation, the installer creates a defaultconfiguration and defines a series of access control policies (ACPs) at various points in the directory information tree (DIT). In particularaccess controls are placed on the user and group containers within thedefault 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. Tocreate a user, an Administrator must be a member of theOracleDASCreateUsergroup. Likewise to edit or delete any user inthe system, they must be a member of the OracleDASEditUser and

OracleDASDeleteUsergroups respectively

Note: For a complete list of the DAS privilege groups pleaserefer to the Oracle Internet Directory Administrators guide.

Within the directory tree privileged roles are defined as public groupsunder the OracleContext node of the realm. Groups defined at thislocation are utilized by Directory Access Control Items (ACI) as aprivilege definition rather than a aggregation. On the other handgroups defined under the cn=portal.nn.nn.nncontainer are seen asaggregations and may be used within a Portal Access Control List.

IDENTIFYING USER COMMUNITIES

In order to apply varying security characteristics to different groups ofusers, defined within the Oracle Internet Directory (OID), there needsto be a method in which to uniquely identify a given community. It isthis community definition against which appropriate policies may bedefined.


7/22


Using Multiple Identity Management Realms

The Oracle Internet Directory supports the creation of totallyindependent user communities, through the ability to create MultipleIdentity Management Realms within the one directory. Each Realm isa fully scoped area, which consists of a well-defined and independentset of user identities, security polices and groups.

By default, the values within a realm are only accessible toobjects/users also within the same realm. That is, a LDAP Query mayonly function within a given Identity Management Realm not acrossthem. Further more each Identity Management Realm has its ownOracleContext subtree and hence will have its own definitions of theSearch and Create base attributes.

As such, it may the very thing that makes Multiple IdentityManagement Realms useful for defining independent communitieswhich prevents their use for a Departmental Administration Model for

use with portal. That is their inability to share an application across theRealm. As the Groups used by Portal are held within the default realmit would not be possible for users in another Realm to be able to querythose groups or be made members of them. Likewise, the values of theSearch and Create bases would be pointing to the wrong area of theDirectory Tree.

Multiple Security Realms

cn=orcladmin

cn=PUBLIC

cn=portalcn=portal_admin

...

cn=Users

cn=dba

cn=authenticated_users

cn=portlet_publishercn=portlet_administrators

cn=rw_basic_user

cn=rw_power_user

...

cn=portal.nn.nn.nn

cn=groups


orclcommongroupsearchbaseorclcommonusercreatebase


...

cn=common

cn=portal

cn=IFS

cn=OCAcn=DAS

cn=wireless

...

cn=products

cn=OracleContext

dc=au

dc=MyCompany

dc=com

cn=orcladmin

cn=PUBLIC

cn=portalcn=portal_admin

...

cn=Users

...

cn=portal.nn.nn.nn cn=OracleContext

dc=us

dc=MyCompany

dc=com

orclapplicationcommonname=portal.nn.nn.nn

cn=Portal

cn=OracleContext

DSE Root

Realms are independent

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


8/22


Note: The Hosted Model for Portal does use multiple IdentityManagement Realms to define multiple hosted communities. Inthis case the Portal component is automatically copied to eachrealm. That is, each is still independent.

Segmenting a Single Realm As the functionality of the application requires the use of a singlerealm, a simple way to represent user communities is to convert the flatlist of users found in cn=Users, into a tree structure that represents theadministrative hierarchy. That is, create a subtree below the Userscontainer, 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 expressedas a hierarchy of containers (objectclass=orclcontainer) that mappedto the State, District and individual school.

A user at the Branch level therefore has the subtree below the branchas their defined scope of responsibility.

cn=orcladmin

cn=PUBLIC

cn=portal

cn=portal_admin

...cn=StateAdmin

cn=SD100Admin

cn=SD100-1AdminUser

cn=SD100-1AdminUser2

cn=SD100-1 Student1

cn=SD100-1 Student2

cn=SD100-1 Student3

cn=SD100-1 Student4

cn=SD100 School 1

cn=SD100-2 Admincn=SD100-2 Student 1

cn=SD100-2 Student 2

cn=SD100-2 Student 3

cn=SD100 School2

cn=SD100-3 Admincn=SD100-3 Student1

cn=SD100-3 Student2

cn=SD100-3 Student3

cn=SD100 School 3

cn=SchoolDistrict100

cn=SD100 Admin1

cn=SD200-1 Admin

cn=SD200 School 1

SD200-2 Admin

cn=SD200 School 2


cn=SD300 Admin

cn=SD300-1 Admin

cn=SD300 School1

cn=SD300-2 Admin

cn=SD300 School 2


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

cn=Us ers cn=groups cn=OracleContext

Realm

(dc=au,dc=DeptOfEducation,dc=gov)

DSE Root

Figure IV: Example Segmented User Subtree With Areas of Administration Privilege Highlighted.


9/22


As can be seen from Figure IV the user cn=StateAdmin is defined inthe cn=State1 container. That is, at the same level as the SchoolDistricts themselves, and as such they subsequently have those SchoolDistricts within their administration domain. The School districtAdmin 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 thedefinition of differently secured groups of users. (See below fordescript/and use of Access Control Items (ACI) to define appropriateaccess polices.)

Note: It is required that the segmented tree structure should be in placebefore the definition of the ACIs. If the OID server is not able toresolve a Distinguished Name referenced when the ACI is applied itwill fail and an error returned.

The fastest method to create a complex administrative hierarchy (asshown 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


10/22


objectclass: person

objectclass: organizationalPerson

objectclass: inetorgperson

objectclass: orcluser

objectclass: orcluserV2

mail: [email protected]

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 groupsallows the user to have global privilege to create and/or edit any user inthe system. This is based on the Access Control Policy defined on theUsers container and any created beneath it. As the goal of theDepartmental Delegation model is to limit an administrator to aprivilege scope, (in our case a School District and/or individualschool) it is necessary to remove direct privilege assignment to theOracleDAS Roles and implement a Privilege Group structure thatclosely represents the scope of privileges required. (The roles may berepresented either as a tree, as in Figure IV, or as a flat list.)

Note: As these groups will specify the access rights to thedirectory, they should be seen as Privileged Roles rather thanaggregation groups and hence should be created under theRealms OracleContext (e.g. cn=Groups, cn=OracleContext,dc=au,dc=DeptOfEducation,dc=gov).

Membership in these roles along with the use of Access ControlPolicies (discussed in next the section) will define the scope in which anadministrator has create/edit privileges. As such the following should

be defined;

An appropriate administration Role defined for eachadministrative level of the hierarchy. (e.g. cn=SD100School1 &cn=SchoolDistrict100)

The Administration user at each departmental administrationlevel is a Unique Member of the Role defined for that level.(e.g. cn=SD100-1 Admin)


11/22


Administration Group of the Parent is a Unique Member ofthose departments within it administration scope. (e.g.cn=SD100 Admin)

Each specified administrative role should be made aUniqueMember of the OracleDAS group relating to the desiredAction on the directory.

In order to allow for the definition of a Global Administrator able toaccess/manage users across each state subtree it is necessary to have aGlobal Privilege group defined.

The Global Administration Group (cn=GlobalStudentAdmin) is

A Unique Member of each Departmental Subtree Rootadministration 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 implementthe Department of Education example used in this white paper.

cn=Users cn=groups


orclcommongroupsearchbaseorclcommonusercreatebase


...

cn=common

cn=portal

cn=IFS

cn=OCA

cn=DAS

cn=wireless

...

cn=products

cn=OracleDAScreateGroup

cn=OracleDASEditGroup

cn=OracleDASDeleteGroup

cn=OracleDASCreateUsercn=OracleDASDeleteUser

...

SD100-1-Admin SD100-2-Admin SD100-3-Admin

cn=SD100-Admin

SD200-1-Admin SD200-2-Admin

cn=SD200-Admin

...

cn=SD300

cn=State1Admin cn=State(nn)Admin

cn=GlobalStudentAdmin

cn=Groups

cn=OracleContext

Realm

(eg. dc=au, dc=DeptOfEducation, dc=gov)

DSE Root

Figure V: Privilege Role Structure for Department Level User Provisioning


12/22


Note: While the departmental administration roles, will be usedto define the scope of user provisioning, it is important that theusers are still members of the Oracle DAS privilege groupsthemselves. This is due to the fact that membership in thesegroups determines the users ability to access the appropriateadministration 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 Portalsadministration page. Likewise, the hyperlink used to create a newuser is rendered only if the user is a member of theOracleDASCreateUser group (with Edit privilege they wouldstill see the portlet itself).

USING ACCESS CONTROL ITEMS

Access to the various nodes within the Directory tree is defined by theimplementation 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 thesubtree of beneath the node in which the Policy was defined. Whenthere is a security hierarchy, as in the School District example, withmultiple ACPs existing at different levels a subordinate container (such

as an individual school or student) will inherit the access policies fromall of the superior ACPs. Unless explicitly over ridden at a lower level.

Put simply, Access policies will be inherited down the branch, but theyare evaluated from the leaf back. That is, if access is denied at the rootnode, it can be reversed at a specific point without having to define thepolicy at each level in the hierarchy

The Departmental Delegated Administration model uses the ACI inthis manner to prevent school administrators from accessing containers(e.g. students from other schools) out side of their scope, while stillhaving full access to their own areas.

The access control directive may be defined against an entire Containeror specified against individual attributes within it.

The basic structure of the ACI is as follows;

OrclACI:

access to Entry | Attribute ([filter=(< ldapFilter>)]


13/22


by * | dn="expression" | group="" | 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 toaccess 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 Controlitems please refer to The Oracle Internet DirectoryAdministration Guide (Part III)

LDIF File exampledn: cn=Users,dc=au,dc=oracle,dc=comchangetype: modifyadd: orclaciorclaci: access to entry bydn=".*,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) ofthe Directory tree, the default Access Policies on the User container

need to be changed to match the Privilege role definitions describedabove. As ACPs are implemented down a directory tree, but accessrights evaluated from the leaf node (e.g. individual school) up thebranch to the root, this privilege may be achieved as follows;

1. Add an ACI entry filter to remove all access to the cn=Users, andentire subtree beneath it, to any user defined under theDepartmental Users container through an ACI entry filter.

e.g.dn: cn=Users,dc=au,dc=DeptOfEducation,dc=govorclaci: 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)


14/22


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 OracleDASprivilege 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, Proxyprivileges on the cn=Users container to the New GlobalAdministrator Privilege role defined.

e.g.dn: cn=Users, dc=au,dc=DeptOfEducation,dc=govorclaci: access to entry filter=(objectclass=inetorgperson)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 newGlobal Admin Role the same attribute privileges previously heldby the OracleDAS privilege groups

e.g.dn: cn=Users, dc=au,dc=DeptOfEducation,dc=govorclaci: access to attr=(*) filter=(objectclass=inetorgperson)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 togrant Browse, Add, Delete, Proxy privileges to the appropriateadministration group defined.

e.g.

dn: cn=SD100School1, cn=SchoolDistrict100, cn=State1, cn=Users,dc=au, dc=DeptOfEducation, dc=govorclaci: access to entry filter=(objectclass=inetorgperson)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)


15/22


7. Add an ACI Attribute filter on the individual school container togrant attribute Read, Write, Search, Compare privileges to theappropriate administration group defined.

e.g.dn: cn=SD100School1, cn=SchoolDistrict100, cn=State1, cn=Users,dc=au, dc=DeptOfEducation, dc=gov

orclaci: access to attr=(*) filter=(objectclass=inetorgperson)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 reachingthe level of the Global Admin.

Note: The Oracle Internet Directory 10g supports the definitionof multiple orclaci attributes in a single container (one after

another). However, this can lead to unpredictable results wherethe Access Policies defined result in a contradiction.

As such it is recommended to update the current orclaciattributes on the cn=Users container rather than simply add newACI attributes to the container.

USER PROVISIONING

One of the major advantages of centralizing the scope of the Directorythrough the use of ACIs, is that it dramatically reduces the requirementfor the application (or even to a degree, the end user) to be aware ofthe segmentation of the user community.

Finding Users (within limits)

The LDAP search syntax requires the definition of a point in thedirectory tree from which to start the query (the basedn). Likewise,one has to define the scope of the query. That is, how many levels ofthe tree should be accessed in order to satisfy the query criteriaspecified.

Scope = base (the container specified by basedn) | one-level (itsimmediate children) |subtree (the entire subtree from the basedndown)

As the default scope is to traverse the entire sub tree, it removes theneed to define a separate starting point for each School district and/orschool. By starting at the top node (cn=Users ) we can perform asingle open query across all schools and effectively traverse all students. The impact of the ACIs defined above, and the current usersmembership of a given privilege group, is to effectively skip any node


16/22


to which the current user does not have Browse privilege. Resulting ina result set that maps to the District/Schools to which they haveresponsibility. Thus, from the applications perspective thesegmentation of the tree is transparent.

Access to the appropriate list of students is greatly simplified within thePortal by use of the User provisioning Portlet. When the Portlets

LOV icon is clicked, the DAS LOV component uses theOrclCommonUserSearchBasedefined for the realm, as the startingpoint for its LDAP search. Hence, without having to modify the LOVor the portlet, the list of students returned will be scoped to the area ofresponsibility of the current administrator.

User Creation within the correct departmental location

Whereas the implementation of a segmented user tree has little effecton the LDAP searching functions of an application, the same cannotbe said for creating a new user in the system.

By default the OrclCommonUserCreateBase points to thecn=Users container, and hence the DAS console will open pointing tothat location, and explicitly try to create the user there. As ACIspreventing browse and write capability have been associated with thiscontainer, an error would occur when the new student was submittedto the directory. Hence for the creation of new users into thesegmented User tree (in this case students into different schooldistricts/schools), it is necessary for the application to explicitly definewhere, based on the current administrators scope, the new user shouldbe created.

Figure VI: Segmentation of the User Community is transparent to the LDAP Query


17/22


Note: Oracle Internet Directory supported the definition ofmultiple values for the OrclCommonUserCreateBaseattribute.If multiple values are defined, the DAS console presents the user with a pop-list of full DNs as possible locations in which tocreate the user.

Likewise the parent DN may be determined by setting multiplevalues for the organizational unit (ou) attribute (as a list). Theadministrator may then choose the organization unit under whichto place the new user. For a limited number of locations, andwith Directory aware end-users, these options may suffice, henceremoving the need for further customization.

Although the application is now explicitly defining where the user is tobe created, if a location is chosen to which the current administratordoes not the appropriate privileges, the action is disallowed and anerror returned. Hence the security of the DIT is maintained. (This isalso 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, theapplication should determine the administration scope of the currentuser and present only those locations, which would be valid. Forexample a School district Administrator should be presented with a listof 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 schools

administrator should be directly inserted into the container for thatschool.

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 thefull DN of the user (by default the RDN will be the SSOusername).

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 thecurrent administrator, by querying for the DNs of thebrowsable container nodes in the subtree.


18/22


Search base: DN of Parent Container

Search Filter: objectclass=orclcontainer

4. Once the appropriate location is chosen the application needonly define the DN of the new user in the appropriate LDAPadd command. Therefore preventing an attempt to create a userin an invalid location.

Prevention of Duplicate Usernames

The Oracle Single Sign On environment requires that every usernamedefined in the system is unique, and when all users are co-located in thesame container (cn=Users) this is a fairly straightforward exercise, asthe Directory automatically prevents duplicate Distinguished Names.However in a Departmental delegation model, where each local Adminchooses the username, there is a high likelihood of collision on the username space. For example, in the case of a School system, it is mostlikely that there will be two or more students with the same name

somewhere in the system (if not, the same school). As such, extrasteps must be taken to prevent the creation of duplicate Usernameentries.

Note: OID by default will not prevent this, as the full DistinguishedNames of the students will still be Unique. However the SSO serverrequires 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 SSOcredential (normally cn=username) by use of a uniqueattribute constraint in the Directory Information Treeitself.

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 ofFirstname.Initial.Lastnameis generally acceptable with a small user base, with a large populationit is unlikely to be sufficiently granular to ensure uniqueness. It isthen necessary to append an appropriate suffix (or Prefix such as theschool or district ID) to uniquely identify the student (this can beseen in such Public Websites as Yahoo!, MSN etc.)

The unique attribute constraint, as the name would suggest, preventsduplication of an attribute value, both when adding the entry and whensubsequently if it is edited. If a duplicate value is identified for theattribute in question, the operation is cancelled and an error returned tothe user. In this manner an administrator can be alerted that the nameby which they are registering a student is not unique.


19/22


Note: Use of a School or District based Prefix would greatlyreduce 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 createdunder the Directory Trees root OracleContext (cn=unique,cn=common, cn=products, cn=oraclecontext) naming the attribute tobe monitored, the scope of uniqueness and optionally to which objectclass 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 Districtsdefined beneath it. The nickname attribute is used to define the SSOusername 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=oraclecontextobjectclass: orclUniqueConfigorcluniqueattrname: uid

orcluniquesubtree: cn=Users,dc=au,dc=DeptOfEducation,dc=govorcluniquescope: suborcluniqueobjectclass: InetOrgPerson

Note: For a further description of the Syntax of AttributeUniqueness Constraints items please refer to The Oracle InternetDirectory Administration Guide (Chapter 8).

Using DAS Console for the Provisioning Interface

While the needs of a specific user community may require a fullycustom interface, the creation of the provisioning UI against asegmented User tree is greatly simplified by the ability to dynamicallyspecify where the DAS console will attempt to create the new user.This is achieved by adding theparentDN argument to the URL issuedto launch the console. The value of which is the full DN of thecontainer in which the user will be created.


20/22


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 thatspecified in the User Search base.

For further information on the available URL arguments to use withthe DAS console please refer to the Oracle Internet Directory,Application Developers Guide 10g(9.0.4).

Note: The use of the parentDN argument with the DASconsole is currently only documented for the creation of Groupswithin the Realms Group container. Given the default container

structure for Users is flat, and not hierarchical, the use of theparentDN argument in the provisioning of users has not beenfully tested by the DAS development team and may result ininconsistent behaviour.

Departmental Provisioning within OracleAS Portal 10g

The User portlet on the Portal tab under the Administration linkenables the creation and subsequent modification of users throughcalling a service unit (sub-set) of the DAS console. The standardportlet will, as previously discussed, will support the querying of users

in a segmented tree; it will not support the creation of a user. Howevermodification of the Portlet using the steps defined above enables boththe query and provisioning of users to be exposed through the samesimple interface.

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


21/22


Figure VII shows this modified functionality, where the current userssphere of responsibility is exposed in the Portlet. By selecting theappropriate location prior to clicking the Create New Users link, theSchool district administrator can automatically provision the user at theappropriate point in the tree. For individual school administrators the

UI appears as per the normal portlet and the Student is explicitly placedin the appropriate school container.

Note: The location displayed in the User Interface may be basedon the Relative Distinguished Name, however for ease ofunderstanding (the common name (cn ) may not be descriptive)the containers Description Attribute may be used, as is the casein Figure VII.

CONCLUSION The explosive growth in the number of users having to be managed within an organizations Identity management Repository, has leadmany administrators to look at Self-Service as the solution to theProvisioning bottle-neck. The primary concern has always been one ofsecurity. How can the central portal administrator allow individualdepartments the ability to provision users (with all the rights thatentails) but at the same time limit the scope to only the departments inquestion?

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 inwhich user provisioning is moved out to the organizations to which theusers belong, while allowing the information to remain a centralizedresource.


22/22

The Implementation of a Departmental User Provisioning Model in OracleAS Portal 10g

November 2004

Author: Barry HiernContributing Authors: Paul Encarnacin, 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 trademarksof 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

Documents