[jboss-dev-forums] [JBoss AS 7 Development] - Access control notes

[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.base.iseries.doc/ae/rsec_adminroles.html#rsecadminroles__deployerrole http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.base.iseries.doc/ae/rsec_adminroles.html#rsecadminroles__deployerrole 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
--------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-dev-forums/attachments/20130417/ff319209/attachment-0001.html