Re: [jboss-dev-forums] [JBoss AS 7 Development] - Access control notes
by Darran Lofthouse
Darran Lofthouse [https://community.jboss.org/people/dlofthouse] commented on the document
"Access control notes"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-48596#comment-11919
--------------------------------------------------
In the general tasks section there are a couple of lines mentioning "Enforce Permissions" in web console and CLI - I would suggest there should be no mention on client side enforcement as that is just not enforcement - all of that needs to be on the server side.
What these clients do need is appropriate meta data to be returned to allow them to be able to still run intuitively against the server. The alternative is each client needs to be updated to understand the permissions model and act accordingly, the down side of this is now we need to maintain it in multiple locations with
This in turn implies to me that anything server side needs to be more than just enforcement i.e. performing an authorization check at the time of an attempt to access the model / execute an operation is the bare minimum - we potentially need to be able to go beyond this to pro-actively identify what can or can not be accessed.
As we have mentioned previously for any permissions schema to be secure it needs to be understandable, one possibility here is to look at ways to show the effect of the currently defined permissions scheme on the domain model. This could be something along the lines of generating a report which visualises the tree and highlights what can and can not be accessed by a specific user / role - alternatively social networks commonly have a view profile as option to see what others can see, this could be a mode to consider in the console.
Some of these items might be out of scope for this phase of development but just wanted to raise them so we can at least take them into account.
--------------------------------------------------
12 years, 8 months
[JBoss AS 7 Development] - Access control notes
by Brian Stansberry
Brian Stansberry [https://community.jboss.org/people/brian.stansberry] modified the document:
"Access control notes"
To view the document, visit: https://community.jboss.org/docs/DOC-48596
--------------------------------------------------------------
h1. Objective
By early September to implement a simplified domain management access control solution suitable for both AS 8 and EAP 6.x.
The primary objective is to establish a simple set of roles with which users can be associated, with clear sets of operation execution permissions associated with each role. The second critical objective is to develop an architecture for authorization that will allow for a much more generic/flexible authorization scheme to be implemented in future releases without breaking the simple scheme we do now.
Actually providing a generic scheme is out of scope for AS 8.
h1. Team and Timeline
Full time: Heiko Braun, Darran Lofthouse, Kabir Khan, Brian Stansberry
Available to assist as needed: Jason Greene, Anil Saldhana, subsystem leads
Design Phase I:
+ Lay out the fundamental architecture, identify the main requirements and intended approach for meeting each
+ 2 weeks
+ Completion allows some aspects of dev to begin (which, TBD)
+ Inability to get the stated time commitments from all participants delays completion by that amount of time
Design Phase II:
+ Design in detail some of the fundamental areas where either coordinated design is required or a sub-team needs to flesh out details
+ 2 weeks
Dev Phase:
+ 2.5 months
+ Achieve feature completion
+ See tasks below
++ need to assign resources and timelines to each task.
Dev Test Phase:
+ hardening period
+ 1 month
+ ends Sept 6
QE Phase:
+ begins following September 6 end of Dev Test Phase
h1. Tasks
*General Tasks*
- Provide a permission model, storage and API
- Enable configuration of the permission model
- Provide operations to retrieve permission meta data
- Enforce permissions in core management compoments (mapping of permission model against resources)
- Enforce permissions in web console (mapping of permission model against interaction units and use cases)
- Enforce permissions in CLI (mapping of permission model against command line syntax and use cases)
*Component Breakdown*
Core Management Compoments
*
*
interface to decision point
+ information about resource access request
+ information about user
+ other information about request (time of day, interface, etc)
misc op authorization
+ basic control over op execution
write-attribute/undefine-attribute authorization
add op authorization
+ trick here is cases where certain attributes can't be written
++ my instinct is to reject the add; no sophisticated rules
read-attribute authorization
read-resource authorization, output control to use response header to indicate content was filtered
configuration of our default decision point
user info configuration (what data to provide decision point, where to get it)
read-resource-access op (an op to learn about user's ability to use API; based on read-resource-description)
+ uses
++ general information
++ allow caller to disable features that will be non-functional (e.g. buttons for misc ops that are not available)
model-reference issues
+ general issue of resources in a tree being affected by other resources
+ server groups
++ user has rights to a resource that affects an SG, but not to the SG itself
+ hosts
++ similar issue
++ twist is host-specific config vs domain-wide config affecting server's on a host
+ others?
+ notion: enforce this at domain rollout time?
++ problem: what about an admin-only HC situation? -- no rollout
Configuration propagation
++ master HC to slave
JMX security
+ AS domains depend on core security, as they just delegate
++ provide some information about access mechanism
+ other mbeans
++ what policy?
++ what control point?
Web Console
+ the interface structure doesn't necessarily refelct the model structure
++ i.e. some coarse grained interface compoments rely on a number of resources across the model
+ distinction between interface structure (interaction units) and DMR payload
+ suppression of interaction units can only be done if the screens properly bootstrap from the model
++ relates to "read-resource-access"
++ currently not the case and a major change (intended first prototype for AS8)
+ distinction between logical entities and resource tree structure
++ i.e. /subsystem=datasources is resource tree structure
++ datasource=ExampleDS is a logical entity within the tree structure
++ makes a diference for address pattern matching...
+ do we support security constraints for logical entities? (can see datasource "Foo" but not datasource "Bar")
++ relates to "model-reference issues".
CLI
+ basic handling of low-level (should be ok)
+ disable high-level commands in advance?
+ ls -- high-level equivalent to read-resource
Misc issues:
sniffing for resources -- request a resource to learn it exists from the failure response
h2. Permission Model
+ Should we aim for a mapping of resources onto a permission model?
++ Do we provide the permission model?
++ For a starting point see: https://community.jboss.org/docs/DOC-47854 https://community.jboss.org/wiki/ManagementLayerAccessControl
h1. Resource and Action Attributes
The following describes attributes required as inputs to a authorization mechanism, which that mechanism would use to enforce some permission schemes we've heard of. The assumption was the authorization mechanism would be some form of Attribute Based Access Control, although the use of ABAC is not a requirement. The terms "Resource Attributes" and "Action Attributes" is derived from the XACML spec, which notes that "Information security policies operate upon attributes of subjects, the resource, the action and the environment in order to arrive at an authorization decision." This section is concerned with identifying relevant attributes of the management resources toward which an operations is targetted, as well as the relevant attributes of the operation itself.
DMR API and Wireformat
+ separate static security meta data from dynamic runtime headers?
++ static: part of "read-resource-access"
++ dynamic: indication of enforced constraints as part of a DMR response (i.e suppressed elements)
h4. Scheme 1:
Monitor:
-- read-only flag on the operation
Configurator:
-- Storage flag on attribute
-- flag on operation to indicate runtime-only
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Operator:
-- Storage flag on attribute
-- flag on operation to indicate runtime-only
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Administrator
-- resource address
Deployer
-- resource address
Admin Security Manager
-- I would consider the equivalent for us to be the ability to configure the access control policies
-- resource address
Auditor
-- resource address
h4. Scheme 2:
Anonymous
-- N/A
Admin
-- none; user is root
Deployer
seems equivalent to Scheme 3's read-write
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Operator
-- read-only flag on the operation
-- resource-address
-- operation name
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Monitor
-- read-only flag on the operation
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
h4. Scheme 3:
Read-only
-- read-only flag on the operation
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Read-write
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Privileged
-- none; user is root
This is basically equivalent to Scheme 2, without Scheme 2's "Operator".
h4. Scheme 4:
Administrator
view or modify anything; deploy apps, perform lifecycle functions
-- none; user is root
Deployer
view anything, deploy apps, perform lifecycle functions
-- read-only flag on the operation
-- resource-address
-- operation name
Operator
view anything, perform lifecycle
-- read-only flag on the operation
-- resource-address
-- operation name
Monitor
view anything
-- read-only flag on the operation
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48596]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
12 years, 8 months
Re: [jboss-dev-forums] [JBoss AS 7 Development] - Access control notes
by Brian Stansberry
Brian Stansberry [https://community.jboss.org/people/brian.stansberry] commented on the document
"Access control notes"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-48596#comment-11917
--------------------------------------------------
Second try at this after the wiki turned my first one into a repost of the main article...
Sorry, Heiko, this page was really notes to myself and wasn't really in a state for publication. But word of it got out into the wild and it needed to be made visible. I'll try and clean it up today.
The initial timing part was very much notes to myself. I do believe that's reasonable for a design phase though.
About "Request Attributes"...
The basic idea I had in mind is that authorization decisions would be made by some sort of authorization engine. The AS would define an SPI for this engine with an available set of inputs that would be provided to the engine and an expected set of outputs -- permit, deny, perhaps other stuff like the XACML "obligations" notion.
The inputs would be from 4 broad categories
1) Information about the operation.
2) Information about the resource being accessed
3) Information about the caller
4) General environmental stuff, e.g. time of day, interface the call came in on, etc. +(This last is conceptual only and not something I propose dealing with in AS 8)+
The "Request Attributes" bits above are notes to myself to identify what stuff from categories 1) and 2) above we would need to provide to a rules engine to provide sufficient input for a set of rules that map to the various "roles" concepts that we've seen in different permission schemes we've heard about. It's basically thought on how to pursue the "Rules based approach" in the wiki article Anil linked.
The idea I had at its core is the authorization system could be as flexibile as the rule grammar and the available inputs will allow. Directly configuring the set of rules allows the user the maximum flexibility. This is not something I see as being in scope for AS 8 though.
For AS 8 (and forever really) we need a simplified system with a limited number of config options that internally generates (or statically defines) a set of rules that results in behavior like one of the schemes I listed. So, if user is in role "Operator", the rules would verify whether the operation is read-only, whether the resource or attribute description has a security restriction associated etc.
Basically, the simplified system is a shorthand way of expressing a fairly complex set of rules in a user-friendly fashion.
For the future, we can see if there are other, more flexibile shorthands for creating rules (e.g. a regex scheme.) Or, if appropriate we can provide direct configurability of the rules engine.
--------------------------------------------------
12 years, 8 months
Re: [jboss-dev-forums] [JBoss AS 7 Development] - Access control notes
by Brian Stansberry
Brian Stansberry [https://community.jboss.org/people/brian.stansberry] commented on the document
"Access control notes"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-48596#comment-11915
--------------------------------------------------
h1. Timeline
Design Phase I:
+ Lay out the fundamental architecture, identify the main requirements and intended approach for meeting each
+ Main participants (67% time task):
++ Brian Stansberry, Darran Lofthouse, Heiko Braun, Jason Greene
+ Partial participants (25% time task):
++ David Lloyd, one other member of Domain Management team, Anil Saldhana, Harald Pehl
+ 2 weeks
+ Completion allows some aspects of dev to begin (which, TBD)
+ Inability to get the stated time commitments from all participants delays completion by that amount of time
Design Phase II:
+ Design in detail some of the fundamental areas where either coordinated design is required or a sub-team needs to flesh out details
+ Participants and time commitment -- same as Design Phase I
+ 2 weeks
Dev Phase:
++ TBD (see tasks below)
++ need to assign resources and timelines to each task.
Test Phase:
TBD
h1. Tasks
*General Tasks*
- Provide a permission model, storage and API
- Enable configuration of the permission model
- Provide operations to retrieve permission meta data
- Enforce permissions in core management compoments (mapping of permission model against resources)
- Enforce permissions in web console (mapping of permission model against interaction units and use cases)
- Enforce permissions in CLI (mapping of permission model against command line syntax and use cases)
*Component Breakdown*
Core Management Compoments
*
*
interface to decision point
+ information about resource access request
+ information about user
+ other information about request (time of day, interface, etc)
misc op authorization
+ basic control over op execution
write-attribute/undefine-attribute authorization
add op authorization
+ trick here is cases where certain attributes can't be written
++ my instinct is to reject the add; no sophisticated rules
read-attribute authorization
read-resource authorization, output control to use response header to indicate content was filtered
configuration of our default decision point
user info configuration (what data to provide decision point, where to get it)
read-resource-access op (an op to learn about user's ability to use API; based on read-resource-description)
+ uses
++ general information
++ allow caller to disable features that will be non-functional (e.g. buttons for misc ops that are not available)
model-reference issues
+ general issue of resources in a tree being affected by other resources
+ server groups
++ user has rights to a resource that affects an SG, but not to the SG itself
+ hosts
++ similar issue
++ twist is host-specific config vs domain-wide config affecting server's on a host
+ others?
+ notion: enforce this at domain rollout time?
++ problem: what about an admin-only HC situation? -- no rollout
Web Console
+ the interface structure doesn't necessarily refelct the model structure
++ i.e. some coarse grained interface compoments rely on a number of resources across the model
+ distinction between interface structure (interaction units) and DMR payload
+ suppression of interaction units can only be done if the screens properly bootstrap from the model
++ relates to "read-resource-access"
++ currently not the case and a major change (intended first prototype for AS8)
+ distinction between logical entities and resource tree structure
++ i.e. /subsystem=datasources is resource tree structure
++ datasource=ExampleDS is a logical entity within the tree structure
++ makes a diference for address pattern matching...
+ do we support security constraints for logical entities? (can see datasource "Foo" but not datasource "Bar")
++ relates to "model-reference issues".
CLI
+ basic handling of low-level (should be ok)
+ disable high-level commands in advance?
+ ls -- high-level equivalent to read-resource
Configuration propagation
++ master HC to slave
JMX security
+ AS domains depend on core security, as they just delegate
++ provide some information about access mechanism
+ other mbeans
++ what policy?
++ what control point?
Misc issues:
sniffing for resources -- request a resource to learn it exists from the failure response
h2. Permission Model
+ Should we aim for a mapping of resources onto a permission model?
++ Do we provide the permission model?
++ For a starting point see: https://community.jboss.org/docs/DOC-47854 https://community.jboss.org/wiki/ManagementLayerAccessControl
h1. Resource Attributes
The following describes resource attributes required to enforce some permission schemes we've heard:
DMR API and Wireformat
+ separate static security meta data from dynamic runtime headers?
++ static: part of "read-resource-access"
++ dynamic: indication of enforced constraints as part of a DMR response (i.e suppressed elements)
h4. Scheme 1:
Monitor:
-- read-only flag on the operation
Configurator:
-- Storage flag on attribute
-- flag on operation to indicate runtime-only
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Operator:
-- Storage flag on attribute
-- flag on operation to indicate runtime-only
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Administrator
-- resource address
Deployer
-- resource address
-- see IBM details at http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.ba... http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.ba... to check for more
Admin Security Manager
-- I would consider the equivalent for us to be the ability to configure the access control policies
-- resource address
Auditor
-- resource address
h4. Scheme 2:
Anonymous
-- N/A
Admin
-- none; user is root
Deployer
seems equivalent to Scheme 3's read-write
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Operator
-- read-only flag on the operation
-- resource-address
-- operation name
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Monitor
-- read-only flag on the operation
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
h4. Scheme 3:
Read-only
-- read-only flag on the operation
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Read-write
-- "security privileged" flag attribute
-- "security privileged" flag on resource
-- attribute value is a vault expression?
Privileged
-- none; user is root
This is basically equivalent to Scheme 2, without Scheme 2's "Operator".
h4. Scheme 4:
Administrator
view or modify anything; deploy apps, perform lifecycle functions
-- none; user is root
Deployer
view anything, deploy apps, perform lifecycle functions
-- read-only flag on the operation
-- resource-address
-- operation name
Operator
view anything, perform lifecycle
-- read-only flag on the operation
-- resource-address
-- operation name
Monitor
view anything
-- read-only flag on the operation
--------------------------------------------------
12 years, 8 months