With DevTest 8.4 Solution, did we necessarily need a flow (direct access) between Workstation and DB to carry out the authentication/authorization process (checking ACLs configurations in DB) ?
In fact, we are looking for anothers alternatives for security reasons. As we have a distributed installation, the workstation (on end-users's computers) are in a different network bubble from the DB. The DB could be installed in a secured bubble (DMZ), and we wouldn't like to have to open flows between each Workstation and the DevTest DB.
Whe have explored the avenue of using a LDAP directory, but we still will need to open flows for authorization checking during authentication process (to Workstation or Portal).
=> Did you have some ideas/alternatives solutions ?
Thank you in advance for your reply.
Hi Baya, I witnessed this behavior using earlier versions of LISA (r7, r7.1, etc.). I found this at a customer who used AD for authentication to their DBMS. The Workstation passed the "logged on user" credentials rather than the DB connection credentials specified in the properties file. It seems this is still the functionality on the basis of description.
My workaround was to have the user IDs of LISA Workstation users assigned to an AD Group. The security team "synchronized" this group with an AD group on the AD used by the DB. Security set this group to allow read, write, update permissions on the DB. I assume I had to ask for a firewall rule to allow access to the port the DBMS was listening on since we were hopping across network boundaries.
Hi Joel, Thank you for this feedback. It confirm my thought, we necessarily have to ask for a firewall rule to allow access from the Workstation to the DBMS. In our case, we can use an LDAP for authentication and we can't do any mapping between LDAP group and DevTest roles for the authorization => In conclusion, we don't have the choice, we have to ask for a firewall rule.
Hi Dembab, yes, I agree you need the firewall rule.
My point about the DB connection and "logged on" user Id was this. If your DBMS uses AD / LDAP authentication (e.g., not mixed mode), the DevTest Workstation "logged on user Id" has to have CRUD access rights to the DevTest database table(s). This has nothing to do with internal DevTest ACLs and roles. When AD / LDAP authentication is enabled in the DBMS, the DevTest Workstation is sending the credentials associated with the "logged on" or "run as" user. (I believe on a Windows platform it is the sqljdbc_auth.dll that passes the security token when AD/LDAP is used.) The DBMS validates the logged on user credentials against the AD/LDAP source. This means that the lisadb.pool.common.user property and the internal lisadb connection pool are not being used. A dump of the security logs from the DBMS should identify this for you.