Re: .NET, connection pooling and security .

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" <ORACLE-L_at_fatcity.com> 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: sperry_at_sprynet.com
> >
> > 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: ListGuru_at_fatcity.com (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: jkstill_at_cybcon.com
>
> 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: ListGuru_at_fatcity.com (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: nflores_at_expand.cl
>
> 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: ListGuru_at_fatcity.com (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: sperry_at_sprynet.com

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: ListGuru_at_fatcity.com (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).