2019-03-22 07:38:51.335 UTC [INFO ] [http-nio-8080-exec-7 ] --- [U:][M:][P:] c.c.t.s.s.SecurityUserService: External authentication not allowed for user integrator
2019-03-22 07:39:07.639 UTC [INFO ] [http-nio-8080-exec-4 ] --- [U:][M:][P:] c.c.t.s.s.SecurityUserService: External authentication not allowed for user integrator
2019-03-22 07:39:15.222 UTC [INFO ] [Thread-47303 ] --- [U:][M:][P:] c.c.t.t.d.TDODSession: Authentication successful. Session Id: 1775427590
2019-03-22 13:35:09.145 UTC [INFO ] [http-nio-8080-exec-5 ] --- [U:][M:][P:] c.c.t.s.s.SecurityUserService: External authentication not allowed for user <<USER_NAME>>
Release : 4.7
Component : CA Test Data Manager - TDM Web Portal
TDMWeb-126.96.36.199.zip Resolves this issue. Please contact BC Support for this or a later version. Please note this did NOT get into the 4.8 GA Version. If you need this fix, please contact BC Support and verify it is in the latest 4.8 Patch.
Are there any suggestions on what LDAP configurations would perform better for TDM?TDM will perform better of if values for User Container and Group Container is defined. If they are not defined then ldap queries scope would be wide and potentially causes performance issues
The main issues we are seeing with the latest patch are when we are trying to load the tiles, why are there LDAP queries running at that time, I would have expected the TDM permissions to take over once the user had authenticated through LDAP while logging into the portal
The default refresh interval is set to 1 hour and can be changed using the entry jwt.refreshInterval in application.properties.
After one hour, the refresh interval kicks in causing the user to be re-authenticated.
Can you please confirm that the behavior you are seeing is related to the refresh interval (default 1 hour) or not.
Do you see the user trying to 'issue' an 1 hour after login?
When you logon using LDAP, the user authentication is performed in the main TDMWeb service.
TDMweb will then request a session ID from TDMService. As part of generating a sessionID, TDMService performs a user authentication
When it works, TDMweb service receives the sessionid back from TDMService and stores it locally
When a User selects a tile, TDMweb uses the sessionId to talk to TDMService
However in your case because of the delays due to LDAP queries, TDMservice takes more than 10 minutes to reply to TDMWeb.
TDMweb then times out waiting for TDMService to reply and does not have a sessionID to store locally
When a User selects a tile, TDMweb asks TDMService again for the sessionID which will force TDMService to try again the authentication for the user
This will show up as tile hanging.
As you can see all this behavior stems from the fact that LDAP authentication takes too long.