Appendix B - One- and Two-level Login Considerations
Two-level login is supported when using ‘application managed’ database connection. This is how it works:
- The user name and password for the first-level ’technical user’ is provided in a configuration text file which is read by SICS
- SICS will connect to the database using the technical user name and password
- SICS reads the corresponding SICS User Object from the
CNU_USERtable - SICS detects that the SICS User Object contains a second-level name and password
- SICS disconnects from the database
- SICS connects (once more) to the database using the second-level name and password from the SICS User Object
- This connection is used for all later access and updates to the database
In other words, when using application managed login, the db connection is under control by the application, i.e. SICS.
However, when using container manager login, the db connection is under control by the web container, i.e. Tomcat or WebSphere.
What SICS does, is to use JNDI to ask the container for a database connection. When doing so, SICS does NOT provide any user name or password. The user name/password has been defined in the JNDI definition inside the web container.
After connecting to the database this way, SICS reads the SICS User Object.
However, even if the SICS User Object contains information about a second-level user name and password, SICS is not able to utilize this. Simply because: when using container managed connections, the application CANNOT control the user name and password used to connect to the database. The connection is completely controlled by the web container and not by the application.
End result: SICS will use the JNDI connection provided by the container, for all later access and updates to the database. Therefore, the user defined in the JNDI connection must have all rights on all SICS tables.
Depending on customer needs, one might set up the JNDI definition with either the first-level or second-level user name and password.