-
1. Re: Passthrough authentication of local web application logs in as anonymous
rareddy Jun 10, 2015 12:26 PM (in response to bpiepers)Bas,
What is security domain defined on the "embedded" transport in your DV server? This needs to match to the security domain you defined on the web service to make passthrough work correctly.
Ramesh..
-
2. Re: Passthrough authentication of local web application logs in as anonymous
bpiepers Jun 10, 2015 3:23 PM (in response to rareddy)Thanks for the quick reply, Ramesh. It's the same everywhere, so the web application that connects to the VDB has the same security domain name as the security domain defined in the standalone configuration file as well as the "embedded" transport definition.
Any idea where to look for/where to debug? I still wonder where "anonymous" comes from. I didn't define it anywhere but the SessionServiceImpl uses it in the passThroughLogin method and uses the securityHelper to get an existing "Subject" for the domain we definied. It then comes up with a security domain of a previously logged in user since "anonymous" doesn't exist as a user....
-
3. Re: Passthrough authentication of local web application logs in as anonymous
rareddy Jun 10, 2015 7:18 PM (in response to bpiepers)"anonymous" is default user name used by Teiid when one is not given on the JDBC URL and one could not read from the passed in Subject. Are you running in debugger to see the above code? You need to start in the LogonImpl then, walk into SessionServiceImpl to make sure the passthough is working as you expect.
-
4. Re: Passthrough authentication of local web application logs in as anonymous
bpiepers Jun 11, 2015 3:01 AM (in response to rareddy)There appears to be something wrong in the DQPWorkingContext class or one of the related classes. It keeps on calling the securityHelper.associateSecurityContext with a previous context. The currently logged in user does have a valid SecurityContext because in the JBossSecurityHelper class I do see that it gets fetched from the SecurityActions.getSecurityContext call, but then associates a previous context as the new context. Also, I don't understand why in the finally block in the DQPWorkContext.runInContext it keeps setting a previous securityContext. There's clearly a mix-up in security contexts...
-
5. Re: Passthrough authentication of local web application logs in as anonymous
bpiepers Jun 11, 2015 8:04 AM (in response to bpiepers)Oke the problem is that the DQPWorkContext class associates a previously created securityContext (from the DQPWorkContext's session) instead of the one that is currently active. It does that in the runInContext method where it calls securityHelper.associateSecurityContext with the securityContext of his own session (which is the session of the previously logged in user). The securityHelper implementation (JBossSecurityHelper) calls SecurityActions.getSecurityContext to get the currently active securityContext (OK!!) but unfortunately gets the incorrect (previous) securityContext from DQPWorkContext class to associate that to the current ThreadLocalContext.
Please advice how I can force the correct user (security context) being used to connect to the VDB.
DQPWorkContext uses a TLS pattern and it seems that for the ThreadLocal that is active a DQPWorkContext is already instantiated/still active. We also use a TLS pattern for the security context that is set within the Jboss Security Domain for the web application that calls the VDB. The DQPContext's session contains a security context that is not in sync with the security context within JBoss. Please advice how to deal with this situation as it seems that when a pass through authentication takes place, JDV re-uses an already active DQPWorkContext (because we seem to call it in the same ThreadLocal context) but I think there should be some kind of mechanism in place that detects that another user has logged in and should then re-instantiate that DQPWorkContext or re-set it...
-
6. Re: Passthrough authentication of local web application logs in as anonymous
shawkins Jun 11, 2015 8:29 AM (in response to bpiepers)The LocalServerConnection class, which is the client's entry point, uses a proxy to check is the same user is still associated with the thread. What version are you on? There have been some changes there even in the latest version - [TEIID-3380] Simplify Kerberos configuration with Embedded - JBoss Issue Tracker
-
7. Re: Passthrough authentication of local web application logs in as anonymous
rareddy Jun 11, 2015 8:45 AM (in response to bpiepers)Can you also try with DV 6.1?
-
8. Re: Passthrough authentication of local web application logs in as anonymous
bpiepers Jun 11, 2015 9:05 AM (in response to shawkins)@Steven - I'm on version JDV version 6.0 and the Teiid runtime is on version 8.4.2.
@Ramesh - not easily but will give it a try. We have it on our roadmap to upgrade to the latest and greatest version of JDV but would like to wait until version 6.2 is released :-)
-
9. Re: Passthrough authentication of local web application logs in as anonymous
rareddy Jun 11, 2015 1:04 PM (in response to bpiepers)That would be good, even if you can try quickly with Teiid 8.7 version that would be good. I trying to see if this is bug that is already fixed or something wrong with your configuration of web service and pass-though stuff.
-
10. Re: Passthrough authentication - Teiid Work Context not in sync with Security Context
bpiepers Jun 12, 2015 5:13 AM (in response to rareddy)Unfortunately it's not trivial to quickly test with Teiid 8.7 due to the large amount of dependencies with other libraries. I'll try and search for differences in the involved classes, perhaps I can spot changes that fix this issue.
-
11. Re: Passthrough authentication - Teiid Work Context not in sync with Security Context
shawkins Jun 12, 2015 7:52 AM (in response to bpiepers)More than likely the LocalConnection changes from FishEye: changeset 6b40fb5c3a8eb85bcc9c78121827d8f7948e8a2b will need to be backported to 8.7.x as well.
-
12. Re: Passthrough authentication - Teiid Work Context not in sync with Security Context
bpiepers Jun 12, 2015 8:33 AM (in response to shawkins)Yes, migrating to 8.7 is not an option for now. Rather I would like to fix this in the current version for now but don't fully understand the concept or reason behind why certain logic is there. I mean, why would you overwrite the JBoss security context that is currently active with a security context from a DQPWorkContext's session? In that proxy that is implemented in LocalServerConnection, the invoke method, it checks if the current WorkContext's security context is the same as the JBoss security context. But why does it assume that the DQPWorkContext's security context is leading here? So in our scenario we set the JBoss security context in our web application and then access a VDB using a certain user name and the passthrough mechanism. But then when the engine spots an already active DQPWorkContext, it decides to overwrite the JBoss security context. I don't understand why and when this is beneficial. Any idea?
-
13. Re: Passthrough authentication - Teiid Work Context not in sync with Security Context
rareddy Jun 12, 2015 9:37 AM (in response to bpiepers)Bas,
We are not ruling out this not as a bug, so if you post test we can check. Or you can open a Redhat support ticket.
Ramesh..
-
14. Re: Passthrough authentication - Teiid Work Context not in sync with Security Context
bpiepers Jun 12, 2015 10:11 AM (in response to rareddy)Will do Ramesh, as for now not completely convinced it's really a problem in the mentioned classes as I also see that the datasource provider seems to re-use connections and therefore doesn't log on to the VDB with the new credentials. I have to dive into this a little bit further so I can give enough information to create a Red Hat support ticket.