[ https://issues.jboss.org/browse/TEIID-2327?page=com.atlassian.jira.plugin... ] Steven Hawkins edited comment on TEIID-2327 at 5/20/13 3:55 PM: ---------------------------------------------------------------- Switched the mask order to specify precedence, so the highest value is first (the default 0 will nominally be last). Also allowed the condition to be used with the mask, for example given the permissions in two roles of: <permission> <resource-name>myTable.T2.col1</resource-name> <mask order="1">col2</mask> </permission> <permission> <resource-name>myTable.T2.col1</resource-name> <condition>col1 = user()</condition> <mask order="2">col1</mask> </permission They will effectively be combined as the mask expression: case when col1 = user() then col1 else when true then col2 else col1 end More on the implementation: - row filters are applied before masking. - The affects of filtering/masking happen logically when the resource is accessed - and not just during the final projection. RuleApplySecurity handles the application of security which occasionally necessitates inserting view layer to keep proper plan positioning. - filtering and masking are allowed on virtual/physical tables/procedures - if the condition is a constraint (the default) it will also be applied as an insert/update constraint for physical updates. we may want to consider making it applicable to views as well. - the row/column security is always in effect. This may need to be refined as well. The means that if a view and physical table row/column security is specified, then the table affect will happen first. Also if row/column security is applicable to resources referenced in the conditions/masks (via subqueries) the affect of security is still applied. A separate JIRA TEIID-2507 was logged specifically for lookups, which are prone to creating global results for something that should of a lesser scope. was (Author: shawkins): Switched the mask order to specify precedence, so the highest value is first (the default 0 will nominally be last). Also allowed the condition to be used with the mask, for example given the permissions in two roles of: <permission> <resource-name>myTable.T2.col1</resource-name> <mask order="1">col2</mask> </permission> <permission> <resource-name>myTable.T2.col1</resource-name> <condition>col1 = user()</condition> <mask order="2">col1</mask> </permission They will effectively be combined as the mask expression: case when col1 = user() then col1 else when true then col2 end More on the implementation: - row filters are applied before masking. - The affects of filtering/masking happen logically when the resource is accessed - and not just during the final projection. RuleApplySecurity handles the application of security which occasionally necessitates inserting view layer to keep proper plan positioning. - filtering and masking are allowed on virtual/physical tables/procedures - if the condition is a constraint (the default) it will also be applied as an insert/update constraint for physical updates. we may want to consider making it applicable to views as well. - the row/column security is always in effect. This may need to be refined as well. The means that if a view and physical table row/column security is specified, then the table affect will happen first. Also if row/column security is applicable to resources referenced in the conditions/masks (via subqueries) the affect of security is still applied. A separate JIRA TEIID-2507 was logged specifically for lookups, which are prone to creating global results for something that should of a lesser scope. -- 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