[JBoss JIRA] (TEIID-2471) Allow permission conditions and masking to be pluggable
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2471?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2471:
-------------------------------------
In that case option (2) sounds good, but not as extension point but extending the MetadataRepository itself in scope of the Schema. We can deprecate current VDB scoped data roles, and for backwards compatibility, since all the resources are fully qualified we can inject that metadata during VDB load into respective MetadatReporitory.
> Allow permission conditions and masking to be pluggable
> -------------------------------------------------------
>
> Key: TEIID-2471
> URL: https://issues.jboss.org/browse/TEIID-2471
> Project: Teiid
> Issue Type: Sub-task
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.4
>
>
> The AuthorizationValidator or similar interface should allow for alternative implementations to be plugged in for providing permission conditions and column masking.
--
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, 10 months
[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:
---------------------------------------
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.
> 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.4
>
>
> 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, 10 months
[JBoss JIRA] (TEIID-2508) Admin api getSchema fails for long schema
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2508?page=com.atlassian.jira.plugin... ]
Ramesh Reddy reassigned TEIID-2508:
-----------------------------------
Assignee: Ramesh Reddy (was: Steven Hawkins)
> Admin api getSchema fails for long schema
> -----------------------------------------
>
> Key: TEIID-2508
> URL: https://issues.jboss.org/browse/TEIID-2508
> Project: Teiid
> Issue Type: Bug
> Components: AdminApi
> Affects Versions: 8.4
> Environment: Fedora 17, Teiid 8.4 Beta2, JBoss EAP 6.1 alpha
> Reporter: Mark Drilling
> Assignee: Ramesh Reddy
> Fix For: 8.4
>
> Attachments: Exception_getDDL.txt
>
>
> The admin.getSchema call to return DDL is failing for long schema (no problem with just a few tables). We had a different issue previously but this is still an issue with 8.4B2 in EAP6.1Alpha. Attaching server stacktrace.
--
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, 10 months
[JBoss JIRA] (TEIID-2508) Admin api getSchema fails for long schema
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2508?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2508:
---------------------------------------
I take this back. The DMR version that we use 1.1.6 has proper handling for writing and reading values above the utf length limit. You must be using an older client admin api.
> Admin api getSchema fails for long schema
> -----------------------------------------
>
> Key: TEIID-2508
> URL: https://issues.jboss.org/browse/TEIID-2508
> Project: Teiid
> Issue Type: Bug
> Components: AdminApi
> Affects Versions: 8.4
> Environment: Fedora 17, Teiid 8.4 Beta2, JBoss EAP 6.1 alpha
> Reporter: Mark Drilling
> Assignee: Steven Hawkins
> Fix For: 8.4
>
> Attachments: Exception_getDDL.txt
>
>
> The admin.getSchema call to return DDL is failing for long schema (no problem with just a few tables). We had a different issue previously but this is still an issue with 8.4B2 in EAP6.1Alpha. Attaching server stacktrace.
--
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, 10 months
[JBoss JIRA] (TEIID-2508) Admin api getSchema fails for long schema
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2508?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2508:
----------------------------------
Fix Version/s: 8.4
In looking at the DMR source, this is a limitation of their framework. Any string value is written out using the writeUTF method that limits string length to 65535. It may be worth logging an issue against DMR, but I'm not sure that is something that would change at this point. Another option for us would be to set the result as bytes or some other value type.
> Admin api getSchema fails for long schema
> -----------------------------------------
>
> Key: TEIID-2508
> URL: https://issues.jboss.org/browse/TEIID-2508
> Project: Teiid
> Issue Type: Bug
> Components: AdminApi
> Affects Versions: 8.4
> Environment: Fedora 17, Teiid 8.4 Beta2, JBoss EAP 6.1 alpha
> Reporter: Mark Drilling
> Assignee: Steven Hawkins
> Fix For: 8.4
>
> Attachments: Exception_getDDL.txt
>
>
> The admin.getSchema call to return DDL is failing for long schema (no problem with just a few tables). We had a different issue previously but this is still an issue with 8.4B2 in EAP6.1Alpha. Attaching server stacktrace.
--
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, 10 months
[JBoss JIRA] (TEIID-2509) Attempt to create second salesforce source fails
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2509?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2509:
----------------------------------
Assignee: (was: Steven Hawkins)
Given that the service name is from the AS layer, this may be an AS issue. Unlike for example TEIID-2121 which was our service.
If this only affects sf, we'll likely push to 8.4.1.
> Attempt to create second salesforce source fails
> ------------------------------------------------
>
> Key: TEIID-2509
> URL: https://issues.jboss.org/browse/TEIID-2509
> Project: Teiid
> Issue Type: Bug
> Components: AdminApi
> Affects Versions: 8.4
> Environment: Fedora 17, Teiid 8.4 Beta2, JBoss EAP 6.1 alpha
> Reporter: Mark Drilling
> Attachments: Exception_duplicateSF.txt
>
>
> Attempt to create a second salesforce datasource via the Admin api fails (stacktrace attached). When I restart the server, it appears.
> I tried the same scenario with the Twitter WS example and it worked - did not need to restart server.
--
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, 10 months
[JBoss JIRA] (TEIID-2509) Attempt to create second salesforce source fails
by Mark Drilling (JIRA)
Mark Drilling created TEIID-2509:
------------------------------------
Summary: Attempt to create second salesforce source fails
Key: TEIID-2509
URL: https://issues.jboss.org/browse/TEIID-2509
Project: Teiid
Issue Type: Bug
Components: AdminApi
Affects Versions: 8.4
Environment: Fedora 17, Teiid 8.4 Beta2, JBoss EAP 6.1 alpha
Reporter: Mark Drilling
Assignee: Steven Hawkins
Attachments: Exception_duplicateSF.txt
Attempt to create a second salesforce datasource via the Admin api fails (stacktrace attached). When I restart the server, it appears.
I tried the same scenario with the Twitter WS example and it worked - did not need to restart server.
--
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, 10 months