I need to create a user in an oracle database that only allows connections through JDBC and not through some IDE for example, is this possible?
There's no good, foolproof way to do what you're asking (limit connections based on connection protocol, or other client-side parameters). Any of the session parameters that you could base a database logon trigger or smart application role on can be spoofed or altered to bypass your security filter. The generally accepted approach is to secure a user account's permissions so that it doesn't matter how they connect - their access to and view of the data is always the same.
If you want to limit access just to your application server, do this using firewall rules on the database server that only allow inbound connections from the app server IP on the database port, or (if you have Enterprise Edition) use Oracle Connection Manager to filter access by IP address and Oracle Service Name.
Basically it hard to set this up really securely.
You can use such an approach:
Create DB user with no privileges on Application schema (except for connect)
Grant user password protected ROLE: APP_ROLE. Having access to APP_SCHEMA tables.
In your app, after DB logon execute:
SET ROLE APP_ROLE IDENTIFIED BY "some role's password";
Then execute:
ALTER SESSION SET CURRENT_SCHEMA='APPL_SCHEMA';
So even if anybody know username and password for database, he can connect, but is not allowed to see any data. APP_ROLE's password is hard-coded in your app, or is passed to your app from outer source (config file or databases global context).
So basically you need two passwords to access database data:
user's password
role's password
Related
We are in the planning phase of configuring our soon-to-be-upgraded databases (19c) to authenticate directly against AD (no oracle proxy). I have read a handful of documents from Oracle on how to do this. Most of the documentation focuses around using passwords (password filter/verifier). The only problem is that our AD administrators are dead-set against implementing Oracle's password filter into our existing AD infrastructure. That being said, one of the security guys said we could implement the oracle authentication using Kerberos instead. From what I have read, and the documents are scattered all over the place, and nothing that detailed, to use Kerberos:
1) The client no longer uses a username/password - they connect using a wallet-style connection (e.g. /#dbname)
2) Not only does the Oracle DB need some configuration changes, but so does every client that plans on using Kerberos
I don't know anything about Kerberos, how it works, and what goes on when you implement this, but I was hoping for, at the end of this is:
1) No client changes/installs (only the oracle DB would have config changes)
The user will continue to provide credentials as before - completely transparent
2) No need for the password filter as our admins have a "beef" against it
So my question is:
If using Kerberos directly against AD on >=18c:
1) Does the client user still provide a username and password to authenticate against AD, or does the client simply get "accepted" due to the tickets/tokens/configuration that occurs on the client (i.e. the client is simply trusted)?
2) Is there client config changes that need to occur, or does the client reach out to the DB and the DB, with its config changes, does all the legwork to authenticate against AD based off of client info being passed
3) Does any additional manual component need to occur on occasion (periodically retrieving a ticket/token/something) (because, say, it expires)
So in the end, we want to have complete transparency with every client and using something other than the password verifier with AD.
Thanks in advance.
-Jim
It sounds like you want to authenticate Windows clients against an Oracle database over a network using Active Directory without making any client changes.
This is pretty open-ended and complex StackOverflow question.
Probably you've been reading the docs about Third Party Network Authentication using Oracle Advanced Security. You can use Kerberos, SSL, RADIUS, PKI, etc. For most of these options, you need to do some setup on the client, because both the Oracle client and server need to authenticate or verify with the third-party system.
I think you need Enterprise User Security (using Oracle Internet Directory). Assuming you go with password-based authentication, you don't need client changes. In this scenario, Oracle Internet Directory can synchronize its user directory with AD, so your users can use their same username/password. However, when they change their AD password, they'll need to change their Oracle password separately.
On a different note, you may be able to alleviate your AD admins' fears about Oracle password complexity requirements, since you can change or remove those to fit your AD requirements.
I need to restrict access to Oracle Database via tools like Toad, SQL Developer etc.
Only the request coming from Application Server should be allowed to connect successfully.
You can:
Restrict access to DB on Firewall level
Restrict access to DB via Listener configuration (listener.ora)
Restrict access to DB via logon trigger on schema. You can find templates of such a trigger on the Internet. Basically you have to select from sys_context function(or from v$session view). This will tell you all the information you need. Then any exception raised from logon trigger aborts the connection.
Grant access to users, but do not give them any privs. Then grant necessary privs to password protected role and enable this role via "SET ROLE" ONLY from the application.
Or you can mix these approaches as you want.
I am working on an application that uses Oracle OCI to connect to the Oracle database server. The application allows the user to change their Oracle password and uses Alter User xxx Identified By to perform this.
However, this transmits the user's new password in clear text over the network (we cannot use Oracle SSL to encrypt network traffic). I have found that Oracle recommends using the PASSWORD command in SQLPlus rather than ALTER USER, one reason being that the new password encrypted.
Does the OCI method OCIPasswordChange also encrypt the new password when it is transmitted over the network?
This is using Oracle 10 and 11.
Yes, OCIPasswordChange does encrypt the new password sent over the network.
I have now implemented this and done a packet trace. An encrypted AUTH_NEWPASSWORD packet is transmitted to the Oracle database server.
There are a few users which have (1) username, (2) password and (3) role attributes.
I want to use credentials of a user to authenticate and authorize for EJB service operations (WebLogic 12c App Server).
At the same time, i want to use those credentials for connection to persistence storage (Oracle 11g Database), cause my customer wants to restrict db object access depend on user role attribute.
Is there WebLogic or Oracle Database facilities to do so?
Is there any way to do so?
Very glad to see all your responses. Thank you.
We are trying to shape up an old, 2 tier, Delphi based application. It originally uses database authentication, we'd like to transform the db user accounts to global users, so an OID server could perform the authentication instead of the database.
The Delphi program can no longer log into the database if the account is a global user. I'm trying to understand the login protocol, so far without results.
Similar thing happens with SQLDeveloper, I can't connect as a global user. SQLPlus however works with both kinds of users. We checked the information flow with Wireshark. When the dbserver asks back for a password, the SQLPlus sends it, while the SQLDeveloper doesn't send a password when attempting to connect as a global user.
The client sends the application name too in the login request. Is it possible that we have to store the client app name in the LDAP itself?
To connect to Oracle using OID, application must properly configure OCI (Oracle Call Interface). The data access components (which one ?), you are using, must set OCI_ATTR_DISTINGUISHED_NAME session attribute. If that is not done, then you will be not able to connect to Oracle server using ODI and OCI.
You should check your components documentation for this feature. And if it is not implemented, then discuss this issue with the components vendor. Actually, there is not much work to implement, but some work to setup testing environment is required ...