What do you need to understand this book

This book assumes a basic knowledge of security-related concepts and terms, including identity, authentication, and authorization. It is also helpful if you are familiar with openCRX accounts and user homepages (UserHomes).

Ownership Permissions

Ownership permissions are used to control browse/delete/update access to openCRX objects by Users and UserGroups. Ownership access control has been implemented since openCRX v1.4.0. Every openCRX object is a SecureObject. The following figure shows an extract from the UML model (if you are interested in all the details and the formally correct and complete specifications you should refer to the openCRX UML models):

The most important security attributes of an object X are discussed below (and an example is shown in Figure 4-2):

• Owning User: this user "owns" object X; the Owning User can always browse/delete/update object X (unless the access level is set to 0 [no access]).

• Owning Groups: these groups might enjoy privileged treatment for browsing/deleting/updating object X depending on the relevant access level settings.

• Browse Access Level: this setting determines which users / user groups are granted browse access to direct composite objects of object X [i.e. can view/inspect direct composite objects (including all their attributes) of object X].

• Delete Access Level: this setting determines which users / user groups are granted delete access to object X and all its composite objects (recursively!) [i.e. can delete object X and all its composite objects (recursively!)].

• Update Access Level: this setting determines which users / user groups are granted update access to object X [i.e. can change object X; this includes adding composite objects to object X].

The following access levels are available to control which users / user groups are granted permission to browse/delete/update a particular object X:

• 0 - N/A: no access.

• 1 - private: access is granted if the user is owning user of object X.

• 2 - basic: access is granted if (a) the user is owning user of object X, or if (b) the user is member of any of the owning groups of object X, or if (c) any of the owning groups of object X is a subgroup** of any group the user is member of.

• 3 - deep: access is granted if (a) the user is owning user of object X, or if (b) the user is member of any of the owning groups of object X, or if (c) any of the owning groups of object X is a subgroup** of any group the user is member of, or if (d) any of the owning groups of object X is a subgroup** of any supergroup* of any group the user is member of.

• 4 - global: all users are granted access.

* a supergroup of an owning group G is a group of which G is a member of (recursively)

** a subgroup of an owning group G is a group which is member of G (recursively)

Security Setting of New Objects

New objects are by default created with the following security settings:

• Owning User: User who is creating the object

• Browse Access Level: 3 - deep

• Delete Level: 2 - basic

• Update Access Level: 2 - basic

• Owning Groups: Primary User Group of the user who is creating the object and (meaning as well as) Owning Group(s) of the parent object of the new object

Please note that the User Group Users (e.g. Standard\\Users) is not added to the list of Owning Groups of newly created top-level objects (i.e. objects attached to a segment, even if Users is an Owning Group of the segment)

Please note that a users's Primary user group is set by the segment administrator with the operation Create User. To change an existing user's primary group, the segment administrator simply executes the operation Create User again with a new parameter for primary user group.

In the context of activity management there are various operations that set/change the Owning Groups of objects based on the settings of an assigned Activity Tracker and not based on the settings of the user who executes the operation.

If you see N/P in a field instead of a more meaningful value you probably do not have browse access to the respective object (N/P stands for No Permission).

Model Permissions

Model permissions are not implemented yet.

Sample Organization

This example is built around a small company structured as shown in the following organizational chart:

The sales department (Sales) features a head of sales (head-sales) and 2 sales teams (SalesTeamA and SalesTeamB). Each sales team consists of 2 sales reps (e.g. SalesTeamA consists of sales-repA1 and sales-repA2). Similarly, there is an accounting department (Accounting) with a head of accounting (head-accounting) and an accountant who is the only member of the team AccountingTeam.The structure of the production department is identical to the structure of the accounting department. The company has a board (Board) with three members: ceo, cfo, and coo.

Please note that the above organizational chart does not contain any security-related information, i.e. it does not tell us anything about permissions and such - an org chart is an org chart and nothing more when it comes to security (even though it is probably not wrong to assume that sales-repA1 should not be allowed to see any objects owned by the ceo unless the ceo has granted such permission explicitly). Before we get started with setting up security let us make a few assumptions about the desired "default security settings" of this organization (please note that the following "rules" really are assumptions, i.e. there is nothing in openCRX that would force you to adopt such rules; we just need a set of rules for the sake of this example enabling us to show how security-related rules can be implemented.):

• every board member should be granted permission to access any object (browse/delete/update), including those created by any other board member, i.e. ceo, cfo, and coo have full access (browse/delete/update) to all objects

• SalesTeamA and SalesTeamB do not co-operate (i.e. objects created by a member of SalesTeamA cannot be accessed by members of SalesTeamB and objects created by a member of SalesTeamB cannot be accessed by members of SalesTeamA)

• department heads have full access (browse/delete/update) to any object created by a member of their department (e.g. head-sales has browse/delete/update access to all objects created by sales-repA1)

• there are "Chinese walls" between departments, i.e. objects created by a particular department are not accessible (browse/delete/update) by any other department (e.g. objects created by the sales department cannot be accessed by neither the accounting department nor the production department

• users are never automatically granted access (browse/delete/update) to objects created by users on a higher organizational hierarchy (e.g. sales-repB2 is not granted access (browse/delete/udpate) to objects created by head-sales or board members like the cfo)

• all members of a particular organizational unit should have the same permissions (e.g. sales-repA1 should have the same permissions as sales-repA2, but permission of sales-repB1 may very well differ from those of sales-repA1)

Users and User Groups

Let us now move on to setting up a flexible security organization that allows us to handle/implement all of the above-mentioned rules. The following figure shows the 12 User Groups (blue box white font, e.g. Company, Board, Sales, SalesManagers, etc.) we are going to create. It also shows how we are going to assign Primary user groups to the 12 Users (blue font, e.g. ceo, cfo, coo, head-sales, etc.) we are going to create:

• User ceo has User Group Board as Primary user group

• User cfo has User Group Board as Primary user group

• User coo has User Group Board as Primary user group

• User head-sales has User Group SalesManagers as Primary user group

• User sales-repA1 has User Group SalesTeamA as Primary user group

• and so on

Please note that the approach demonstrated in this example is not the only one possible. This security organization is not optimized in any way as we want the reader to follow our line of thought. Furthermore, it is advisable to get security issues right before you start thinking about optimizations.

The proposed security organization does not cover/include the User admin-Standard, i.e. this User will not have any access to objects created by any of the 12 Users on the above security organization.

Creating Principals

Connect to the root provider and login as admin-Root. Create the Principal ceo with the following steps:

• navigate to the Security Realm Default

• use the creator menu to create a new Principal

• enter ceo into the field Qualifier (leave the other attributes unchanged) and then click the button [Save] to create this new Principal

• navigate to the Principal ceo (for example by clicking on the operation result)

• in the grid Member of Principal Groups click on the lookup icon to start the lookup inspector and then locate the Principal Group Users (click the appropriate check box to select Users and return to the grid)

• click on the button [+] to add the Principal Group Users (this makes the Principal ceo a member of the Principal Group Users)

If you inspect your newly created Principal ceo you should now see the following:

Two important issues to verify are:

• the identity of the Principal ceo is xri:@openmdx:org.openmdx.security.realm1/provider/CRX/segment/Root/realm/Default/principal/ceo

• Principal ceo is member of the Principal Group Users

Please note that the values of the attributes User and Primary User Group will be assigned later (by executing the operation Create User).

Now you can create the following Principals with the same steps (i.e. do not forget to make every Principal member of the Principal Group Users:

• cfo

• coo

• head-sales

• head-accounting

• head-production

• sales-repA1

• sales-repA2

• sales-repB1

• sales-repB2

• accountant

• worker

You have successfully created all the principals shown in Figure 5-2.

Creating Contacts

Connect to the standard provider and login as admin-Standard. Use the provider Accounts to create the following 12 Contacts, i.e. one Contact for each User:

• ceo

• cfo

• coo

• head-sales

• head-accounting

• head-production

• sales-repA1

• sales-repA2

• sales-repB1

• sales-repB2

• accountant

• worker

To keep it simple, we only entered values into the field Last Name (e.g. the Contact ceo has the last name ceo) as shown in the following figure:

Creating Local User Groups

Next we use the provider Security Users / Groups to create several Local User Groups (see also Figure 5-2 for an overview of the User Groups). It is sufficient to enter a reasonable value into the field Description; we typically enter the provider followed by the name, e.g. Standard\\Board or Standard\\Company, but feel free to develop/follow your own pattern. Create the following Local User Groups:

• Standard\\Board

• Standard\\Company

• Standard\\Accounting

• Standard\\AccountingManagers

• Standard\\AccountingTeam

• Standard\\Production

• Standard\\ProductionManagers

• Standard\\ProductionTeam

• Standard\\Sales

• Standard\\SalesManagers

• Standard\\SalesTeamA

• Standard\\SalesTeamB

The following figure shows the grid Users / User Groups containing the newly created Local User Groups corresponding to Figure 5-2:

Creating Users

Next we navigate to the provider User Homepages and use the Operation Actions | Create User. to create Users. The operation Create User allows us to set the following attributes:

• User id

• Realm name (use Default for our example)

• Principal name (in our example the Principal name always matches the User id)

• Contact (use the lookup inspector to point to the matching Contact)

• Primary user group (use the lookup inspector to point to the desired User Group)

• Initial password (in our example we use "*" (without the quotes) as our password)

• Password again (repeat the password)

The steps to create the User ceo are as follows:

• execute the operation Actions | Create User. and enter the following parameter values

• User id: ceo

• Realm name: Default

• Principal name: ceo

• Contact: use the lookup inspector to select the Contact ceo

• Primary user group: use the lookup inspector to locate the User Group Standard\\Board

• Initial password: *

• Password again: *

• click on the button [OK] to create the User

The figure below shows the operation parameter panel just before clicking the button [OK]:

In addition to the User ceo you also need to create 12 Users (in parenthesis you will find the Primary Owning Group you need to assign to the respective User); the Realm name is Default for all Users. You also need to use the lookup inspector to select the matching Contact):

• cfo (Standard\\Board)

• coo (Standard\\Board)

• head-sales (Standard\\SalesManagers)

• head-accounting (Standard\\AccountingManagers)

• head-production (Standard\\ProductionManagers)

• sales-repA1 (Standard\\SalesTeamA)

• sales-repA2 (Standard\\SalesTeamA)

• sales-repB1 (Standard\\SalesTeamB)

• sales-repB2 (Standard\\SalesTeamB)

• accountant (Standard\\AccountingTeam)

• worker (Standard\\ProductionTeam)

The following figure shows the grid Users / User Groups containing the newly created Users:

Back in the root provider (login as admin-Root) you can now inspect the previously created Principals and verify that the operation Create User indeed properly updated the fields User and Primary User Group. For example, if you inspect the Principal ceo you should now see the following:

Two important issues to verify are:

• the User of the Principal ceo is equal to Standard\\ceo,

• the Primary User Group of the Principal ceo is equal to Standard\\Board

Assigning Group Memberships

Finally, we need to assign Users to the appropriate User Groups. The following table shows for each User (left-most column) which User Group (top column) she/he is member of (the acronym PUG stands for Primary User Group; the "PUG membership" is defined at the time the User is created with the operation Create User - the same operation can be used to change the Primary User Group of a User):

To add a particular User to a User Group, navigate to the provider Security Users / Groups, locate the respective User in the grid (e.g. Standard\\ceo) and load it into the inspector. Now you can use the lookup inspector of the grid Member of User Groups to locate the desired User Group and click on the respective checkbox. Back in the grid you can use the [+] button to add the User Group to the grid.

You can add User Groups very efficiently if you keep one browser window open showing the list of User Groups and another browser window to inspect the User (also showing the grid Member of Users Groups). To add a User Group to the grid Member of User Groups copy the URL of the icon of the User Group to be added to the input field of the grid Member of User Groups (you can copy the URL of an icon as follows: right-click on the icon and then select "Copy Shortcut" (IE) or "Copy Link Location" (Firefox) from the context menu to copy the URL into the clipboard; next you paste the URL into the input field). Finally, you click the [+] button.

The following figure shows the User ceo with all the User Groups she/he is member of (the list must correspond to the row ceo of the matrix in Figure 5-9):

Work yourself through the matrix Figure 5-9, i.e. for each User add the checked User Groups to the User's grid Member of User Groups.This completes the setup of the security structure as outline in Figure 5-2 and defined by the rules we assumed at the beginning of this example.

Objects created by ceo

Login as User ceo and create a Contact. Navigate to the newly created contact and have a look at the security settings as shown in the figure below:

The security settings of the newly created Contact are in line with the rules given in Security Setting of New Objects:

• Owning User: Standard\\ceo (because the Contact was created by the User ceo)

• Browse access level: [3] deep (default browse access level)

• Delete access level: [2] basic (default delete access level)

• Update access level: [2] basic (default update access level)

• Owning Groups: Standard\\Board (because Standard\\Board is the Primary User Group of the User ceo who created this Contact)

You can easily verify that the User ceo has full access (browse/delete/update) to this object.

Let us now verify what the situation is like for other Users. To do so, you need to start a new browser and login - for example - as User cfo. As you will find out, the User cfo also has full access (browse/delete/update) to this Contact. We would not expect it to be any different because that is how we configured our security setup. The following table shows the permissions granted to each User:

This corresponds exactly with our intentions as formulated in the section Sample Organization

Objects created by sales-repA1

Login as User sales-repA1 and create a Contact. Navigate to the newly created contact and have a look at the security settings as shown in the figure below:

The security settings of the newly created Contact are in line with the rules given in Security Setting of New Objects:

• Owning User: Standard\\sales-repA1 (because the Contact was created by the User sales-repA1)

• Browse access level: [3] deep (default browse access level)

• Delete access level: [2] basic (default delete access level)

• Update access level: [2] basic (default update access level)

• Owning Groups: Standard\\SalesTeamA (because Standard\\SalesTeamA is the Primary User Group of the User sales-repA1 who created this Contact)

You can easily verify that the User sales-repA1 has full access (browse/delete/update) to this object.

Let us now verify what the situation is like for other Users. To do so, you need to start a new browser and login - for example - as User ceo. As you will find out, the User ceo also has full access (browse/delete/update) to this Contact. Similarly, full access (browse/delete/update) is granted to the other board members and the 2 Users head-sales and sales-repA2. Members of the User Group SalesTeamB are not granted access. Furthermore, our "Chinese walls" are firmly in place: User of the departments production and accounting are not granted access either. We would not expect it to be any different because that is how we configured our security setup. The following table shows the permissions granted for each User:

This corresponds exactly with our intentions as formulated in the section Sample Organization

Selective Readonly Sharing

Instead of granting mutual full access, one could also imagine a regime where sales teams co-operate on a more selective basis by making some information available to the other sales team on a readonly basis. Hence, let us now assume that in addition to our original assumptions (see Sample Organization) the two sales teams SalesTeamA and SalesTeamB should have the possibility of easily sharing information on a readonly basis, i.e.

• members of SalesTeamB have no permission to access (browse/delete/update) any object created by a member of SalesTeamA (existing rule)

• members of SalesTeamA have no permission to access (browse/delete/update) any object created by a member of SalesTeamB (existing rule)

• new rule: but there should be a (simple) way of making objects created by a member of particular sales team available to the other sales team on a readonly basis (i.e. browse access only)

This feature request can easily be implemented with openCRX by adding two new User Groups Sales-super and Sales-readonly and then making the two User Groups Sales and Sales-readonly members of the new User Group Sales-super. The following figure shows the new security organization:

To implement this change, login as admin-Standard and navigate to the provider Security Users / Groups. Create a new Local User Group Sales-super (enter Standard\\Sales-super into the field Description). Next you create a new Local User Group Sales-readonly (enter Standard\\Sales-readonly into the field Description) and load it into the inspector. In the grid Member of User Groups you can use the lookup inspector (click on the looking glass) to locate the Local User Group Sales-super. Click the checkbox to return to the grid and then click the [+] button to add Standard\\Sales. You should now see the following:

Similarly, you also need to make the User Group Sales a member of the User Group Sales-super.

To verify the new security configuration, logout and login as sales-repA1 to create a new Contact. The default security settings of this new Contact should correspond to the ones in the following figure:

Neither sales-repB1 nor sales-repB2 have access to this Contact, while sales-repA2 has full access (browse/delete/update).

Let us now try to share this contact with the SalesTeamB. Logout and login as sales-repA1 and navigate to the Contact you want to share. Click on the Tab [^] to see the Owning Groups. Use the lookup inspector to navigate to the User Group Standard\\Sales-readonly. Click on the checkbox to return to the grid and then click the button [+] to add the User Group to the list of Owning Groups. The security settings should correspond to the ones in the following figure:

You can easily verify that in addition to the Users ceo, cfo, coo, head-sales, sales-repA1, and sales-repA2 being granted full access (browse/delete/update), the two Users sales-repB1 and sales-repB2 are now granted browse access (but delete/update access is not granted). This is exactly what we wanted to achieve.

The following matrix summarizes permissions on the Contact created by sales-repA1 if the User Group Standard\\Sales-readonly is added to the list of Owning Groups:

To revoke browse access for SalesTeamB you simply remove Standard\\Sales-readonly from the Contact's list of Owning Groups.

One last twist: to remove delete/update access for sales-repA2 you could remove Standard\\SalesTeamA from the Contact's list of Owning Groups. This reduces permissions of the User sales-repA2 to browse access only; sales-repA1 is now the only sales rep which delete/update access.

Co-operating Sales Teams

Let us now assume that at some point in time it is decided that in contrast to our original assumptions (see Sample Organization) the two sales teams SalesTeamA and SalesTeamB should be fully co-operating, i.e.

• members of SalesTeamB are automatically granted full access (browse/delete/update) to any object created by a member of SalesTeamA, and

• members of SalesTeamA are automatically granted full access (browse/delete/update) to any object created by a member of SalesTeamB

This change is easily accommodated with openCRX by making both User Groups SalesTeamA and SalesTeamB members of the User Group Sales. The following figure shows the new security organization:

To implement this change, login as admin-Standard and navigate to the provider Security Users / Groups. Locate the Local User Group SalesTeamA and load it into the inspector. In the grid Member of User Groups you can use the lookup inspector (click on the looking glass) to locate the Local User Group Sales. Click the checkbox to return to the grid and then click the [+] button to add Standard\\Sales. You should now see the following:

Similarly, make the User Group SalesTeamB a member of the User Group Sales.

To verify the new security configuration, logout and login as sales-repA1 to create a new Contact. The default security settings should correspond to the ones in the following figure:

You can easily verify that not only the Users ceo, cfo, coo, head-sales, sales-repA1, and sales-repA2 are granted full access (browse/delete/update), but the two Users sales-repB1 and sales-repB2 are also granted full access (browse/delete/update) to this Contact even though the User Group Standard\\Sales (or Standard\\SalesTeamB) was not explicitly added to the list of Owning Groups of the Contact (this is what we did in section Grant full access to Sales to grant access to the other sales team).

The following matrix summarizes permissions on the Contact created by sales-repA1: