Role base Security

Question

Hello,
My question is I want to create a role which should make sure through this role if a user is an authorized user, and logging from authorized server(could be IP verification).  once the condition satisfies through this role, then it should enable the for that particular user can select or update objects from that user.
say for example,  USER "A"  has access to "TEST" schema in a test database.
there is 1 role test_a which has select privileges on TEST schema objects, which is granted to User "A".
Here I want to check first through another role say for example CK_TEST role which should make sure if User "A" is an authorized user, if so is user "A" logging from authorized client or server, if so then enable the TEST_A role to User 'A".
can someone give me an example how toaccomplish this.
Thanks a lot....

Answer 1

I'm assuming that user A is a database user, not an application user.  If that's the case, what does it mean for A to be an "authorized user"?  If the session has been created, then A must be a valid database user and whoever is logging in must have provided the correct password.  If A has been granted the TEST_A role, what more is required for A to be an "authorized user"?
Having the database verify that a client is "authorized" is a bit problematic simply because the client is providing all the information that you'd be checking in the database.  An attacker could easily spoof or change their IP address, for example.  Validating the IP address can be useful if you want to prevent people from doing things inadvertently (i.e. preventing a DBA from inadvertently logging in to prod from their laptops if that's something that you want to avoid) but isn't particularly good at preventing attackers from getting in.
You can make TEST_A a password-protected role.  You can create a VPD policy on the objects in TEST that requires a user to call a procedure that you've defined that does whatever validation you want before setting the context to allow access to the data in those tables.  You can create a logon trigger that tries to prevent users from logging in from the "wrong" IP address (with the caveats above that this isn't particularly good at keeping attackers out).  Or you can restrict what machines can access the database at the SQL*Net layer or, preferrably, by putting a firewall in front of the database.
Justin