Chapter 7. Security

Table of Contents
Security Setting of New Objects
Resetting Security

We do not recommend learning about security with mission critical data. Backup your data BEFORE you make changes if you are not certain what the consequences are! The default settings should work for virtually all users; the probability of getting yourself into trouble by changing default settings should not be underestimated. Read and understand the openCRX Security Guide BEFORE you make any changes.

Starting with openCRX v1.4.0 access control is activated. Please refer to the openCRX Security Guide for a detailed explanation of role-based security as it is implemented by openCRX. In this chapter we will present a high-level overview and we will discuss a few select issues only, including disaster recovery if you locked yourself out and/or screwed up the security settings in a major way.

Starting with openCRX v1.8.0 various security concept enhancements are activated. Some of the basic concepts are:

Each ‚real‘ user is represented by a subject, e.g. ‚Guest‘.
Each subject has a login id (application login principal), e.g. ‚guest‘. Each (application login) principal is assigned to a subject (e.g. the principal ‚guest‘ is assigned to subject ‚Guest‘) and allows a ‚real user‘ to login to openCRX. Subjects and application login principals are managed by the openCRX Root administrator (admin-Root).
A ‚real user‘ can have one or more additional segment login principals. A segment login principal has typically the same name as the application login principal (e.g. ‚guest‘) and grants a ‚real user‘ login access to a segment. Segment login principals are managed by the openCRX segment administrators (e.g. admin-Standard for the Segment Standard).
Each ‚real user‘ which has access to a segment (i.e. has a segment login principal) has (in addition to the segment login principal) a segment user principal, e.g. ‚guest.User‘. The segment user principal is required to assign objects to an owning user.
Principals are stored in realms. Each segment has a corresponding realm:
- The application login principals are stored in the realm ‚Default‘.
- The segment login principals for segment ‚<segment name>‘ are stored in the realm ‚<segment name>‘.
- Each segment has a segment administrator principal (admin-<segment name>).
Each segment login principal has a home page in the corresponding segment (qualifier of principal and home page must match!).
Each segment login principal is correlated with a contact. This correlation is e.g. required to find all activities and contracts assigned to the logged in principal.

All security data is managed by the openCRX security provider. The following figure should give you an idea of how it all fits together:

Figure 7-1. Subjects, Realms, and Principals

Hence, summarizing the above:

there is a Realm for each segment (e.g. if you followed this guide there is a Realm Standard because you created a segment Standard)
the Realm Default acts as login realm, i.e. it contains all principals who are allowed to login to the application server
there is a subject for each ‘real user’ and all principals of a user are assigned to the same subject; this allows openCRX to find all principals of a user (--> role selection drop down)

The segment administrator (e.g. admin-Standard) creates Principals and User Homepages with the operation createUser() :

Each segment login principal has a home page in the corresponding segment (qualifier of principal and home page must match!).
Each segment login principal is correlated with a contact. This correlation is e.g. required to find all activities and contracts assigned to the logged in principal.

Figure 7-2. Segment Administration

While each ‘real user’ (typically) has 1 application login principal only, ‘real users’ may have multiple segment login principals (e.g. because a ‘real user’ is allowed to access multiple segments or because a ‘real user’ is allowed to access a particular segment in different roles [e.g. Head of Sales and and CFO] – all available segment login principals are listed in the so-called Role Drop Down:

Figure 7-3. Role Drop Down with list of available Principals

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
Update Access Level: 2 – basic
Delete 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).