[JBoss JIRA] (TEIID-2327) Add column masking
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2327?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2327:
---------------------------------------
This will likely not make it into 8.3 based upon other, higher-priority, work.
> Add column masking
> ------------------
>
> Key: TEIID-2327
> URL: https://issues.jboss.org/browse/TEIID-2327
> Project: Teiid
> Issue Type: Sub-task
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.3
>
>
> Support for column masking should be added to data roles. A typical approach would be to only affect the final projected values from user queries and have only one mask applicable at a time.
> A possibly related ability would be to hide columns (much like hidden tables) to our metadata.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (TEIID-2325) Add GUI handling for permission conditions
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2325?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2325:
----------------------------------
Summary: Add GUI handling for permission conditions (was: CLONE - Add simple row based security to data roles)
Assignee: (was: Steven Hawkins)
Description:
A common request is to implement row based security. Teiid has added the ability to define a permission condition for this purpose:
<permission>
<resource-name>...</resource-name>
<condition>sql</condition>
...
</permission>
The sql should resolve against the resource specified, ideally designer would check that as well.
See TEIID-2311 and the reference for how these conditions are applied.
was:
A common request is to implement row based security. The common workaround of modifying transformations is generally not a good solution.
We should look at adding support for simple table filters and column masks.
To be effective, filtering permissions however would have to act differently than normal data roles. They would need to be applied all the time - and not just against the end user queries.
For example, for tables:
<permission>
<resource-name>SCHEMA.TABLE</resource-name>
<filter>COLUMNA=2</filter>
</permission>
Meaning allow the CRUD of the given row only if COLUMNA has the value of 2. Any valid predicate against just the referenced table would be allowed as a filter. Each such permission would be applied as an additional predicate any time the table is referenced (in views, inserts, updates, deletes, etc.).
Allows would not be specified here as we want the filter to always specify inclusion. Any applicable permissions in additional roles would be applied disjunctively - filter OR filter.
We could possibly support column masks via case expressions, such as:
<permission>
<resource-name>SCHEMA.TABLE.COLUMN</resource-name>
<mask>CASE WHEN ...</mask>
</permission>
However this is slightly more complicated. Presumably the mask would only apply to projection and makes more sense to be applied at the final output/user query (more like a data role).
If we work the issue to specify the object type of a permission, then the name could alternatively refer to datatype or even an extension property to make the masking a little easier.
Complexity: Medium (was: High)
> Add GUI handling for permission conditions
> ------------------------------------------
>
> Key: TEIID-2325
> URL: https://issues.jboss.org/browse/TEIID-2325
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Affects Versions: 8.2
> Reporter: Steven Hawkins
> Fix For: 8.3
>
>
> A common request is to implement row based security. Teiid has added the ability to define a permission condition for this purpose:
> <permission>
> <resource-name>...</resource-name>
> <condition>sql</condition>
> ...
> </permission>
> The sql should resolve against the resource specified, ideally designer would check that as well.
> See TEIID-2311 and the reference for how these conditions are applied.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (TEIID-2325) CLONE - Add simple row based security to data roles
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-2325:
-------------------------------------
Summary: CLONE - Add simple row based security to data roles
Key: TEIID-2325
URL: https://issues.jboss.org/browse/TEIID-2325
Project: Teiid
Issue Type: Feature Request
Components: Query Engine
Affects Versions: 8.2
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 8.3
A common request is to implement row based security. The common workaround of modifying transformations is generally not a good solution.
We should look at adding support for simple table filters and column masks.
To be effective, filtering permissions however would have to act differently than normal data roles. They would need to be applied all the time - and not just against the end user queries.
For example, for tables:
<permission>
<resource-name>SCHEMA.TABLE</resource-name>
<filter>COLUMNA=2</filter>
</permission>
Meaning allow the CRUD of the given row only if COLUMNA has the value of 2. Any valid predicate against just the referenced table would be allowed as a filter. Each such permission would be applied as an additional predicate any time the table is referenced (in views, inserts, updates, deletes, etc.).
Allows would not be specified here as we want the filter to always specify inclusion. Any applicable permissions in additional roles would be applied disjunctively - filter OR filter.
We could possibly support column masks via case expressions, such as:
<permission>
<resource-name>SCHEMA.TABLE.COLUMN</resource-name>
<mask>CASE WHEN ...</mask>
</permission>
However this is slightly more complicated. Presumably the mask would only apply to projection and makes more sense to be applied at the final output/user query (more like a data role).
If we work the issue to specify the object type of a permission, then the name could alternatively refer to datatype or even an extension property to make the masking a little easier.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (TEIID-2311) Add simple row based security to data roles
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2311?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2311:
---------------------------------------
Added the initial check-in of row-based security. The approach is basically as outlined above. A permission element can now have a condition child:
<permission>
<resource-name>SCHEMA.TABLE</resource-name>
<condition>COLUMNA=user()</condition>
<allow-read>true</allow-read>
...
</permission>
The affected resource can be a table/view or procedure. Multiple conditions against the same resource are accumulated disjuctively. Unlike data roles, the conditions are always applied (not just at the user query). So it may be typical that the permissions are written for an any authenticated role and generalized, such as shown above with the use of the user function.
The condition can be any valid sql referencing the projected columns, but the current implementation will not correctly handle subqueries for bulk inserts (that could be addressed later if needed).
The condition is applied conjunctively to update/delete/select where clauses. That means that those queries will only ever be effective against the subset of rows that pass the condition, i.e. SELECT * FROM TBL WHERE blah AND condition
inserts and updates against tables are further validated so that the insert/change values must pass the condition (evaluate to true) for the insert/update to succeed - this is effectively the same a sql constraint. This will happen for all styles of insert/update - insert with query expression, bulk insert/update, etc. However this can inhibit pushdown in some circumstances as we have to check the values for each row. inserts/updates against views are not checked with regards to the constraint.
Further changes may be necessary to ensure that performance is not unduly harmed when the condition cannot be pushed down - most optimizations are already flexible about this case, but we could more aggressively look at raising the criteria to produce a better plan.
> Add simple row based security to data roles
> -------------------------------------------
>
> Key: TEIID-2311
> URL: https://issues.jboss.org/browse/TEIID-2311
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Affects Versions: 8.2
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.3
>
>
> A common request is to implement row based security. The common workaround of modifying transformations is generally not a good solution.
> We should look at adding support for simple table filters and column masks.
> To be effective, filtering permissions however would have to act differently than normal data roles. They would need to be applied all the time - and not just against the end user queries.
> For example, for tables:
> <permission>
> <resource-name>SCHEMA.TABLE</resource-name>
> <filter>COLUMNA=2</filter>
> </permission>
> Meaning allow the CRUD of the given row only if COLUMNA has the value of 2. Any valid predicate against just the referenced table would be allowed as a filter. Each such permission would be applied as an additional predicate any time the table is referenced (in views, inserts, updates, deletes, etc.).
> Allows would not be specified here as we want the filter to always specify inclusion. Any applicable permissions in additional roles would be applied disjunctively - filter OR filter.
> We could possibly support column masks via case expressions, such as:
> <permission>
> <resource-name>SCHEMA.TABLE.COLUMN</resource-name>
> <mask>CASE WHEN ...</mask>
> </permission>
> However this is slightly more complicated. Presumably the mask would only apply to projection and makes more sense to be applied at the final output/user query (more like a data role).
> If we work the issue to specify the object type of a permission, then the name could alternatively refer to datatype or even an extension property to make the masking a little easier.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (TEIID-2324) Error message is misleading when the model is not updatable, but an update is issued against it
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2324?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2324.
-----------------------------------
Resolution: Duplicate Issue
Worked as part of TEIID-2144
> Error message is misleading when the model is not updatable, but an update is issued against it
> -----------------------------------------------------------------------------------------------
>
> Key: TEIID-2324
> URL: https://issues.jboss.org/browse/TEIID-2324
> Project: Teiid
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 7.7.1
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Priority: Minor
>
> When trying to issue an update against a table that didn't have the updatable flag enabled, the following error occurred:
> Error Code:ERR.015.008.0009 Message:Remote org.teiid.api.exception.query.QueryResolverException: Error Code:ERR.015.008.0009 Message:Update is not allowed on the view US_CustomerAccounts_VBL.customer: a procedure must be defined to handle the Update.
> Is it possible to change the message such that it indicates the table isn't updatable?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (TEIID-2324) Error message is misleading when the model is not updatable, but an update is issued against it
by Van Halbert (JIRA)
Van Halbert created TEIID-2324:
----------------------------------
Summary: Error message is misleading when the model is not updatable, but an update is issued against it
Key: TEIID-2324
URL: https://issues.jboss.org/browse/TEIID-2324
Project: Teiid
Issue Type: Enhancement
Components: Server
Affects Versions: 7.7.1
Reporter: Van Halbert
Assignee: Steven Hawkins
Priority: Minor
When trying to issue an update against a table that didn't have the updatable flag enabled, the following error occurred:
Error Code:ERR.015.008.0009 Message:Remote org.teiid.api.exception.query.QueryResolverException: Error Code:ERR.015.008.0009 Message:Update is not allowed on the view US_CustomerAccounts_VBL.customer: a procedure must be defined to handle the Update.
Is it possible to change the message such that it indicates the table isn't updatable?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (TEIID-2063) NPE with proc relational query
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2063?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2063.
-----------------------------------
Resolution: Done
Again marking as resolved on the community side. There's no need to reopen this for the product issue as there is already a bz entry. It will just await closure until the fix version has been updated.
Also there's generally no need to update the affected version to specific point release unless the issue is introduced in that point release. Identifying the earliest minor release (7.4 here) generally indicates it affects all later releases until the fix version(s).
> NPE with proc relational query
> ------------------------------
>
> Key: TEIID-2063
> URL: https://issues.jboss.org/browse/TEIID-2063
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 7.4, 7.7.3
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.1
>
>
> A proc relational query using a table function or other source without an access node will fail with an NPE, for example:
> select param1, param2, e1, e2 from pm1.vsp26 as x, texttable('abc' columns a string) as y where param1=1 and param2='a'
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years