Cohabitation/Migration ODSEE->OUD: privileges

OUD provides a privilege subsystem, which can be used to define capabilities that will be granted to users. The privilege subsystem works in conjunction with the access control implementation in the process of determining whether a user will be allowed to perform a certain operation.

In general, default OUD access control settings are stricter than ODSEE. Appropriate privileges must be added to achieve behavior that is equivalent to that of ODSEE. For instance, by default, OUD ACIs don’t allow users to reset another users’s password. Alternatively, it is possible to disable the privilege subsystem.

By default, normal users are not granted any of the privileges listed above. Therefore, if a user should be allowed to perform any of the associated operations, they must be granted the appropriate privileges. This can be done by adding the ds-privilege-name operational attribute to the user's entry. ds-privilege-name is a multivalued attribute, and if a user is to be given multiple privileges, then a separate value should be used for each one. When the virtual attribute subsystem is in place, it should also be possible to grant privileges to groups of users automatically by making ds-privilege-name a virtual attribute in those user entries.

As an example, the following modification can be used to add the proxied-auth privilege to the user cn=Proxy User,dc=example,dc=com:

dn: cn=Proxy User,dc=example,dc=com
changetype: modify
add: ds-privilege-name
ds-privilege-name: proxied-auth

Granting privileges explictely to users may not be the optimal solution when OUD and ODSEE cohabit in a replication topology as the OUD-specific ds-privilege-name would be replicated by to ODSEE, so privileges can also be assign implicitely to a set of user based on group membership for example, using the notion of virtual attribute. I'll cover Virtual attribute in a subsequent post.

Alternatively, It is possible to disable those privileges leading to aci behavioral differences between OUD and ODSEE. For instance, the  unindexed-search privilege can be disabled  so that users can perform un-indexed searches. A privilege (unindex search checking in the example below) can be disabled using the following command:

dsconfig
set-global-configuration-prop  --add \
disabled-privilege: unindexed-search -n

The list of OUD privileges is available here.

Comments:

Is there any web management GUI for OUD? last time I checked you need to use odsm which dose didn't include any replication status like ODSEE's console (ODSCC).

Thanks,
-Eli

Posted by Eli Kleinman on May 03, 2012 at 02:45 PM CEST #

Replication monitoting is not integrated with the current version of ODSM (OUD Web Admin Console). Replication status of the entire topology can be simply monitored using the dsreplication status command as described in http://docs.oracle.com/cd/E22289_01/html/821-1273/configuring-data-replication-with-dsreplication.html#scrolltoc

Posted by sylvain duloutre on May 11, 2012 at 12:41 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
About


I am Sylvain Duloutre, I work as a Software Architect in the Oracle Directory Integration Team, the customer-facing part of Directory Services & Identity Management Product Development, working on Technical Field Enablement.

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
9
10
11
12
13
14
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today