Licenses are the foundation of the security model. There are two types of licenses: a base license that provides access to a limited set of functionality and a full license that provides access to the full application. A license is assigned individually to each user, providing the ability to log on and defining user access to modules and views. Essentially, a license defines the maximum possible access a user can be given to modules and views. Think of the license as a large container; it holds a user's greatest potential access to the application.
Security roles are basically a collection of individual permissions and define the level of access for users and groups and functions they can perform. The permissions structure enables you to specify the precise level of access for the security role, and to the individual views, dimensions, and user actions. Licensed users are put in groups, which are then assigned to a security role. When user access provided by a security role is combined with the potential access granted by the license, the net result is the most restrictive level of access.
When security roles and licenses are combined, the result is restrictive. However, users and groups can belong to more than one security role. In this case, the user access from each security role is cumulative, but only to the extent provided by the license.
A role assignment is the last layer in the security framework. Role assignments define user and group access to a specific work item or work item portfolios. The security role assignment is actually part of the work item's properties. This is the final step in determining a the level of access for a user or group. A user can have a full license and have unrestricted access via their security role, and will not have access to a work item or portfolio without a appropriate role assignment.
Combining licenses, security roles, and role assignments effectively can provide the appropriate level of access and visibility into portfolio data. In fact, when combined with a well-designed portfolio structure, you can virtually isolate a work item and entire portfolios from unauthorized access.
The following visual provides an example of this security-based portfolio isolation. Users with role assignments on the IT Portfolio, for instance, see only those items highlighted in green. When those users log on, the other items and portfolios will not even appear in the hierarchy. In the same way, users assigned to the Executive Portfolio will only see and have access to items in that specific portfolio.
- Document your requirements for user access and application security. Determine the level of granularity needed by your organization.
- Outline the security roles.
- Devise the licensing scheme that will match this setup.
- Define and create each security role and assign corresponding permissions.
- Ensure each security role has access to the appropriate dimensions.
- Create groups, and assign groups to security roles.
- Create users and then add them to appropriate groups.
- Assign users the appropriate licenses that match their security roles.
If you assign a security role permission to edit the properties of a work item in the work item hierarchy, that permission will be inherited by all of that work item's children. It is possible to restrict permission to edit an work item's children, but it is not possible to restrict permission to view an work item's children.