We have a "common" remote database that all users must be able to access from within our application. But the database must not be accessible for the users with ODBC or other connectivity method.

My only idea to solve this, is to create a new "user role" for this purpose, and grant the user access to this "user role", when starting the application, and then revoke the access when closing the application.

Does this make sense? Does anyone have a suggestion, how to limit access to a "common" database for our application only?

Eydun


ElevateDB has multiple protection methods built in:

1. User password
2. Encryption
3. Signature

A lot will depend on how you access it, wether it needs to share a session etc

Roy Lambert

Eydun wrote:

> We have a "common" remote database that all users must be able to access from within our application. But the database must not be accessible for the users with ODBC or other connectivity method.

I'm not entirely sure I understand the situation, but surely the answer is simply users and access permissions? The ODBC user could, if they knew the right user/password, access anything. But if you don't tell them the password, they can't. IIRC the ODBC side defines the password in the connection string, so just set things up appropriately.

What am I missing?

--

Matthew Jones

Matthew


>What am I missing?

Users willingly giving the username / password to the developer using ODBC so they can access things in an "easier" way.

Roy

Roy Lambert wrote:

> Users willingly giving the username / password to the developer using ODBC so they can access things in an "easier" way.

Hmm, but is there a way around that? I suppose you could have "users" separate to the "access user" at the database level. So all "users" are connecting not as a database user, but some higher level construct. But I still don't think there is a good solulution. I'd be tempted to say it needs to be two separate databases/sessions. Or use a server that provides an API and acts as intermediary.

--

Matthew Jones

Eydun,

<< We have a "common" remote database that all users must be able to access from within our application. But the database must not be accessible for the users with ODBC or other connectivity method.

My only idea to solve this, is to create a new "user role" for this purpose, and grant the user access to this "user role", when starting the application, and then revoke the access when closing the application.

Does this make sense? Does anyone have a suggestion, how to limit access to a "common" database for our application only? >>

Typically, this is done with a custom signature on the remote database that is only used by your application (and the "default" ODBC driver would have no idea about).  But, that may be a little difficult if you've already deployed the database, etc.

Dynamically-modifying users and roles will work, but I wouldn't recommend it:

1) You can end up leaving an orphaned, granted role for a given user.

2) You end up really taxing the concurrency on the EDB configuration file.  The configuration file is typically only modified occasionally with DDL statements, and isn't really designed for constant modification like a database.

Tim Young
Elevate Software
www.elevatesoft.com

Thank you all for your helpful replies.

"Signature" was the solution to our problem


Tim Young [Elevate Software] wrote:

Eydun,

<< We have a "common" remote database that all users must be able to access from within our application. But the database must not be accessible for the users with ODBC or other connectivity method.

My only idea to solve this, is to create a new "user role" for this purpose, and grant the user access to this "user role", when starting the application, and then revoke the access when closing the application.

Does this make sense? Does anyone have a suggestion, how to limit access to a "common" database for our application only? >>

Typically, this is done with a custom signature on the remote database that is only used by your application (and the "default" ODBC driver would have no idea about).  But, that may be a little difficult if you've already deployed the database, etc.

Dynamically-modifying users and roles will work, but I wouldn't recommend it:

1) You can end up leaving an orphaned, granted role for a given user.

2) You end up really taxing the concurrency on the EDB configuration file.  The configuration file is typically only modified occasionally with DDL statements, and isn't really designed for constant modification like a database.

Tim Young
Elevate Software
www.elevatesoft.com