8 Replies Latest reply on Jul 15, 2014 9:19 PM by Greg MacKinnon

    teiid50090 when trying to access odata entity

    Greg MacKinnon Newbie

      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

        • 1. Re: teiid50090 when trying to access odata entity
          Steven Hawkins Master

          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.

          • 2. Re: teiid50090 when trying to access odata entity
            Greg MacKinnon Newbie

            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

             


            • 3. Re: teiid50090 when trying to access odata entity
              Steven Hawkins Master

              > 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?

              • 4. Re: teiid50090 when trying to access odata entity
                Steven Hawkins Master

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

                • 6. Re: teiid50090 when trying to access odata entity
                  Greg MacKinnon Newbie

                  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.

                  • 7. Re: teiid50090 when trying to access odata entity
                    Steven Hawkins Master

                    > 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.

                    • 8. Re: teiid50090 when trying to access odata entity
                      Greg MacKinnon Newbie

                      This issue appears to have been addressed.

                       

                      Thanks, Steven.

                      Best Regards,

                      Greg