Priveleges to create procedures/functions in schemas

Question

Greetings,
I have a default schema associated with my user account. Can permissions be given for my user account to create functions and procedures in another schema without giving that user priveleges to create in ANY schema.
Our default schema for HTMLDB is not the schema associated with my user account. I want to be able to create my functions inside that schema, but our DBA's havent been able to find out how to give the privelege without opening up all schemas to that account.
hope this made sense,
Cliff Moon

Answer 1

Okay Cliff, no problem.
Now, Michael, I don't know of any prepared docs specifically about this but fwiw, I'll try to recap how it works.
1. HTML DB uses a public account to create (or reclaim) a distinct database session to service each page request. The connection is configured with the modplsql DAD and the database user (schema) that owns the session is HTMLDB_PUBLIC_USER. (The exception to this is when you configure a DAD for basic authentication.)
2. The public packages (like wwv_flow) and procedures (like f) invoked through each HTTP request are owned by schema FLOWS_xxxxxx. Packages like wwv_flow use definers rights. This means, among other things, that they can execute any other packages owned by the FLOWS_xxxxxx schema, including the highly privileged, non-public packages that execute user code.
3. The more privileged non-public packages do all the real work of rendering pages and processing POSTed pages. During these phases, your application code is executed (your report region queries, your DML operations, your page processes, validations, condition evaluation, your API calls, everything). All of this code is "parsed as" the database user (schema) assigned to your application. (Only one schema is assigned to a given application, although the assigned schema can be changed using the builder whenever you like.) The HTML DB engine can execute all of your application code as the "parse as" schema because it has SYS privileges to do so.
4. Any of your code that HTML DB executes dynamically runs with the security privileges of your application schema. These privileges must have been granted explicitly and not through roles. So if your report query does 'select * from emp' it's necessary for emp (or a synonym for it) to exist in your application schema and for that schema to have select privilege on emp.
5. The SQL Workshop works the same way, except things happen there at a workspace level, not at an application level. A workspace has one or more database schemas mapped to it. This means only that a conscious decision has been made (by an admin) to allow each workspace to access specific schemas. The list of schemas mapped to a given workspace appears in LOVs in various places, such as the SQL Command Processor. Selecting a schema from this LOV allows you to perform operations in that schema. You can perform operations in any of the other mapped schemas by selecting them from the LOV in turn.
Note: so far we've said nothing about who the authenticated user is using your application (or the SQL Workshop application), because it has absolutely no bearing on anything so far.
6. HTML DB allows developers to specify a plan to be used by the engine at the start of every page request to perform the chores of authentication, initial session registration and session management. This plan is called an authentication scheme. HTML DB provides standard schemes that are used by most developers, but developers can also design and build custom authentication schemes over which developers have complete control.
7. During the execution of the authentication scheme for a page view (show) or page processing (accept) request, it is common for the scheme to cause a branch/redirect to a login page if it determines that no valid session yet exists. The operation of the login page results in the user being challenged for credentials and for those credentials to be verified. If they check out, related housekeeping tasks are performed such as recording the session ID in a table and session cookie creation. And a token is established to be used to identify the authenticated user for the duration of the HTML DB session. This value is stored in APP_USER and can be queried by developer-owned code and HTML DB-owned code as required.
8. The credentials verification step is where user accounts come into play. It doesn't matter to HTML DB whether your application uses custom tables, an LDAP directory, an SSO infrastructure, or database accounts to verify credentials -- the verification takes place, usually once per HTML DB session, and that's that. The authentication scheme determines the exact method used.
9. One example of an application that uses its own custom tables to hold account information (usernames/passwords) is HTML DB itself. You get the first account created for you during product installation and then you create administrator and developer accounts as you create multiple workspaces for developers at the site. These accounts are just rows in tables, a username, a password, an email address, the ID of the workspace, basic stuff like that. They are not database user accounts (schemas). And with these accounts, you can authenticate to HTML DB and use the Builder, the SQL Workshop, and the administration functions. Just remember, the database knows nothing of these accounts (they are like Oracle Applications user accounts).
10. These HTML DB user accounts exist primarily to allow developers to use HTML DB. But they can also be used to allow end users to authenticate to applications created using HTML DB. That relieves each developer of having to "reinvent the wheel" and set up account repository tables and to have to write APIs to store/manage passwords, the work we did for HTML DB itself. Your application can simply use the built-in HTML DB authentication scheme which uses the account repository for credentials verification. It's not the only way for your application to verify credentials. In fact it's best suited for experimental applications, small workgroup applications, prototypes, apps on that scale. Applications that are slated for actual production deployment should be fitted with enterprise-level identity management solutions.
11. Finally, HTML DB provides a very, very basic group-membership model that allows developer accounts (not database schemas) to be assigned to arbitrarily organized named groups. There is a supporting API for queries against these groups and an admin UI to create/maintain these groups. The same caveats given for using developer accounts for production applications apply to this facility.
Recap:
Database accounts: HTML DB does not use these accounts, their roles, or their privileges except to dynamically execute application code using these schemas as the "parsing schema".
HTML DB user accounts: No relation to database schemas (*). They exist in custom tables owned by the HTML DB product. Accounts can be created and used by application developers as an out-of-the-box credentials verification method for authentication.
*Exception: The "default schema" associated with an HTML DB user account is the name of a schema used to prime an LOV when the user sees a list-of-schemas LOV in places like the SQL Workshop.
Scott