Hi,

We have an application from a vendor that is behaving in a way I didn't expect. It was designed as a single all in one solution but our environment has the traditional split between Application Server and Database.

So here the Administrative Security for WAS is set against an LDAP - Standalone Repository (fine). Application Security is enabled (which is key). All okay there.

Next we provide database access to a functional ID called Billing. In WAS I define the J2C credentials for Billing and associate them with the datasource. When I test the datasource connection it fails as the application attempts to look for the user first in the LDAP! So I have to have Billing in the LDAP and  Billing on the database host (which is ludicrous and defeats the purpose of separation for security).

If I disabled Application Security then the jdbc test goes straight to the Database to check the credentials (and Billing only exists on the database server as expected). However, now the application administration console (built into the application) is not secure so this doesn't work.

Is there any way to get more granular in terms of security settings at this point? Am I missing something basic here? (Application Vendor has backed away from this one)

Thanks,

Paul

Hell Paul,
that sounds a bit strange as using a J2C Authentication alias with the DB user / password and then assigning that J2C Authentication alias with the data source while using an LDAP base user registry is kinda standard procedure and used at almost every customer.

Are you sure that the application uses the WAS infrastructure here and is not using any customer code to connect to the database if application security is enabled?

Can you provide a bit more information on your environment? What version (-number, WAS ND, WAS standalone, platform) of WAS are you using? What topology is in place?  Which DB are you using? Can you provide anonymized screen shots of your configuration and the detailed error messages you get?

The following must gather documentshttps://www-01.ibm.com/support/docview.wss?uid=swg21610455 and https://www-01.ibm.com/support/docview.wss?uid=swg21654565 might provide some instructions on how to investigate further.


------------------------------
Hermann Huebler
------------------------------

Original Message:
Sent: Fri June 14, 2019 01:48 PM
From: Paul Fearon
Subject: Application Security and J2C Authentication Credentials

Hi,

We have an application from a vendor that is behaving in a way I didn't expect. It was designed as a single all in one solution but our environment has the traditional split between Application Server and Database.

So here the Administrative Security for WAS is set against an LDAP - Standalone Repository (fine). Application Security is enabled (which is key). All okay there.

Next we provide database access to a functional ID called Billing. In WAS I define the J2C credentials for Billing and associate them with the datasource. When I test the datasource connection it fails as the application attempts to look for the user first in the LDAP! So I have to have Billing in the LDAP and  Billing on the database host (which is ludicrous and defeats the purpose of separation for security).

If I disabled Application Security then the jdbc test goes straight to the Database to check the credentials (and Billing only exists on the database server as expected). However, now the application administration console (built into the application) is not secure so this doesn't work.

Is there any way to get more granular in terms of security settings at this point? Am I missing something basic here? (Application Vendor has backed away from this one)

Thanks,

Paul

Hi Hermann,

Thanks for the update. It got me thinking a bit more about the configuration and then I revisited the logs. The issue was that in the original solution there were multiple J2C aliases defined (some for jdbc and some for Bus) but all were using the same credentials. This worked because the original system was a single server implementation.

In the distributed solution I needed to have separate aliases for Bus and JDBC connections. The Bus use was then in LDAP and JDBC was obviously remote so the conflict was removed. 

Thanks for the direction on this.

Paul


------------------------------
Paul Fearon
------------------------------

Original Message:
Sent: Mon June 17, 2019 04:45 AM
From: Hermann Huebler
Subject: Application Security and J2C Authentication Credentials

Hell Paul,
that sounds a bit strange as using a J2C Authentication alias with the DB user / password and then assigning that J2C Authentication alias with the data source while using an LDAP base user registry is kinda standard procedure and used at almost every customer.

Are you sure that the application uses the WAS infrastructure here and is not using any customer code to connect to the database if application security is enabled?

Can you provide a bit more information on your environment? What version (-number, WAS ND, WAS standalone, platform) of WAS are you using? What topology is in place?  Which DB are you using? Can you provide anonymized screen shots of your configuration and the detailed error messages you get?

The following must gather documentshttps://www-01.ibm.com/support/docview.wss?uid=swg21610455 and https://www-01.ibm.com/support/docview.wss?uid=swg21654565 might provide some instructions on how to investigate further.


------------------------------
Hermann Huebler

Original Message:
Sent: Fri June 14, 2019 01:48 PM
From: Paul Fearon
Subject: Application Security and J2C Authentication Credentials

Hi,

We have an application from a vendor that is behaving in a way I didn't expect. It was designed as a single all in one solution but our environment has the traditional split between Application Server and Database.

So here the Administrative Security for WAS is set against an LDAP - Standalone Repository (fine). Application Security is enabled (which is key). All okay there.

Next we provide database access to a functional ID called Billing. In WAS I define the J2C credentials for Billing and associate them with the datasource. When I test the datasource connection it fails as the application attempts to look for the user first in the LDAP! So I have to have Billing in the LDAP and  Billing on the database host (which is ludicrous and defeats the purpose of separation for security).

If I disabled Application Security then the jdbc test goes straight to the Database to check the credentials (and Billing only exists on the database server as expected). However, now the application administration console (built into the application) is not secure so this doesn't work.

Is there any way to get more granular in terms of security settings at this point? Am I missing something basic here? (Application Vendor has backed away from this one)

Thanks,

Paul