oracle - authenticate with username and password

[dave]

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

 

[Donkey Hot]

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

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=PASSWORDpassword) ;

But there is no such information in Oracle schema.

 

[Lew]

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=PASSWORDpassword) ;

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?

 

[Donkey Hot]

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.

 

[Lew]

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.

 

[Donkey Hot]

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.

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.