oracle - authenticate with username and password

Thread view:

dave - 11 Jan 2008 19:40 GMT

Hello,

I need to authenticate users based on their oracle username and
password.

I get the username / password from a web form.

Is there some oracle java library that will allow me to perform a
check on the username and password?

I could just create a JDBC connection to the database with their
information, but I'm thinking that this could fail for reasons other
than incorrect username/ password. I want a way to verify username/
password only.

Thanks

Reply to this Message

Donkey Hot - 12 Jan 2008 01:55 GMT

dave <dave8421@hotmail.com> wrote in news:d1369398-8348-4486-85a1-
327ef0e3d9a2@u10g2000prn.googlegroups.com:

> Hello,
>
[quoted text clipped - 12 lines]
>
> Thanks

No such way in Oracle, I think.

In MySQL you could have one connection to the db and use something like

SELECT COUNT(*) FROM MySQL.User WHERE username=:username AND
password=PASSWORD(:password) ;

But there is no such information in Oracle schema.

Reply to this Message

Lew - 12 Jan 2008 02:21 GMT

dave wrote:

>> I need to authenticate users based on their oracle username and
>> password.
[quoted text clipped - 3 lines]
>> Is there some oracle java library that will allow me to perform a
>> check on the username and password?

> No such way in Oracle, I think.
>
[quoted text clipped - 4 lines]
>
> But there is no such information in Oracle schema.

That doesn't make sense. You don't authenticate a person for business logic
based on their user id in the back end. In typical situations, the user
doesn't even have a database username; the application has a username and
proxies database actions based on the application authorization of the user.

I think we aren't clear on what the OP means by the "oracle [sic] username and
password".

The usual way to authenticate is to have a username (rolename) / password
table in the application's database (i.e., not the RDBMS system tables), that
applies to the application, not the database.

As for using JDBC or not, how else would one expect to connect Java code to a
database, hmm?

Signature

Lew

Reply to this Message

Donkey Hot - 12 Jan 2008 02:26 GMT

> I think we aren't clear on what the OP means by the "oracle [sic]
> username and password".
>
> The usual way to authenticate is to have a username (rolename) /
> password table in the application's database (i.e., not the RDBMS
> system tables), that applies to the application, not the database.

I'm not sure if I like that concept at all. Especially Oracle has great
means of granting users rights and roles. I think it's not really ideal for
an application to reinvent the wheel and establish own mechanisms for that.

More so, if you want to have an audit system upon your database keeping
track for what people do in the db. My business happens to be in security,
and I have implemented and audit reporting system for a hospital, who
wanted to know if their users peek what and when.

When everything was ready, we saw that there was only one "user" in the
system... some fixed "application" user, who authenticated the users
againts it's own table. The audit report showed all queries and updates
done to the database, including clear text passwords to the application
user/role repository. So much for security.

There are great auditing systems for databases, like Lumigent AuditDB.
Great tool renders almost useless with all those home made applications.

That's sad. Databases do have concepts of USER, PASSWORD, ROLE and ACCESS
RIGHT. There is no need to duplicate them in any application.

Reply to this Message

Lew - 12 Jan 2008 03:22 GMT

> When everything was ready, we saw that there was only one "user" in the
> system... some fixed "application" user, who authenticated the users
> againts it's [sic] own table. The audit report showed all queries and updates
> done to the database, including clear text passwords to the application
> user/role repository. So much for security.

You blame having only "some fixed 'application' user" for that problem. I
would blame the programmer for forgetting to put that audit information into
the database, and for transmitting passwords in the clear.

Having a single application database username does not preclude the type of
security safeguards and audit information to which you refer. It is
programmer error, not the separation of database and app users, that caused
your trouble.

Signature

Lew

Reply to this Message

Donkey Hot - 12 Jan 2008 04:55 GMT

>> When everything was ready, we saw that there was only one "user" in
>> the system... some fixed "application" user, who authenticated the
[quoted text clipped - 12 lines]
> It is programmer error, not the separation of database and app users,
> that caused your trouble.

A good audit system does not care if the programmer has a clue or not, it
reads the database redo-logs or such, and produces an audit trail from all
happenings in the db, no matter who did or did't do what. Luckily some
databases, like SQL-Server stores the operating system user to the logs as
well, so everything is not lost. No programmer has forced the users to log
on to network with some 'application logon name' yet.

Truly, these kind of things should be handled by the infrastructure, and
the applications should be coded as applications. If the application is
security, then it can handle users, roles and passwords. But it's meant for
business logic, it should stick on it.

Btw. I'm not from Texas, while I write in error "its" as "it's". I'm from
Finland, but what is more important, I'm drunk.

Reply to this Message

oracle - authenticate with username and password

Free Magazines