[teiid-issues] [JBoss JIRA] (TEIID-2948) Implement Access Controls on management operations in Teiid

[Ramesh Reddy (JIRA)]

    [ https://issues.jboss.org/browse/TEIID-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965799#comment-12965799 ] 

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/org/jboss/as/controller/access/management/SensitiveTargetAccessConstraintDefinition.java

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-8f203031cdd66bd3a3a400d099551c4dR285


> 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)