May 2013 - teiid-issues - Jboss List Archives

[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

1
0
0 / 0

[JBoss JIRA] (TEIID-2471) Allow permission conditions and masking to be pluggable

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2471?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2471: --------------------------------------- They are, but ideally I want us to start treating the security concerns as if they were just like any other metadata (eventually specifiable through grant statements). > 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

1
0
0 / 0

[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

1
0
0 / 0

[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: ------------------------------------- The VDB extension point is similar to AuthorizationValidator/PolicyDecider right? The may be scoped to system. Then why not modify them? > 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

1
0
0 / 0

[JBoss JIRA] (TEIID-2509) Attempt to create second salesforce source fails

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-2509?page=com.atlassian.jira.plugin... ] Ramesh Reddy reassigned TEIID-2509: ----------------------------------- Assignee: Ramesh Reddy > 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: Ramesh Reddy > 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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues May 2013