1. Proposal for RBAC Features for SDD James Falkner Sun Microsystems October 11, 2006

2. Related Use Cases - Install customized for different roles. administrator, end user, developer for example). So the user does not have to make complex decisions about what components to select for his needs. The custom options should aim at reducing complexity by providing exactly the set of features a particular role might need - (Non-Root Install) 1. User installs product (into a location into which they have "write access" 2. User configures and uses software. Software makes no use of (or disables certain features that require) administrator-only interfaces - Development needs to specify the privileges required to install a component. There are generally cases in which a “root” or other administrative level user id is required: For Windows, creations of product registry information, defining discretionary access control, or setup of services, drivers, etc. For UNIX/Linux, update of protected directories such as /etc

3. Related Requirements 2.2.1.4 The SDD specification MUST must support the ability for the author to define the information in order to specify, as requirements for deployment lifecycle operations, the need for administrative, user, and system privileges. SDD specification must must support the ability for the author to define the system privileges required for deployment lifecycle operations when necessary. However, it should be noted, as a best practice, system privileges SHOULD only be required when absolutely necessary. 2.1.1.5 The SDD specification must support the ability for the author to define information sufficient for a provisioning application or installation program to determine in advance that a deployment lifecycle operation is invalid ??? Ability to disable installation or configuration of components based on pre-defined roles or privileges

4. Potential Solutions Adopt two Roles: user, and administrator Satisfies only one use case, and does not permit future use cases or extensibility Define a generic, extensible “Role” entity Associated with installation groups or features, and constrained resource requirements Better, but does not address flexible policy declarations and leaves a lot up to implementations Adopt existing standard ANSI RBAC, XACML, WS-Security

5. Existing Standards ANSI RBAC Generic model, used as basis for XACML Not readily adoptable in XML Standards WS-Security Not role-based, mainly concentrates on message security, confidentiality, and integrity Others http://www.oasis-open.org/committees/xacml/faq.php

6. Proposal: XACML XACML is an OASIS standard that describes both a policy language and an access control decision request/response language (both encoded in XML).OASIS –OASIS Standard –Generic –Distributed –Needed subsets readily imported

7. XACML Concepts Policies define rules which are applied to individual entities or roles to allow or deny access to resources Can be very simple or complex Resources are any protected entity –Physical hardware –Directories (e.g. /usr) –Metadata (e.g. Features) –Application state (e.g. allowable configuration)

8. XACML Example Policy Identifies which resource is protected (the target) User ID Root (uid=0) Allow If.. For any action (install, configure, etc)

9. Application to SDD Becomes addressable resource within Policy via id Checks can define policy to constrain resource

10. Application to SDD Defines Roles in which feature should be selected or deselected (e.g. EnabledForRole)

11. Application to SDD SIU == “install” action SCU == “configure” action Specifies which role is required for this IU

12. Implementation Considerations Must map end users to Roles (out of scope for SDD) Must process XACML Policies according to specification Initially, all XACML entities (PEP, PDP, etc) can be local and private to implementation. Can optionally provide true XACML implementation (request/response protocol, context creation) for interoperability with true XACML systems