Re: Dynamic Default Roles ?

From: David Sidwell <dasidwel_at_us.oracle.com>
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

Original text of this message