Hi Tom,
We are currently working on designing a security model for a university systems. The university has the following systems.
- HR
- Students Registration
- Inventory
- Library
Currently, they are using these systems which are developed using Oracle Forms and Reports. The end user logon to one form which displays a tree for the systems the end user has access to them. However, the security model is enforced on the application only, while at the database level the user has a full access to all tables on all systems. This is accomplished using one Role which (Select Any.....) system privileges.
Our task now is to design these legacy systems using Oracle JDeveloper to replace Oracle Forms and the reporting tool is BI Publisher as a replacement for Oracle Reports. Therefore, we decided - as first step - to redesign the security model using Oracle Best Practices. However, the following needed to be in mind when we need to design the security model for the systems mentioned above:
Users belong to groups, for example: deans, managers, secretary... etc
A group of users, say secretary, will have the same privileges on all systems mentioned above.
Some users within the same group may have more or less privileges. For example, a secretary might be granted a privilege for Order Entry system. This privilege is ONLY for this user, not the whole group. Also, the reverse is true, a privilege might be revoked from specific user, not from the whole group. For example, a secretary might not be allowed to use specific report while it is still allowed to the rest of the group.
Also, some users will have insert, update and delete on tables but with specific rules. For example, consider a table for leave permissions. The user in the secretary is allowed to insert a record as a leave permission as follows:
Emp_no leave_date_time return_date_time status
1111 01/05/2012 10:00 a.m. pending
Then, when he/she return back, the user is allowd to update the record to enter the return information
Emp_no leave_date_time return_date_time status
1111 01/05/2012 10:00 a.m. 01/05/2012 12:30 p.m. completed
Now, the manager of this employee, can only *update* this record after its status is completed to approve it. The manager will have an update privilege on this table for the records with *completed* status
Therefore, technically, we thought of the following:
- The system will have a schema called "sec_man", this schema will have tables for users and their groups and the privileges to these systems.
- Users are all database users, they all connect to the database through a proxy user. The proxy user establishes the connection pooling between the application server and the database.
- Business Logic is implemented in PLSQL Packages with invoker rights
- Security is enforced using Secured Application Roles
- Data Access is enforced using Oracle Virtual Private Database (VPD)
Roles here represents groups of users. Also, Roles are enforced from trusted package, they are secured.
VPD will handle the specific update, delete, insert and select privileges for users. The policy function will determine the right *WHERE* clause for each user.
However, I still do not know to how to handle the exceptions inside each group, I mean, how to grant a user an additional privilege that does not exist for the rest of the group as I have explained before.
Also, we are little worry that using Oracle Roles to implement the security model will not helpful due to the exception happened inside each group as explained above. Therefore, some of the team are thinking to grant the users the EXECUTE privilege for the PLSQL packages using owner rights, and inside each package, the developer will restrict what the user can do inside the PLSQL code within the package.
I am still fan of using Oracle Roles, Secured Application Roles along with VPD. On the other hand, some of my team worry that this model will be very costing and complicated in implementation.
I have reviewd the Security Guide Book
http://docs.oracle.com/cd/E11882_01/network.112/e16543/authorization.htm especially chapter 4 and 5, but I still feel they did not give me the complete picture.
If you were working on such a project, how would you implement the security model?
Regards,
Emad
May 12, 2012 - 11:18 am UTC
However, the security model is
enforced on the application only, while at the database level the user has a
full access to all tables on all systems. This is accomplished using one Role
which (Select Any.....) system privileges.
In short, there is no security beyond obscurity.
- Business Logic is implemented in PLSQL Packages with invoker rights
I would strongly discourage that - strongly. I would not use invokers rights like that. I would only use invokers rights for "utility" type of routines or certain administrative packages - infrequently executed code.
Roles will deal with who can run which code.
VPD will deal with what that code can see and do.
You do NOT need, want, nor desire invokers rights routines.
I am strongly against it.
I mean, how to grant a user an additional privilege that does not exist for the
rest of the group as I have explained before.
that is done via grants?
The role X has execute on A,B,C - but the user Mary needs Role X AND execute on D. Just grant????
And then just revoke???
You have proxy users - you have access to all of the grant/revoke code of the database - that is the beauty of proxy users - you don't have to re-invent an entire security model.
Therefore, some of the team are thinking to grant the users
the EXECUTE privilege for the PLSQL packages using owner rights, and inside
each package, the developer will restrict what the user can do inside the PLSQL
code within the package.
I am still fan of using Oracle Roles, Secured Application Roles along with VPD.
On the other hand, some of my team worry that this model will be very costing
and complicated in implementation.
Oh my gosh - your kidding - they think using grant and revoke will be overly complex - but that by RE-IMPLEMENTING THE ENTIRE SECURITY MODEL OF THE DATABASE - it will be easier?
Seriously? I mean it - Seriously?
You are using database users (yay!)
You have access to roles, grants, revoke (yay!)
coupled with VPD to make it so that even if user X can run process A, process A is limited to act on only the data user X is allowed to X (yay! yay!)
all without having to write any code really (short of the vpd functions) to do this - regardless of who writes the code in plsql or in the client (this - this fact - is important)
It doesn't matter how smart or not the developer is about the security rules - they cannot violate them - new code, old code, refactored code.
In order for any developer to write any code in this system - they would have to be more than expert on the entire security model and you would have to trust them to enforce it correctly
and when and if (or just when is more likely true) the model changes - you don't have to inspect every line of code to figure out what needs to change. You change the roles, the grants, the vpd and it is just done.