Re: Dynamic Default Roles ?
Date: 1995/06/16
Message-ID: <dasidwel-1606950943410001_at_dasidwel-mac.us.oracle.com>#1/1
In article <1995Jun15.002155.20394_at_nosc.mil>, dbrewer_at_nosc.mil (Dennis Brewer) wrote:
> joe_at_access4.digex.net (Joe Nardone) wrote:
> >Dennis Brewer (dbrewer_at_nosc.mil) wrote:
> >: Fact1: Every user that logs in is assigned a defult role.
> >: Fact2: Some users wear different hats when logging onto the
database. This requires
> >: different role assignments bases on the current
application and session.
> >: Fact3: Each time a user logs on a session is started with an entry
in the v$session table.
> >: Question1: Does it put an entry in the v$session table, before the
default role is enabled?
> >: Question2: Can a trigger be placed on the v$session table?
> >
> >[snip]
> >
> >Why couldn't the users be assigned all the roles they need as their
> >default role? I don't quite understand the dilemma here.
> >
> >Joe Nardone
> >
> >
> >
> >--
> >
> >=------------------------------------------------------------------------=
>
> Joe
> Look again at fact 2: In our organization I can log in using an
application as the head
> of my division. Now as the head of my division I have access to many
more attributes
> than say a lowly clerk. In this case I would have a default role that
would reflect my
> grants and priviledges. One hour later I can again log on using a
different application.
> This application is using data from another division, now I am a lowly
clerk as far
> as this other division is concerned. My default role at this time should
be highly
> restricted.
> This is a Military Base, and as such not all users are created equal.
However a user
> could be granted many different roles based on the applications in use
at the moment.
> Many key individuals have applications that cross over into other areas
of data. This is
> the reason that the default role should be dynamic.
Dennis,
Shouldn't the roles differ between divisions ?
Instead of having a HEAD_OF_DIV role with all-powerful grants to it, why not subdivide this into HEAD_OF_DIV1, HEAD_OF_DIV2 etc. ? You would then be granted HEAD_OF_DIVx and CLERK - both as default roles.
This really has nothing to do with whether a role is a DEFAULT role or not. It is simply an exercise in least privilege reduction.
The main point is that there is really no more protection in granting someone a non-default role than there is in granting a default role. A grant is a grant and a non-default role can be enabled. The only exception to this is if the role is password protected and the grantee does not know the password. In that case you have a password management problem as it must be embedded in the application - or somewhere accessible to the application and not to the end user. Received on Fri Jun 16 1995 - 00:00:00 CEST