teiid50090 when trying to access odata entity

[gmackinnon]

teiid : 8.7.0.FinalCAFix

JBoss : EAP 6.1.0.0A (AS 7.2.0 Final- redhat-8)

I read the Security info found here : Security Guide - Teiid 8.7 - Project Documentation Editor

Based on that, I am using HTTP basic auth to access the /odata web application by setting the auth header in a REST client.  I also made sure that the "embedded" transport security-domain is the same security-domain specified in the

odata jboss-web.xml file included in the odata WAR. Further, I made sure I had a userId defined in user properties that was associated with the odata role.

I deployed the odata war file and can hit a URL to get the metadata for a VDB. For example,  http://localhost:8080/odata/vdbName/$metadata.    If I try to do a GET for a resource to get an entity, I get teiid50090.   The URL follows this pattern

when I get this issue :  http://localhost:8080/odata/vdbName/model.view  , where "model" is a schema available in the VDB and "view" is a "view" defined in the schema. There is a primary key defined.

Given the security guide article I cite above, my expectation is that pass-through authorization should handle this case. It seems, though, that the context isn't available to do the check.

I'm not that conversant with JBoss security considerations and I'm most likely overlooking some thing basic, so your help would be greatly appreciated.

Thanks and Best Regards,

Greg

[shawkins]

So there are a couple of possibilities here.

The first is that your context is null from the start.  A detail log will show whether an authentication attempt is being made for your user.

The other is that the context is null because the connection is effectively being reused after a close/logoff.  However that seems unlikely.

[gmackinnon]

Hi Steven,

I increased the logging level.

This log snippet shows the principal associated with the "odata" role being authenticated :

08 May 2014 16:22:32,685 DEBUG [org.apache.catalina.authenticator] (http-/0.0.0.0:8080-1)  Authenticated 'wittgenstein' with type 'BASIC'^M

08 May 2014 16:22:32,685 DEBUG [org.apache.catalina.authenticator] (http-/0.0.0.0:8080-1)   Calling accessControl()^M

08 May 2014 16:22:32,685 DEBUG [org.apache.catalina.realm] (http-/0.0.0.0:8080-1)    Checking roles GenericPrincipal[wittgenstein(odata,)]^M

08 May 2014 16:22:32,685 DEBUG [org.apache.catalina.realm] (http-/0.0.0.0:8080-1)  JBWEB000017: User [wittgenstein] has role [odata]^M

08 May 2014 16:22:32,686 TRACE [org.jboss.as.web.security] (http-/0.0.0.0:8080-1)  hasRole:RealmBase says:true::Authz framework says:true:final=true^M

08 May 2014 16:22:32,686 DEBUG [org.apache.catalina.realm] (http-/0.0.0.0:8080-1)  Role found: odata^M

08 May 2014 16:22:32,686 TRACE [org.jboss.as.web.security] (http-/0.0.0.0:8080-1)  hasResourcePermission:RealmBase says:true::Authz framework says:true:final=true^M

08 May 2014 16:22:32,686 DEBUG [org.apache.catalina.authenticator] (http-/0.0.0.0:8080-1)   Successfully passed all security constraints^M

...

When running in the debugger, I see that the connectionProperties (Properties) instance passed into the org.teiid.transport.LocalServerConnection constructor does not contain a DQPWorkContext object.

Consequently a local DQPWorkContext is instantiated in LocalServerConnection.  This local DQPWorkContext instance is used to fetch parameters for the call to JBossSecurityHelper.sameSubject(String securityDomain,

Object context, Subject subject) and all three parameters are null. Hence, the teiid50090 given the check for a null context at the head of the sameSubject() method.

Thanks, Steven.

Greg

[shawkins]

> When running in the debugger, I see that the connectionProperties (Properties) instance passed into the org.teiid.transport.LocalServerConnection constructor does not contain a DQPWorkContext object.

That is expected.  We only populate that when making a child connection off of the CommandContext.

> This local DQPWorkContext instance is used to fetch parameters for the call to JBossSecurityHelper.sameSubject(String securityDomain,Object context, Subject subject) and all three parameters are null.

Prior to that point in time though the connection should have had a login/authenticate call which should establish your Teiid session.  And then you should only make the sameSubject check when workContext.getSession().getSessionId() is not null implying there is a session.  Do you have any logs from the Teiid session service?

[shawkins]

Specifically are you seeing TEIID40117 in the detail log, which would indicate that no security domains are configured.

[shawkins]

Was this also resolved with the patch change from Unable to connect to Teiid Server using custom Security Domain?

[gmackinnon]

Hi Steven,

I don't know if TEIID40117 was logged in the detail log. I can recreate the problem and see if that message is being logged.  I'll have to check to see if I have the patch you reference applied.

What I have done to workaround this is not use PassthroughAuthentication mode (in effect, set it to false when the LocalClient is being constructed). If I do that, then I am effectively able to retrieve arbitrary OData entities successfully.

[shawkins]

> What I have done to workaround this is not use PassthroughAuthentication mode (in effect, set it to false when the LocalClient is being constructed).

At that point you are effectively using static credentials rather than propagating the authenticated user from the web layer.  Yes, let us know if this is still happening after looking into the CA specific patches.

[gmackinnon]

This issue appears to have been addressed.

Thanks, Steven.

Best Regards,

Greg