[JBoss JIRA] (TEIID-2939) Issues with applying row based security
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2939?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2939.
-----------------------------------
Resolution: Done
Moved assign output elements after applying security.
> Issues with applying row based security
> ---------------------------------------
>
> Key: TEIID-2939
> URL: https://issues.jboss.org/browse/TEIID-2939
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.4
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.7.1, 8.8
>
>
> If a view over a left outer join has a row condition and is used in a simple aggregation:
> select count\(*) from vw
> Then a null pointer exception will occur when considering optional joins.
> If intervening criteria is added:
> select count\(*) from vw where ...
> we can get past the initial error, but will fail in initializing the join node with an assertion error. Both of these have the same root issue, which is our attempt to make the logic selective about when assign output elements is run, which leads to the output elements not being in place when later needed.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 8 months
[JBoss JIRA] (TEIID-2948) Implement Access Controls on management operations in Teiid
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2948?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2948:
-------------------------------------
Instructions from [~brian.stansberry]
In general, you modify the ResourceDefinition for your resource types or
the AttributeDefinition for your attributes to declare constraints.
Examples below. If you apply a constraint to a resource type, it applies
to all attributes and to all child resources. So you don't need to
redeclare it for children.
The constraint declarations make it possible for the core management
layer to enforce the constraint, and also let the core management layer
expose a resource for each constraint that lets an end user modify the
constraint's behavior.
There are two main aspects.
1) First is whether any of the resources in your subsystem might be
considered by some user organizations to be "application" resources vs
general container resources, and thus modifiable by an admin in our
Deployer role. Examples of things like that are JMS queues, datasources,
etc.
This type of constraint only applies to resources; not to individual
attributes.
This commit shows where this was done for all the subsystems shipped
with WF. Hopefully it's fairly self explanatory.
https://github.com/wildfly/wildfly/commit/4a9c6bc
2) Second, and more common is whether resources or attributes should be
treated as security sensitive. If so the resource/attribute is annotated
with a SensitivityClassification that declares what it is about the
resource/attribute that might be considered sensitive and whether
addressing[1]/read/write is sensitive.
The goal with sensitivity classifications is to find a kind of sweet
spot where a single setting controls a fairly broad swath of
resources/attributes. So there's a single core setting related to
credentials. There's a single core setting related to configuring sockets.
There are two categories of sensitivity classifications.
a) Subsystem-specific ones. Some resource/attribute is sensitive but the
justification for calling it that does not apply outside the subsystem.
So you create and apply your own classification.
This commit shows where this was done for all the subsystems shipped
with WF.
https://github.com/wildfly/wildfly/commit/b12fea9
b) There are also a bunch of "core" sensitivity classifications that can
be applied to any resource/attribute in any subsystem. If you look in
the commit above, you can see in a few cases those core classifications
had already been applied to some things, e.g. [2].
The core classifications are listed as constants in
https://github.com/wildfly/wildfly/blob/master/controller/src/main/java/o...
There are a few of those that often apply to subsystem resources/attributes:
CREDENTIAL -- the attribute stores a username or password or other kind
of credential
SECURITY_DOMAIN_REF -- the attribute stores the name of a security domain
SECURITY_REALM_REF -- the attribute stores the name of a security realm
SOCKET_BINDING_REF -- the attribuet stores the name of a socket binding
SOCKET_CONFIG -- the attribute in some other way configures a socket
You can also apply constraints to individual operations. Let me know if
you want to do that.
[1] Addressing refers to even being able to confirm the existing of a
resource at a given address, e.g. via the read-children-names operation
invoked on its parent. In a few cases the address itself contains
sensitive data, e.g. the names of security realms.
[2]
https://github.com/wildfly/wildfly/commit/b12fea9#diff-8f203031cdd66bd3a3...
> Implement Access Controls on management operations in Teiid
> -----------------------------------------------------------
>
> Key: TEIID-2948
> URL: https://issues.jboss.org/browse/TEIID-2948
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Fix For: 8.7.1
>
>
> EAP 6.2 and above provides facilities to implement access controls on the management operations. Teiid should implement them on the management operations so that they can be controlled by access level of the user.
> Unfortunately this is not in EAP 6.1.Alpha, so it becomes hard to pull the changes upstream into 8.8
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 8 months
[JBoss JIRA] (TEIID-2948) Implement Access Controls on management operations in Teiid
by Ramesh Reddy (JIRA)
Ramesh Reddy created TEIID-2948:
-----------------------------------
Summary: Implement Access Controls on management operations in Teiid
Key: TEIID-2948
URL: https://issues.jboss.org/browse/TEIID-2948
Project: Teiid
Issue Type: Feature Request
Components: Server
Reporter: Ramesh Reddy
Assignee: Ramesh Reddy
Fix For: 8.7.1
EAP 6.2 and above provides facilities to implement access controls on the management operations. Teiid should implement them on the management operations so that they can be controlled by access level of the user.
Unfortunately this is not in EAP 6.1.Alpha, so it becomes hard to pull the changes upstream into 8.8
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 8 months
[JBoss JIRA] (TEIID-2902) More incremental join when a limit is present
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2902?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2902:
---------------------------------------
Not making much head way here as all of the sorting logic / join logic is fairly entangled and generally expects to read all values as part of the sorting operation (for example if any prefetch is performed, we'll read everything even before performing a single pass sort).
It looks like it would be easier to start over somewhat to avoid attempting to retro-fit too much.
> More incremental join when a limit is present
> ---------------------------------------------
>
> Key: TEIID-2902
> URL: https://issues.jboss.org/browse/TEIID-2902
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Affects Versions: 8.7
> Reporter: Ivan Chan
> Assignee: Steven Hawkins
> Fix For: 8.8
>
>
> For SQL like:
> SELECT
> t1.column1,
> t2.column1
> FROM
> schema1.table1 t1,
> schema2.table1 t2
> WHERE
> t1.column2=t2.column2
> LIMIT 100
> Teiid may get the whole schema1.table1 content and the whole schema2.table1 content, do the join in memory and then, limit the resultset to 100 records.
> However, I think teiid can fetch smaller set of data then do a join. If the join result set is less than number of rows asking, keep fetching next set of data and do a join until hits the limit number.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 8 months
[JBoss JIRA] (TEIID-2913) Enhance Logging Quickstart
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-2913?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-2913:
------------------------------------
With the addition of command and audit logging to the core services of Teiid, the quick start will now be improved based on those features. So it will no longer include the sample appenders.
> Enhance Logging Quickstart
> --------------------------
>
> Key: TEIID-2913
> URL: https://issues.jboss.org/browse/TEIID-2913
> Project: Teiid
> Issue Type: Enhancement
> Components: Quick Starts
> Affects Versions: 8.7.1
> Reporter: Van Halbert
> Assignee: Van Halbert
>
> Add the following enhancements to the logging quick start:
> - add example for audit logging to a database (use h2)
> - add dynamic VDB's to expose the audit and command logging schemas
> - add a preconfigured dashboard to present the audit and command logs
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 8 months
[JBoss JIRA] (TEIID-2938) Provide ability to write command and audit logging to database
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2938?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2938:
-------------------------------------
Since this is separate project, it will not be available with core Teiid libraries, this will be a add-on. Will provide a download link on the downloads page during the 8.8 release. The instructions for installation are defined on readme file on the project. Will add a blurb about it in Teiid docs.
> Provide ability to write command and audit logging to database
> --------------------------------------------------------------
>
> Key: TEIID-2938
> URL: https://issues.jboss.org/browse/TEIID-2938
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 8.7
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Fix For: 8.7.1, 8.8
>
>
> Provide ability for command logging and audit logging to write to the database.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 8 months