Administration
Administrators Guide
[ CSM: Administrators Guide | Developers Guide | Users Guide | caGrid: Documentation Guides ]
Overview of CSM Security Concepts
Successful usage and management of your CSM Service requires a good understanding of its underlying security concepts. The CSM Service provides access control for the data, methods and objects found in an application through the definition and configuration of users, roles, groups, privileges, protection elements, and protection groups as well as the linkages that associate these concepts to one another.
Consider the following table of security concept definitions found in the CSM Overview: Security Concepts section of the caCORE CSM v4.2 Programmer's Guide
. This provides a good overview of what the concepts are and how they are used. Refer to the Programmer's Guide for additional detail.
| Security Concept | Definition |
|---|---|
| Application | Any software or set of software intended to achieve business or technical goals. |
| User | A User is someone that requires access to an application. Users can become part of a Group, and can have an associated Protection Group and Roles. |
| Group | A Group is a collection of application users. By combining users into a Group, it becomes easier to manage their collective roles and access rights in your application. |
| Protection Element | A Protection Element is any entity (typically data) that has controlled access. Examples include Social Security Number, City, and Salary. Protection Elements can also include operations, buttons, links, etc. |
| Protection Group | A Protection Group is a collection of application Protection Elements. By combining Protection Elements into a Protection Group, it becomes easier to associate Users and Groups with rights to a particular data set. Examples include Address and Personal Information. |
| Privilege | A Privilege refers to any operation performed upon data. CSM makes use of a standard set of privileges. This will help standardize authorization to comply with JAAS and Authorization Policy and allow for adoption of technology such as SAML in the future. |
| Role | A Role is a collection of application Privileges. Examples include Record Admin and HR Manager |
One security concept described in this table is what is referred to later in the Programmer's Guide as a Final Association. This guide as well as the CSM Admin UI refer to Final Associations as Permissions. A Permission is the correlation between a User or Group, their assigned Role(s) and a Protection Group. Permissions are what tie the security concepts toegether.
The following diagram from the Programmer's Guide provides additional insight into how the security concepts are associated with one another.
Protection Elements are created to represent entities in the application that should be protected such as a database element. A privilege is an action or operation that can be performed on a piece of data. Examples of permissions are READ or WRITE access to the same types of entities that can be represented by protection elements.
Protection Elements can be grouped together into Protection Groups, making it easy to manage sets of similar elements. For example, an Address protection group could group together protection elements such as street address, city, state, etc. Similarly, Privileges can be grouped together into a Role. Example roles are Administrator, Read Only, etc.
Users are associated with protection groups and roles through Permission definitions. The protection groups a user is associated with defines the set of protection elements the user has access to. The set of actions the User can perform on these protection elements is defined by the Privileges specified by the User's Roles. A set of Users can be bundled together in a group, and a Permission can be associated with either a single User or Group.