On Feb 22, 7:54 pm, "foothillbiker" <foothillbi..._at_gmail.com> wrote:
> On Feb 22, 4:46 pm, "Valentin Minzatu" <valentinminz..._at_yahoo.com>
> wrote:
>
>
>
>
>
> > On Feb 22, 7:05 pm, "foothillbiker" <foothillbi..._at_gmail.com> wrote:
>
> > > On Feb 22, 1:32 pm, "Valentin Minzatu" <valentinminz..._at_yahoo.com>
> > > wrote:
>
> > > > On Feb 22, 4:20 pm, "foothillbiker" <foothillbi..._at_gmail.com> wrote:
>
> > > > > All,
>
> > > > > we have the standard
> > > > > web client<==>app server<==>db
> > > > > arrangement.
>
> > > > > We're using fgac (or vdb if you like) to control what data is visible
> > > > > based on who the oracle user is. The end users are created like this:
>
> > > > > 15:53:47 system SQL> CREATE USER jblow
> > > > > 15:54:34 2 IDENTIFIED BY unknownpassword
> > > > > 15:54:57 3 DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp
> > > > > 15:55:15 4 /
>
> > > > > User created.
>
> > > > > 15:55:17 systemSQL> GRANT CREATE SESSION TO jblow;
>
> > > > > Grant succeeded.
>
> > > > > 15:56:12 system SQL> ALTER USER jblow
> > > > > 15:58:51 2 GRANT CONNECT THROUGH midtierappuser
> > > > > 15:59:05 3 /
>
> > > > > User altered.
>
> > > > > That all works fine.
>
> > > > > The app is in java, the db is 10.2.0.2
>
> > > > > My question/comment/concern:
> > > > > Since jblow's account is proxied through midtierappuser, jblow's
> > > > > actual oracle password is irrelevant.
>
> > > > > *** THE ISSUE: what's to stop
> > > > > jblow
> > > > > from logging in as
> > > > > dman
> > > > > and getting all the priv's of the dman's account?
>
> > > > > Basically, it seems that anybody can log in under whatever id they
> > > > > want, they just need to know the username.
>
> > > > > We could prevent this situation by asking jblow to provide a password
> > > > > which we validate somehow before passing the connection request off to
> > > > > midtierappuser. But surely there's a better solution that that...
>
> > > > > I've read the asktom posts:
> > > > > http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1...
> > > > > http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:9...
> > > > > but they don't really address the issue.
>
> > > > > Thanks for whatever help you might offer.
>
> > > > > REgards,
> > > > > Chas.
>
> > > > I hope I understood properly the questions.
>
> > > > Authorization: at the VPD/FGAC level you can handle not only user
> > > > session related constraints, but also context related ones. So, let's
> > > > say that you can ask the middletier to pass in for each real
> > > > (physical) client their identity you can base VPD/FGAC rules on that
> > > > criteria and not allow anybody to "see" more data than they are are
> > > > entitled to.
>
> > > > For the authentication part, you could pretty much use what you like
> > > > as long nobody gets access to the rest of the data until they have
> > > > passed through FGAC filters.- Hide quoted text -
>
> > > > - Show quoted text -
>
> > > Valentin/All,
>
> > > VPD/FGAC works fine -- no issues there.
>
> > > The issue is that since the proxy authent goes through midtierappuser
> > > (an oracle user account which logs in when the appserver starts) that
> > > means that end user passwords are irrelvant, and that (afaict) there
> > > is nothing stopping UserA from logging in to the application as UserB.
>
> > > UserA just has to know the username of UserB.
>
> > > If it matters, we're using jdbc thin drivers, and a product called
> > > "Hibernate" for the app.
>
> > > Thanks.
>
> > > REgards,
> > > Chas.- Hide quoted text -
>
> > > - Show quoted text -
>
> > That is because you have configured it such way that it is filtering
> > based on the USER.
>
> > Let's say that all your tables have a column (hidden or not from the
> > application) which identify the owner of the data. The column is
> > populated using values which are not the username. Then once the user
> > is authenticated, you can store as part of the session context (even
> > transparent to the application) that ID (in lack of a better term)
> > which allows only that user - due to VPD/FGAC - to get access to his/
> > her own data and nothing else - you can come up with other variations
> > as well.
>
> > Have I misunderstood your question?- Hide quoted text -
>
> > - Show quoted text -
>
> Valentin,
>
> Let's just forget about VPD/FGAC for this discussion b/c it is not the
> concern -- it works just fine.
>
> The concern is that if we use proxy authentication (users are
> authenticated by midtierappuser) then user *passwords* are irrelevant.
>
> The scenario I want to avoid is anybody at all can bring up a login
> screen, type in a legitimate username, and they are in, without a
> password.
>
> REgards,
> Chas.- Hide quoted text -
>
> - Show quoted text -
Ok. Correct me if I am wrong: the middle tier account (jblow I think
it was) has access to *nothing*. Then, the end user (the guy in front
of the web page) types in a username and a password which allow his
session to proxy into the Oracle account giving him access to his
data. I do not see why the password is irrelevant. What have I missed?
Received on Thu Feb 22 2007 - 19:08:26 CST
