Executing a SQL Inseert as a DB User instead of htmldb_public_user

Question

Hi,
There are quite a few posts on this topic, but no direct answer.
In one of Scott's posts, he says:
'If you use HTML DB Account/LDAP/SSO/roll-your-own authentication and your named HTML DB session user is MIKE, HTML DB will execute your SQL or PL/SQL as the application's schema connected as HTMLDB_PUBLIC_USER and everything your code does inside the database will be as user HTMLDB_PUBLIC_USER .... '
In same post he says that if you use DB_authentication, the SQL is executed as the DB user.
We are putting the finishing touches on an application that needs to write to a DB which contains a trigger on it enforcing a rule that the insert user has to be a database user.
The problems/background to the issue we have are:
1. We want to use ldap - so we don't have to register everyone on that DB
2. Even if we didn't want to use LDAP, we can't get people to log onto the database anyway - as the application has a weird setup where the database username = application userame, but application password <> database password - and no user knows their database password (so they can't sneak around the back end).
3. We can't create a user htmldb_public_user on that database as it has a 10 char restriction on usernames
I guess It's the same question as:
How to execute a plsql with another db user but not HTMLDB_PUBLIC_USER?
but this was never expanded/answered.
What are my options?
A. Can I change htmldb_public_user to another username that is on the database?
or preferably
B. Can I somehow get the SQL to be run using the username that logged into htmldb?
...David.

Answer 1

Hi Scott,
1) If you cannot create database users > 10 chars, how did you install HTML DB with its default schemas FLOWS_010600, FLOWS_020000, or FLOWS_FILES? We can create these users directly on the database for htmldb, but the application that we have on that same database does not let us create usernames > 10 char - and it is this application (a 3rd party system we have no control over) that enforces the database trigger for the user to be registered on their system when we try and update some of their data.
ie - we have a 3rd party database structure that we are sitting html db on top of to do reports and some updates where that system is inefficient. We have to work around that 3rd party's security as we have no way of changing it or getting them to change it.
2) You cannot safely use an alternative user to HTMLDB_PUBLIC_USER. Okay. That's nice to know as we were about to try that option.
Scott: having seen hopefully a bit more detail in the reply to 1 above - can you see what the question is now? ie - if we authenticate in htmldb using ldap, can we run a insert or update sql somehow within the htmldb application using a different account to htmldb_public_user so that we can fit in with the security restraints of this 3rd party system?
As I have said, we cannot use database authentication as the setup on this 3rd party system is very strange - it has a separate application based password for users compared to the user's database password , and we cannot give the users the database password (so they can log into htmldb) as it constitutes a security risk.
I am toying with the idea of creating a staging table that contains triggers to update the real table owned by the 3rd party application's schema, but haven't managed to get it working yet.