[teiid-issues] [JBoss JIRA] (TEIID-2948) Implement Access Controls on management operations in Teiid
Ramesh Reddy (JIRA)
issues at jboss.org
Fri May 9 08:49:56 EDT 2014
[ https://issues.jboss.org/browse/TEIID-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12966761#comment-12966761 ]
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)
More information about the teiid-issues
mailing list