Access control notes

Version 22

     

     

    There are a couple of in-progress Google docs related to this work:

     

    https://docs.google.com/document/d/1_Lz8ILDuWN9ZWJSUQZGnB3DIQ1sDGR5UGPCZeP3rKvE

     

    https://docs.google.com/spreadsheet/ccc?key=0Au0knNJrYUJhdFlSSEVpdGJpQnlDOURXYTRYajhaZWc#gid=1

     

    Anyone with the link should be able to view these or comment on them. If you want to edit, please ping me with your google id.

     

    Objective

     

    By early September to implement a simplified domain management access control solution (administrative security) 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.

     

    Team and Timeline

     

    Full time: Heiko Braun, Darran Lofthouse, Kabir Khan, Brian Stansberry

    Available to assist as needed: Jason Greene, Anil Saldhana, subsystem leads

    QE: Ladislav Thon and Jakub Cechacek

     

    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

     

    Tasks

     

    General Tasks

     

    - Provide a security policy model, storage and API

    - Provide the integration of the security policy model with (external) user registries

    - Enable configuration of the security policy model and mapping to users

    - Provide operations to retrieve security meta data and/or todo pre-flight authorisation checks

     

    - Enforce permissions in core management compoments (mapping of policies against resources)

     

    - Respect permissions in web console (GUI should be aware and respect the policies: i.e. suppression of interaction units)

    - Respect permissions in CLI (CLI should be aware and respect the policies: i.e: restriction of command line syntax)

     

    - Provide methodologies and strategies to assure completeness of security policies and their enforcement

     

    Component Breakdown

     

    Core Management Components


    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?

     

    Notifications

    + WildFly 8 is adding management API notification capabilities; need to ensure that protected data is not allowed to leak out via notification listeners

    Admin 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".

     

    + some of the "configuration" sections contain "runtime" operations

    ++ i.e. subsytem=datasources/datasource-fooBar:enable

    ++ needs to be moved to runtime/status/subsystems to allow clean separation of duties

    CLI

    + basic handling of low-level (should be ok)

    + disable high-level commands in advance?

    + ls -- high-level equivalent to read-resource

     

     

    Misc:

    + sniffing for resources -- request a resource to learn it exists from the failure response

     

    + application security versus adminstrative security

    ++ IMO these are currently mixed (see security subsystem) and should be spearated

     

    + Notion of "start/stop service"

    ++ What's included, in our terms?

    ++ i.e. creation of a datasource with "enabled=true" attribute, will start the service

    ++ Does this mean the "add" operation will be restricted to users with operator permissions?

     

    Separation of Duty

    Commonly used speartion of duty for the simple version.

     

    RoleDescription
    Monitor

    The monitor role has the fewest permissions and restricts the user to viewing the

    configuration and current state.

    ConfiguratorThe configurator role has the same permissions as the monitor role, and can change the configuration. For example, the configurator can deploy an application. A configurator can change the application level security settings.
    OperatorThe operator role has monitor permissions and can change the runtime state. For example, the operator can start or stop services and servers
    AdministratorThe administrator role has the combined permissions of the operator and the configurator. This role has permission to access sensitive data, including passwords. The administrator role is the superuser of the Application Server and can modify adminstrative users and roles.
    Deployer

    The deployer role can perform both configuration and runtime operations on Applications.

    AuditorThe auditor role can view and modify the configuration settings for the security auditing system. The auditor role includes the monitor role, allowing the auditor to view but not change the rest of the security configuration.

     

     

     

     

    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)

     

    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

     

    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?

     

    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".

     

    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

     

     

    Glossary of terms

     

    TermDescription
    Security Policy
    A security policy is an association between a resource and one or more users, groups, or security roles.