Chapter 3. Introduction to role-based security

It is the main goal of the security concept of openCRX to control who is allowed to browse/delete/update which information. On the one hand this requires some infrastructure to manage identity data (e.g. principals, users), authentication data (e.g. passwords, certificates) and authorization data (e.g. permissions, roles), on the other hand the rules defined by the various permissions granted to principals must be enforced to ensure that no principal can take an action without being granted permission to do so. openCRX implements a state-of-the-art role-based security concept which utilizes the concepts of Principals and Roles, similar to the implementation of security in many current operating systems. While role-based security may be overkill in trivial settings (e.g. SOHO with two users who both are allowed to browse/delete/update all objects) it is an extremely powerful tool to get a handle on complex environments (e.g. ASP managing tens of thousands of customers/companies). Apart from these two extreme settings (SOHO, ASP), role-based security is also very useful in many typical company settings where various sales teams, customer service teams, and maybe accounting teams need to browse/delete/update customer-related data (e.g. sales orders, invoices, payments, support requests) while at the same time permissions on such data may vary depending on the function of the employee (imagine what would happen if accounting staff could enter/change sales orders or a customer service rep could alter customer payments).

The following explanations are hopefully helpful to understand the role-based security concept as it is implemented by openCRX. Please be aware that the goal of this documentation is to explain the concepts used in openCRX - if you are interested in details and the formally correct and complete specifications you should refer to the openCRX UML models.

The following figure shows the main ingredients of role-based security:

At the core of role-based security is the concept of collecting Permissions in Roles, which can be granted to Principals (a Principal corresponds to a Login). For example, imagine a Principal admin-Standard who is granted the Role OpenCrxAdministrator which comes with all the Permissions required for a segment administrator to do his work, or a Principal salesrep1 who is granted the Role SalesRep which comes with all the Permissions required for a sales representative to do his work. For better manageability several Principals can be collected in a PrincipalGroup and Roles can be directly attached to PrincipalGroups.

Users (e.g. human beings like Joe, Mary, Jeff) can be assigned multiple Principals to reflect the fact that some users connect to the system in different roles depending on the tasks at hand. For example, User joe might be assigned the Principal head-Sales (because Joe is head of sales) as well as the Principal admin-Standard (because Joe is also segment administrator). If Joe wants to work as segment administrator he logs in as Principal admin-Standard, if Joe wants to work as head of sales he logs in as Principal head-Sales. Credentials (like passwords, certificates, SecurIDs) are attached to Users. Like this it is possible to let Joe connect to the system with the same password, regardless of whether he acts as segment administrator or head of accounting. For better manageability several Users can be collected in a UserGroup. The term Subject is commonly used to refer to Users and UserGroups.

In addition to this standard setup of role-based security openCRX allows you to relate Users to Contacts. Furthermore, each Principal is related (automatically) to an openCRX UserHome (this is how openCRX can easily maintain two different histories for Principal admin-Standard and Principal head-Sales; one history keeps track of Joe's actions when he is logged in as segment administrator, the other history keeps track of his actions when he is logged in as head of sales). These openCRX extensions to role-based security are shown in the following figure:

Please note that the above figure represents a high-level view of the implemented security concept - refer to the openCRX UML models for detailed and formally correct and complete specifications.