ODI11g - Mixing the Security "models" for Authorisations Assignment

With Oracle Data Integrator 11g, Oracle extended the Authentication capabilities to be applied to the ODI users. In this post, we will focus on the Authorisation aspects that Oracle Data Integrator inherited from the Sunopsis era. In this inherited approach, the ODI application is implementation with several Security Profiles enabling 'Generic' or 'Non Generic' authorisation profiles. With a 'Generic' profile, the user will have the ability to apply the provided 'methods' to all 'instances' of the object 'class'. For instance, when the method 'delete' is provided for object type 'datastore', the user being assigned  this Generic profile will have the ability to apply this method to all datastores. From an administration perspective, this type of profiles are requiring little effort once the users are created with such profiles assigned to them.   With a 'Non Generic' profile, the user will only have the ability to apply the provided 'methods' to the 'instances' of the object 'class' assigned to him/her by the security administrator. For instance, when the method 'delete' is provided for object type 'datastore', the user being assigned  this Non Generic profile will only have the ability to apply this method to datastore 'SRC_ORDERS' that has been added under his/her user definition , Instances node. From an administration perspective, this type of profiles are requiring more effort once the users are created with such profiles assigned to them.   A logic like "provide ability to apply the method(s) to all objects except some specific ones" is not immediately available.
Nevertheless, in order to alleviate the administration burden of going for the implementation of 'Non Generic' profiles, the security could look for mixing the 2 approaches. Let's assume several development teams are using the same Work Repository (type Development) and one would like to have each team only operating the objects within a given project.   In our example, we have 2 projects (DEMO_01, DEMO_02) and 2 teams materialized by 2 users, where USER01 would belong to Team 01 and USER02 would belong to Team02.	Fig.01
And for each team, one wants them to have full access to the underlying objects in the Project tree.   From an ODI security perspective, this would be translated as: I want Non-Generic rights for the Project object class and I want Generic rights for all other objects (Interfaces, Packages, Variables, Procedures, ...) under this point in the tree.	Fig.02
In the Security Navigator, we would then in the Profiles part, pick up the existing 'DESIGNER' profile and duplicate it under the name 'DESIGNER_PROJ'.	Fig.03
We would then  . expand the 'Designer_Proj' profile to  . locate the 'Project' node , expand it too and then for each method (assuming we want to kept all methods from the original definition), we would uncheck the [ ] 'Generic Privilege' box on the Definition tab of the methods.	Fig.05
We then, if not done yet add USER01 and USER02 under the 'Users' module. For each user, we assign - drag and drop - the 'Connect' profile and the newly created 'Designer_Proj' profile to the users.   We then move the 'Security Navigator' (clicking on the icon on the header bar) from the menu (for us on the left side of the ODI Studio) over the Workspace area in order to have both the Designer Navigator (left in the menu) and the Security Navigator (right in the workspace) visible.   We then drag and drop the project instance 'DEMO_01' onto the 'USER01' node in the Security Navigator. We are asked to confirm granting this project to this user, what we do.	Fig.06
A window is then automatically open in the workspace for you to activate the methods for this object's instance. Your may choose between 3 possibilities:  . Allow all methods in all repositories  . Deny all methods in all repositories  . Allow all methods in selected repositories For this example, we 'Allow all methods in all repositories'.
We may then disconnect and (re)connect as USER01 to have a try at the behaviour. The users (as shown on Fig. ) were also assigned the complementary - and original - profile 'METADATA_ADMIN'. This profile provides a 'Generic' View method on the 'Project' class.   We duplicated the profile 'METADATA_ADMIN' to create a  profile 'METADATA_ADMIN_MODELS' without View method on Project and replaced the Metadata profiles on users with the newly created one.   The complete users' profile settings would not be completed at this stage. Nevertheless, as a matter of conclusion, this demonstrates that there are plenty of configurations available (not out of the box unfortunately) in order to mitigate Security requirements and administration burden.