This article is deprecated:

Please refer to https://community.jboss.org/wiki/AccessControlNotes until we publish the final access control documentation

Role based access control to the AS7 management layer.

Core Concepts

When defining an RBAC model, the following conventions are useful:

• Subject = A person or automated agent
• Role = Job function or title which defines an authority level
• Permissions = An approval of a mode of access to a resource
• Action = An operation to execute on a resource
• Constraint: Predicate that makes the permission valid in the context of the system state
• Session = A mapping involving Subject, Role and/or Permissions

https://community.jboss.org/servlet/JiveServlet/downloadImage/102-47854-32-19855/450-235/PermissonModel2.png

Generic Requirements

• Provide a usable (in terms of complexity), yet comprehensive base model
• Provide a set of out-of-the-box roles & permissons that reflect common authorization requirements
• Enable customizations/extension of the default scheme (i.e custom permissions, permission granularity)
• Provide management operations to retrieve session information (i.e. roles assigned, permissions granted, etc)
• Clearly distinguish security exceptions from other operation errors (i.e. custom response headers)
• Mappability with existing authorisation schemes (i.e. JON)

Specific Requirements

• Support permission enforcement that restricts visibility of model elements:
  Control visibility of resources (i.e. restrict visibility of server groups)
• Support permission enforcement that restricts execution on model elements:
  Control execution on resources (i.e. lock down certain operations, distinguish read & read/write access)
• The management layer needs to enforce permission regardless of the client type and availability:
  I.e. enformenent can not be delegated to the client only
  
• Clients (CLI, Web) should indicate permissions prior to execution of management operations:
  I.e. grey out interface elements to emphasis lack of permissions
• JMX access that isn't delegated to the ModelController needs to be covered by the permission scheme as well

Use cases

See RBACUsecases

Advanced Topics

- Context based access control: i.e. Taking the connection into consideration

- Support for role hierarchies: i.e. structuring roles to reflect an organizations lines of authority and responsibility

- Role constraints: i.e. mutual exclusive roles

- RBAC to manage RBAC itself

- Ability to hide the existence of a resource altogether, vs the ability to show its existence but hide its content.

   The issue here is in some cases the address of the resource itself may provide sensitive information,

   e.g. security-realm=ManagementRealm