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

[ 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... -- This message was sent by Atlassian JIRA (v6.2.3#6260)