Data roles usage

[dvanmil]

Hello,

I have the following situation:

- teiid 9.0.3

- some models that I want to expose by odata4 (done)

Now I want to achieve that some roles have read access permission to some models and some have more permissions on the models.

Using the teiid data roles seemed a good solution to me, so I planned to:

- define two odata web endpoints, one with a security constraint (when a logged in user is needed) and one without (but that could use some kind of default role)

- Use the teiid data roles I (apparently) need a user for every request, so I configured the "teiid-security" security domain with the "unauthenticatedIdentity" module option so a user is always available.

- I defined read only access on some (view)models and enabled the "apply this role to all users" option so everyone gets read access (?)

But at a request I still get the "User <anonymous> is not entitled to action <READ> for 1 or more of the groups/elements/procedures..." error and I am not allowed to read the data.

My questions are:

- should the above work?

- are there better solutions for more fine grained data roles etc.?

- why doesn't teiid get the user defined in the "unauthenticatedIdentity" option from the JBoss Security context etc.

Thanks in advance,

Daniel.

[rareddy]

Daniel,

You usecase is pretty legitimate, I am trying to see how it can fit the needs. I still do not have an answer, but let me see if I can explain through below picture of inner security workings

The above describes the security interactions, inside a WildFly/Teiid server when issue a OData call. The OData WAR file is deployed at context "odata4", and this context is setup OOB with HTTP Basic authentication. I.e security check happens with security domain/login module here. Once the user is logged in, the same user security context is inline passed to the Teiid Engine over a JDBC connection. Then the session service on Teiid Engine will verify the user security context is indeed a valid one issued from the security domain and will let you access to the VDB. Here VDB then will use current session's user an their role information along with data roles you defined inside the VDB to either grant or deny the access to specific resources inside the VDB.

So basically, there is web layer, and then Teiid layer in this process, work hand in hand. Now the issue with Web layer is security is pegged to a "path" a.k.a context, which in our case is "odata4". That means all the traffic on context "odata4" is subject to security challenge. There is no way you can say that half people will provide the userid/password  and half will not. The need here is we need to somehow split the context into two separate paths, where we can allow one to use the secured, another as open. Like

http://localhost:8080/odata4/ ==> secured

http://localhost:8080/odata4-nosecurity/ ==> no security, no userid/password

If we can do that, then it in the no-security case, the anonymous user over JDBC connection is used, that can get authenticated through your "unauthenticatedidentitymodule". Then if you configure "any-authenticated" role on data role to give it default permission, like "read" on VDB, it would work as you expected. Secure one already works.

The easiest way to do two contexts is deploying the "OData 4" war twice with different names and context and removing the security details from one of them. But note that by doing that, you opening your system completely wide open for any VDB that is not using data roles to control the access, if this is only VDB then that is not an issue. Next hurdle is, the code is written with understanding that "odata4" is the context, so that needs to be modified to account for that, which is not an huge issue.

There is may be another ways to solve the issue, thus I wanted to explain in detail and open it up for discussion. As I said, this is valid usecase, I am willing to put in some time to make this work, granted what proposed is the right solution.

Ramesh..

[dvanmil]

Dear Ramesh,

Thanks for the quick response. I think I understand your answer.

My problem is that although I configure the unauthenticatedidentity option with an username (different from anonymous) and enable the "apply this role to all users" teiid still logs the:

TEIID30492 User <anonymous> is not entitled to action <READ> for 1 or more of the groups/elements/procedures.: org.teiid.api.exception.query.QueryValidatorException: TEIID30492 User <anonymous> is not entitled to action <READ> for 1 or more of the groups/elements/procedures.

error, so it looks like the user is not passed to teiid correctly.

The fragment from standalone-teiid.xml:

                <security-domain name="teiid-security" cache-type="default">

                    <authentication>

                        <login-module code="RealmDirect" flag="required">

                            <module-option name="password-stacking" value="useFirstPass"/>

                            <module-option name="unauthenticatedIdentity" value="my-user"/>

                        </login-module>

                    </authentication>

                </security-domain>

Any idea?

[rareddy]

Daniel,

You can do something like

<security-domain name="teiid-security" cache-type="default">
    <authentication>
        <login-module code="RealmDirect" flag="optional">
            <module-option name="password-stacking" value="useFirstPass"/>
        </login-module>
        <login-module code="org.jboss.security.auth.spi.IdentityLoginModule" flag="required">
            <module-option name="password-stacking" value="useFirstPass"/>
    <module-option name="principal" value="guest"/>
    <module-option name="roles" value="odata"/>
        </login-module>
    </authentication>
</security-domain>

This allows a user with name guest into the system without providing username and password, or by providing null user name and null password.  Note that this opening up your system wide open for any user to come in without a passcode, and that can be serious security risk. I would not recommend it. At a minimum, I suggest you single vdb in this system and you control the rest through data roles, or configure a specific security-domain for this particular VDB.

Ramesh..