[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:
-------------------------------------
On 5/7/14, 9:21 AM, Ramesh Reddy wrote:
> Thanks again, this is very good. The one thing I still do not get it is the following statement
>
>> The core operation execution logic knows whether the operation step
>> handler is trying to address, read, or write.
>
> I can understand for attributes, and application resources the above can be possible. But the operations are like procedure, apart from addressing, core logic will have no way of knowing a custom operations like "get-translators" in Teiid whether it is performing read/write. I am confused as how to control those as they only need "execute" permission.
The control is via the implementation of the OperationContext interface.
An OperationStepHandler needs to go through the OperationContext to do
most anything. The API of the various OC methods allows us to see if the
intent is to read or write. There are readXXX and readXXXForUpdate
methods, former are reads, latter are writes. The
getServiceTarget(boolean modify) method lets us determine if the intent
is to write via the "modify" param. The removeService methods are of
course writes.
If there is something your handlers do that isn't covered by that,
please let me know some details. The OC also has some "authorize"
methods, but they were added to cover some use cases in the core, I
don't like the API much, and I'd much prefer if subsystems don't use those.
The above covers the actual permission enforcement during operation
execution. We also want to include information about access control in
the response data for read-resource-description and
read-operation-description. This information allows clients like the
console to tailor their UI. For this we can't use the actual actions of
the OSH; we need to rely on the resource/attribute/operation description.
For operations, you can provide necessary information via the following
methods in SimpleOperationDefinitionBuilder:
setReadOnly() -- tells us the op will only read.
setRuntimeOnly() -- tells us the op will not deal with the persistent
config. This is only relevant for write ops, as we have no roles that
can read runtime but not persistent config or vice versa.
For an attribute, the API for registering it with the
ManagementResourceRegistration tells us whether is is read-only or
read-write. The builders for AttributeDefinitions also include a
setStorageRuntime() method -- if you use that we know that an attribute
is not persisted to the xml config file, so we can let the Operator role
modify it.
> 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)
11 years, 11 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:
-------------------------------------
How are operations handled?
That's interesting; there are only 9 cases of this in the subsystems
that ship in WF itself. I didn't say this before, but you don't need to
configure constraints on ops if they are the same as the constraints on
the target resource.
There's an API for definining an operation that's analogous to
ResourceDefinition and AttributeDefinition. It's
org.jboss.as.controller.OperationDefinition. You provide
AccessConstraintDefinition... to its constructor. You use it from
ResourceDefinition.registerOperations by calling
ManagementResourceRegistration.registerOperationHandler(OperationDefinition
definition, OperationStepHandler handler, [boolean inherited])
An OperationDefinition is usually created using a builder class,
SimpleOperationDefinitionBuilder that has an addAccessConstraint method,
just like SimpleAttributeDefinitionBuilder does for attributes.
One of the commits I linked before has a use of this at
https://github.com/wildfly/wildfly/commit/b12fea9#diff-7
You can also see a fair number of examples in the modcluster module in
that commit.
> 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)
11 years, 11 months
[JBoss JIRA] (TEIID-2952) Crypto exception with client/server running on different java versions
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2952?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2952.
-----------------------------------
Resolution: Done
Added a check to see if the secret is less than the expected 1024 bits (which should only occur when the leading byte is 0).
The logic emulates the Java 7 handling so this change may cause issues for certain working client/server combinations involving Java 6. As long as both client are patched, then everything will work as expected.
> Crypto exception with client/server running on different java versions
> ----------------------------------------------------------------------
>
> Key: TEIID-2952
> URL: https://issues.jboss.org/browse/TEIID-2952
> Project: Teiid
> Issue Type: Feature Request
> Components: JDBC Driver, Server
> Affects Versions: 7.7
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 8.7.1, 8.8
>
>
> The DiffieHellman key generation logic varies by platform with the handling of leading 0's in the secret. 1.6 seems to strip while most 1.7 vms do not. A related Java bug is http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8014618 which indicates Sun/OpenJDK JRE 7u17 - 8b94 are affected.
> If there is conflicting handling between the client/server then approximately 1 out of 256 connection attempts will fail with a bad padding exception, since the client/server will be operating against different symmetric keys.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (TEIID-2952) Crypto exception with client/server running on different java versions
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-2952:
-------------------------------------
Summary: Crypto exception with client/server running on different java versions
Key: TEIID-2952
URL: https://issues.jboss.org/browse/TEIID-2952
Project: Teiid
Issue Type: Feature Request
Components: JDBC Driver, Server
Affects Versions: 7.7
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Priority: Critical
Fix For: 8.7.1, 8.8
The DiffieHellman key generation logic varies by platform with the handling of leading 0's in the secret. 1.6 seems to strip while most 1.7 vms do not. A related Java bug is http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8014618 which indicates Sun/OpenJDK JRE 7u17 - 8b94 are affected.
If there is conflicting handling between the client/server then approximately 1 out of 256 connection attempts will fail with a bad padding exception, since the client/server will be operating against different symmetric keys.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (TEIID-2950) Do not schema-qualify the DDL constraint references if they are within the current schema
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2950?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2950.
-----------------------------------
Fix Version/s: 8.7.1
8.8
Resolution: Done
The resolving logic already checks against the current schema first, so it's fine to make this change back. However we do have a potential ambiguity since we allow multi-part names in an unquoted manner, but that is a larger issue than this one.
> Do not schema-qualify the DDL constraint references if they are within the current schema
> -----------------------------------------------------------------------------------------
>
> Key: TEIID-2950
> URL: https://issues.jboss.org/browse/TEIID-2950
> Project: Teiid
> Issue Type: Enhancement
> Components: AdminApi
> Affects Versions: 8.7
> Reporter: Mark Drilling
> Assignee: Steven Hawkins
> Fix For: 8.7.1, 8.8
>
>
> The DDL constraint statements now contain the model name in order to qualify the schema. For example :
> CONSTRAINT FK_Account_ParentId FOREIGN KEY(ParentId) REFERENCES importVDBSrcModel.Account (Id)
> Request that the schema be dropped if the reference is within the current schema.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (TEIID-2951) rate limit the creation of scrollable results
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-2951:
-------------------------------------
Summary: rate limit the creation of scrollable results
Key: TEIID-2951
URL: https://issues.jboss.org/browse/TEIID-2951
Project: Teiid
Issue Type: Enhancement
Components: Query Engine
Affects Versions: 8.4
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 8.8
Related to TEIID-2461, we should also limit the rate at which scrollable results are created.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (TEIID-2950) Do not schema-qualify the DDL constraint references if they are within the current schema
by Mark Drilling (JIRA)
Mark Drilling created TEIID-2950:
------------------------------------
Summary: Do not schema-qualify the DDL constraint references if they are within the current schema
Key: TEIID-2950
URL: https://issues.jboss.org/browse/TEIID-2950
Project: Teiid
Issue Type: Enhancement
Components: AdminApi
Affects Versions: 8.7
Reporter: Mark Drilling
Assignee: Steven Hawkins
The DDL constraint statements now contain the model name in order to qualify the schema. For example :
CONSTRAINT FK_Account_ParentId FOREIGN KEY(ParentId) REFERENCES importVDBSrcModel.Account (Id)
Request that the schema be dropped if the reference is within the current schema.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (TEIID-2932) Datastax: fail to access PortfolioDemo (demo schema that provided by Datastax)
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2932?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2932:
---------------------------------------
Since I don't have a datastax install handy it may be quicker just to check the metadata directly. Under the covers the 1.0.4 driver is effectively processing:
SELECT * FROM system.schema_columns where keyspace_name = 'keyspace'
Ivan can you issue that and see if any of the column_name entries are null?
> Datastax: fail to access PortfolioDemo (demo schema that provided by Datastax)
> -------------------------------------------------------------------------------
>
> Key: TEIID-2932
> URL: https://issues.jboss.org/browse/TEIID-2932
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7
> Environment: Datastax with Teiid 8.7 CR
> Reporter: Ivan Chan
> Assignee: Steven Hawkins
> Fix For: 8.8
>
>
> Fail to access PortfolioDemo (demo schema that provided by Datastax) and the the following exception:
> java.lang.NullPointerException
> at org.teiid.metadata.MetadataFactory.addColumn(MetadataFactory.java:204)
> at org.teiid.translator.cassandra.CassandraMetadataProcessor.addColumnsToTable(CassandraMetadataProcessor.java:101)
> at org.teiid.translator.cassandra.CassandraMetadataProcessor.addTable(CassandraMetadataProcessor.java:63)
> at org.teiid.translator.cassandra.CassandraMetadataProcessor.process(CassandraMetadataProcessor.java:50)
> at org.teiid.translator.cassandra.CassandraMetadataProcessor.process(CassandraMetadataProcessor.java:42)
> at org.teiid.translator.ExecutionFactory.getMetadata(ExecutionFactory.java:915)
> at org.teiid.query.metadata.NativeMetadataRepository.loadMetadata(NativeMetadataRepository.java:73)
> at org.teiid.query.metadata.ChainingMetadataRepository.loadMetadata(ChainingMetadataRepository.java:55)
> at org.teiid.runtime.EmbeddedServer.loadMetadata(EmbeddedServer.java:685)
> at org.teiid.runtime.AbstractVDBDeployer.loadMetadata(AbstractVDBDeployer.java:161)
> at org.teiid.runtime.EmbeddedServer.deployVDB(EmbeddedServer.java:635)
> at org.teiid.runtime.EmbeddedServer.deployVDB(EmbeddedServer.java:547)
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months