Access Model
User Management
Collection Profile
All users in ShareAspace will have a footprint on the collection level.
It is within the collection that the global user information (such as display
name, avatar image, etc.) is stored. This user information is called a
Collection Profile. The key for the Collection Profile is the user's email
address. After a successful identification at an Identity Provider the email
address of the user will be passed on as a claim through the authorization.
Space Profile
A user will have one space specific user profile, Space Profile, for
each space that the user is part of. The Space Profile is stored within
the space and is responsible for saving the user's:
- Space specific information filter settings
- Modules to be active on the user's space home screen (only modules available for that specific space can be configured)
The space itself is responsible for the user access within the space.
Access Model
This section will describe the conceptual Access Model constructs of ShareAspace. Refer to the picture below when reading the documentation.
Participant
All data within a ShareAspace space is owned by a Participant or by the Space itself. A
Participant is a system specific object used to track ownership of data as well
as being part of the mechanisms controlling access to the data. The Participant is stored
within a space and is owned by itself. The Participant is created during Bootstrap of the Space or at run time.
Role
A Role is a system specific object used to define access. A Role has a name
and a value for the specified access. A Role can be defined by combining the
following access attributes.
| Attribute | Description |
|---|---|
| Create (C) | Instantiate a new Unit of Information (UoI). The created UoI shall have the owner set to the Participant that the claim concerns. Note that create is not required to instantiate entries inside a UoI. |
| Read (R) | Retrieve/read UoI/Entries that are owned by the Participant the claim concerns. |
| Update (U) | Create new entries, delete existing entries or alter values of existing attributes inside a UoI owned by the Participant that the claim concerns. |
| Delete (D) | Delete a UoI owned by the participant that the claim concerns. Note that delete is not required to delete entries inside a UoI. |
| FileVault Access (FVA) | Retrieve PLM-vaulted files from a UoI owned by the Participant that the claim concerns. |
| Execute Operation (EXE) | Execute operations held by a UoI owned by the Participant that the claim concerns. |
| Awareness (AWA) | Grant another Participant awareness of the existence of the Participant granting this access. Note that AWA is still required even if other Access Rights are added to the External Access. |
| Grant Detailed Access (GDA) | Grant another Participant ReadShare/FullShare to UoI/VersionEntry/DefinitionEntry owned by the Participant that the claim concerns. |
| Grant User Access (GUA) | Issue/revoke claims to other users (existing on collection level or not) based on the applied role references available for the Participant that the claim concerns. |
| Grant Participant Access (GPA) | Create a new Participant at runtime in the space. |
| Grant External Access (GEA) | Establish an External Access Rights (EAR) between an unrelated Participant and the Participant that the claim concerns. |
| Manage Space Definitions (MSD) | To manage the definitions of the space. |
| Lock (L) | Allows for "checkout" of objects. |
| DelegateLock (DL) | Allows for handing over a "checkout" of an object to another user. |
The defined roles are stored on space level, thus allowing for different roles in different spaces as well as roles with the same name but with different access to be setup across the spaces.
Applied Role Reference and Role Assignment
An Applied Role Reference is used to define which roles are applicable for a Participant.
A Project Profile (User) can be given access to a Participant by using one of the applicable roles. This is
achieved by creating a Role Assignment for the user. The Role Assignment is stored on
Space level. A user's access within a space is controlled via Claims. These claims,
called Role Claim, are calculated from the user's Role Assignments.
A Role Claim is identified as http://ShareAspace.com/identity/claims/role with the value
Role@Participant@Space. Read more about the authentication and authorization process
here.
Sub Participant
A Sub Participant is a Participant that is owned by another Participant. The Sub Participant grants full external access to the owning Participant (AWA, R, U, D, FVA, EXE).
To be able to create a Sub Participant the user need to have Grant Participant Access.
All the Applied Role References from the owning Participant will be copied to the Sub Participant.
All the Space Profile References for the creating user in the owning Participant will be copied to the Sub Participant.
The user that creates the Sub Participant will have the same access rights in the new Sub Participant as the user has in the owning Participant since the roles are copied from the Participant to the Sub Participant.
The other users in the owning Participant will have the same access in the Sub Participant as they have in the owning Participant except for C, GDA, GUA, GPA, GEA, and MPD. To gain C, GDA, GUA, GPA, GEA, and MPD in the Sup Participant the user needs to have a Role in the Sub Participant with that Access Right.
Internal Access
Internal Access of a Participant is setup during the creation of the Participant and cannot be changed at runtime. By default the Internal Access of a Participant is full access. The Internal Access of a Participant is AND-operated with any Role Claims given to a User for that Participant; thus the Internal Access will be restricting any Role Claims given to Users for the Participant.
Example
Document 1 is owned by Participant 1. Participant 1 has read (R) as Internal Access. User 1 has been given a Role Claim with "edit" access (C, R, U, D) in Participant 1. Because of the Internal Access User 1 will only get read (R) access to data owned by Participant 1.
User 1 access to Document 1
| C | R | U | D | |
|---|---|---|---|---|
| U1 Role Claim in P1 | 1 | 1 | 1 | 1 |
| Internal AR P1 | 0 | 1 | 0 | 0 |
| Result | 0 | 1 | 0 | 0 |
External Access
Access can also be setup between participants. For example a Participant can give
any combination of R, U, D, FVA, EXE, and GUA access to another Participant. The access
between two participants is called External Access.
Note
C, GDA, GPA, GEA, and MPD access can only be applied on Roles.
When a Participant is given External Access to another Participant, users with a
Role Claim in the first Participant will be given the intersection of access of
their Role Claim access in the first Participant and the External Access between
the first and the second Participant.
The Internal Access of a Participant will also be AND-operated with any External Access
given to other participants; thus the Internal Access will be restricting any
External Access given to other participants.
Example
Document 1 is owned by Participant 2. User 1 is given a Role Claim with "edit" access (R, U, D) in Participant 1. Participant 1 is then given Read access (R) to Participant 2. User 1 will then have C, R, U, D access to Participant 1 because of the Role Claim. User 1 will also have Read (R) access to Participant 2 because of the intersection of (R, U, D) and (R) being (R).
User 1 access to Document 1
| C | R | U | D | |
|---|---|---|---|---|
| U1 Role Claim in P1 | 1 | 1 | 1 | 1 |
| Internal AR P1 | 1 | 1 | 1 | 1 |
| External AR P1 in P2 | 0 | 1 | 0 | 0 |
| Internal AR P2 | 1 | 1 | 1 | 1 |
| Result | 0 | 1 | 0 | 0 |
Note
External Access will not propagate between Participants, i.e. External Access given to one Participant will only apply to users with an applied role to the Participant given the External Access.
User 1 access to Document 1
| C | R | U | D | |
|---|---|---|---|---|
| U1 Role Claim in P1 | 1 | 1 | 1 | 1 |
| Internal AR P1 | 1 | 1 | 1 | 1 |
| External AR P1 in P2 | 0 | 1 | 0 | 0 |
| Internal AR P2 | 1 | 1 | 1 | 1 |
| External AR P1 in P3 | 0 | 0 | 0 | 0 |
| Result | 0 | 0 | 0 | 0 |
If User 1 would have also had a claim for an Applied Role "Creator" in Participant 3 the result of that access would have been OR-operated with the above access. See example below.
| C | R | U | D | |
|---|---|---|---|---|
| U1 Role Claim in P1 | 1 | 1 | 1 | 1 |
| Internal AR P1 | 1 | 1 | 1 | 1 |
| External AR P1 in P2 | 0 | 1 | 0 | 0 |
| Internal AR P2 | 1 | 1 | 1 | 1 |
| External AR P1 in P3 | 0 | 0 | 0 | 0 |
| --- OR --- | ||||
| U1 Role Claim in P3 | 1 | 1 | 1 | 1 |
| Internal AR P3 | 1 | 1 | 1 | 1 |
| Result | 1 | 1 | 1 | 1 |
Special case Participant
There is one special type of Participant that has additional business logic compared to other participants.
The special participant is called the "Space participant". The intended use of the Space participant is for it to be the owner of reference data like units, properties etc. that should be accessible by everyone within the Space. Because of this participant being the default owner of shared information, any participant created at runtime will automatically be granted access to the Space participant. The granted external access is: (R) Read, (FVA) File vault access, and (AWA) Awareness.
Role based SoftType operations
The ShareAspace access engine is also supporting additional access control for SoftType operations, like creating/updating/reading instances of SoftTypes.
Basics
- AllowedRoles restrictions on
anySoftType - Filter API routes for update/delete on SoftType definition level.
- Possible to set AllowedRoles on a specific DataExchange job, define which role@particpant should be able to schedule it.
AccessRights calculation for links in API
- No AllowedRoles section in SoftTypeDefinition, return current role@participant rights
- Match the whole role@participant, return allowed rights
- Match combination of role and participant, return intersection (bitwise and) of allowed rights
- Match only role, return role allowed rights
- Match only participant, return participant allowed rights
- No match, return current role@participant rights
AccessRights check for commit validation
- Retrieve current user access for specific UoI
- If no allowed roles section, return user access
- Check AllowedRoles for
alluser roles and combine them. - If no restriction found, return user access
- If restriction found, return the intersection of user access and allowed roles.