I like the idea of roles and that's what I'm trying to get at, but the app determines the user's authority prior to connecting to the database by looking at a key in active directory. The database connections have to connect as the highest level user possible, which is the application admin. I don't like that because it seems like a security hole. Like I said, I'm not real comfortable with Web security and may be making something out of nothing.
thanks. ----- Original Message ----- To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Saturday, November 29, 2003 11:44 PM > 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). -- 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).
