Well ... in general it's the apps that manage the system security, and
the DB users are there to prevent the app users from doing damage, but
in general these two work in unison. 

I have not seen any "decent" ways of having the DB administer users
without there being a serious overhead, in terms of administration
duties, for the DBA (which is what Jared mentioned). 

I say that, given the information you provide, sticking with the two
types of roles (owner and user) is the most adequate way. 
Why would you want to change this anyway?

My 3.14159 pence worth.


-----Original Message-----
Jared Still
Sent: Saturday, November 29, 2003 9:15 PM
To: Multiple recipients of list ORACLE-L

Steve,

I'm not a web developer either, but I do know that this
is a very common method of handling the database connections.

Many 2 tier apps work this way as well.  SAP for example.

Unless you have influence on the architecture and can
present a convincing argument, you best learn how to
work with it.

You don't give any details about the app either.

Are users required to authenticate?  If not, what would
be the point of requiring db accounts for them?

The number of users is important as well.

Imagine a web app that services 250k users.  Do you
really want that many users in the data dictionary?
Would you want the DDL overhead of creating/administering
that many users?

I'm considering some extremes, because there were no
details provided.

HTH

Jared


On Sat, 2003-11-29 at 19:49, Steve Perry wrote:
> I hope somebody on the list can help me out with this.
> 
> All of our 3-tier apps are architected with a schema owner (owns all
objects
> used by an application) and application user (no create privs, but it
does
> have full dml privs to the schema owner objects).
> On the web side, connection pooling is setup with 10 connections
logged in
> (all as the application user).
> When users connect, the application reads some active directory keys
that
> tell if the user is a reader, dml user or admin user (all privs).
> 
> I don't feel the application should be managing security and I'd like
to
> take that responsibility away.
> The 10 identical connections logged into the database bothers me too.
> 
> I'd like to make it work similar to our 2-tier apps where we use
roles,
> assign them to a user and they connect individually. We don't have OID
setup
> and I imagine that would solve this. Short of that, is there any other
way
> to work around having the 10 identical connections logging in and
having the
> application maintaining security? Is there another way of assigning
the
> security?
> 
> I don't have any web development experience and I thought I'd check
here
> first to see how others deal with this.  I  hope somebody else has
worked
> this out at their shop.
> 
> I'm not sure if the answers will change, but it's an all M$ shop,
except for
> Oracle.
> 
> Any help would be appreciated.
> Steve
> 
> 
> -- 
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> -- 
> Author: Steve Perry
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
> San Diego, California        -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from).  You may
> also send the HELP command for other information (like subscribing).
> 


-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jared Still
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: nelson flores
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to