|
Jack,
Question - why do you want to use System triggers
to change roles? I don't see how you can define an event for this trigger to be
fired. If the event is the updating of record in USERS table, who updates it?
Obviously not the user himeself; then the whole system becomes insecure to the
core.
Your choice of using a role to allow access to a
specific yesr is sound design. I assume each year is stored in separate tables.
If that is not correct, i.e. the record for all years are stored in a single
table, then roles will not help you, you need to enable FGAC using something
called application context.
Scenario 1: Each year's data is stored in a seprate
table.
You would create roles, but not normal roles. The
roles should be identified by a procedure. This procedure is owned by SYS or
some other secued schema. Inside this procedure you would assign a value to the
application context attribute called user_role, which is set via
dbms_Session.set_context. All the users are revoked execute priv on
dbms_session; so they will never be able to call this procedure directly. The
only way they can do it is by calling the trusted procedure you have defined for
that role.
Scenario 2: All the tables have data for all the
years.
Inthis case you will have to use FGAC; but the FGAC
policy will have to depend on the application context you defined earlier. You
wil define another context attribute called school_year, whic is again set by
the trusted procedure of the role. Since the user does not have the privilege to
call dbms_Session, he will not be able to set the value of this attrbute to any
other year at will.
Summary:
You will define several roles ideintified by
procedure. All these roles are granted to the user but none is a default
role.
When a user logs in, all roles assigned to him are
disabled, since none is a default role. Then he calls the procedure set_role(),
no arguments. Inside the procedure set_role(), you will read the users table,
see the role the user is supposed to have, enable this role via
dbms_Session.set_role and then set the application context, if any.
Since the user does not have execute privs on
dbms_session, he will not be able to set the app context.
Since the role is identified by a procedure, i.e.
set_role(), the user will not be able to set the role himself using "SET ROLE"
command in sql*plus. The only way he can do that is by calling the set_role
procedure.
If the user does not call the procedure, none of
the roles are enabled; therefore he will not be able to do
anything.
In other words, you have a secured
system.
As an added bonus: you will have the application
context attribute you can use any way you want to use. Right now you can use it
for FGAC; but later when you are in 9i, you can use it in other cooler features
such as Fine Grained Auditing.
HTH.
Arup Nanda
|
- Set Role in Trigger JApplewhite
- RE: Set Role in Trigger Arup Nanda
- RE: Set Role in Trigger Pardee, Roy E
- Re: Set Role in Trigger Arup Nanda
- Re: Set Role in Trigger Tanel Poder
- Re: Set Role in Trigger Arup Nanda
- Re: Set Role in Trigger Tanel Poder
- Re: Set Role in Trigger JApplewhite
- Re: Set Role in Trigger Arup Nanda
- RE: Set Role in Trigger Pardee, Roy E
- Re: Set Role in Trigger JApplewhite
- Re: Set Role in Trigger Jared Still
