Sentinet Users
Authenticated and authorized Sentinet Administrative Console Users can access Sentinet Administrative Console and the Sentinet Repository Management API. Sentinet Users are created in the Repository folders (including the root of the Repository). A User created in a particular folder will get access and visibility only to the folder he is created in including all its subfolders. Sentinet provides a multi-tenancy environment through user access isolation, where each user or a group of users may have access to the Repository only starting from a specific level of the Repository hierarchy. Sentinet Users, who are created in a particular Repository folder, do not have access nor visibility to a folder of the same or higher level. A Sentinet User may be authenticated using multiple authentication schemes described below.
User Roles
A Sentinet User must be assigned a specific User Role. Sentinet automatically provides three (with the upgrade from older Sentinet version - four) built-in User Roles, which cannot be removed from the system or modified. Custom User Roles can be added, removed or modified by the Sentinet Administrators. A User Role is defined as a set of different permissions to access different parts of the Sentinet Administrative Console and the Sentinet Repository Management API. To create a User Role, navigate to the CONFIGURATION tab of the Repository root folder, select USER ROLES subtab and click +Add button to add a new User Role (note that this action is available only to the root Sentinet Users, which also have permission to modify User Roles, see later in this chapter).
The Add User Role dialog assigns permissions (checkmarks), which will be given to a User Role.
Certain adjustments may be automatically executed to added or removed permissions once they are assigned. For example, Modify permission automatically includes View permission. Some permissions will actually be given only to Sentinet Users created in the root of the Repository even if their User Role is explicitly given such permissions. Those special permissions are marked with (1) reference in the dialog UI. For example, Repository Entities Import.
Custom User Roles can be modified and deleted. Built-in User Roles are always read-only.
All individual permissions are self-explanatory, except two particular permissions that require some explanation. Those are Modify and Manage for Developer Portal Content. These permissions map to built-in Umbraco Backoffice User Groups when Sentinet User Role is meant to be provided with permissions to administer Sentinet Developer Portal from within Umbraco Backoffice. Umbraco Backoffice has 5 built-in User Groups described here. Sentinet maps its own users to Umbraco User Groups according to the following rules:
Modify Developer Portal Content permission maps Sentinet User to Umbraco’s Editor, Writer and Translator User Groups.
Manage Developer Portal Content permission maps Sentinet User to Umbraco’s Administrator and Sensitive Data User Groups.
Built-in User Roles are listed below:
Administrator. Administrator users have full access to the Repository.
Read/Write. These users can use the Sentinet Administrative Console in read-write mode, and can add, delete or modify Repository entities and configurations. They cannot create or view other Sentinet user accounts (unlike Administrator users).
Read Only. These users can use the Sentinet Administrative Console in read-only mode, and cannot add, delete or modify anything in the Repository.
Consumer (Deprecated). This User Role has very limited access to the Sentinet Repository with Read Only permissions for Virtual Services. The User Group is available only when upgrading Sentinet from the versions older than Sentinet 6.2. New installations do not offer this built-in User Role.
Important
The concept of a Sentinet User with Consumer (Deprecated) User Role is considered obsolete since the Sentinet version 6.0, which introduced optional Sentinet component, Developer Portal.
Developer Portal provides much more capable and flexible handling of API Consumer accounts and their User Experience through a separate web application, Sentinet Developer Portal Web Application. Sentinet User with Consumer (Deprecated) User Role may still be used by Nevatech customers who do not wish or do not have requirements to use Sentinet Developer Portal components.
Sentinet Users in a specific User Role can be searched for using Repository Search function.
Managing Sentinet Users
When the Sentinet Repository Application is initially configured using the Repository Configuration Wizard (see Sentinet Installation Guide), the first, root-level user account is created, which is a member of the built-in Administrator User Role described above. That account can later be modified or even deleted using the Sentinet Administrative Console. The Configuration Wizard can also be used to create additional root-level accounts. Best practice is to leverage the Sentinet Administrative Console user interface to manage Sentinet users, starting from the moment the first user account is created in the Repository Configuration Wizard application.
To add a new Sentinet user account to a Repository folder, select that folder and select the Add->User menu option from the main toolbar, or right-click and select the Add->User pop-up menu option.
Provide the values for the following fields:
Full Name. An account's full name. For example, System Administrator, or John Smith.
Email. Enter a valid email address that may be used by Sentinet to send notifications and alerts (see the Alerts chapter in this guide for more details).
Enabled. If a user account is disabled, a user cannot sign in to the Sentinet Administrative Console.
User Role. Select the Administrator, Read/ Write, Read Only or one of your Custom User Roles from the drop-down list of available User Roles.
Click the +Add button to add one or more different identities for this user account. A Sentinet user may use different user identities and different user identity types. For example, a user may sign in using a username/password identity or his current Windows Identity - in any case he will be signed in with this Sentinet User account (see the Sentinet Installation Guide and its Appendixes on how to configure Sentinet to use different user identity types.).
Note
A Sentinet Repository Web Application may be configured to use a custom in-memory User Authentication cache to provide efficient Sentinet user authentication. If a user account is found in a User cache, then any changes to that user account may not take effect until after the user account cache entry expires. User Cache expiration is controlled by the expirationInterval attribute value measured in minutes and configured in the Sentinet Repository Application’s web.config file. Expiration values greater than zero improve responsiveness of the Sentinet Administrative Console by using in-memory cached user authentication tokens.
Sentinet also uses another in-memory cache that keeps resolved Windows Groups SIDs to groups’ names. The cache is used by the Windows Integrated Security with Administrative Console. It is automatically destroyed and recreated when Repository Web Application restarts. Both caches can be controlled in the web.config file:
<nevatech.vsb.repository>
…
<usersCache expirationInterval="0" … />
<windowsAuthentication disableSidTranslationCaching="false" />
…
A user account can be assigned any number of identities, where an identity can be of any of the following identity types:
Username/Password – default Sentinet user authentication scheme based on the Sentinet user accounts stored in the Sentinet Repository.
Windows User – Windows integrated authentication scheme based on a specific local machine or Active Directory domain account. Sentinet Application server machine must be a member of an Active Directory domain for Active Directory accounts to be used (see the Sentinet Installation Guide, Appendix B on how to configure Sentinet to use Windows Integrated Security).
Windows Group – Windows integrated authentication scheme based on a specific local machine or Active Directory domain group membership. Sentinet Application server machine must be member of an Active Directory domain for Active Directory accounts to be used (see the Sentinet Installation Guide, Appendix B on how to configure Sentinet to use Windows Integrated Security).
Federation Claim – Sentinet user authentication scheme based on the SAML tokens (claims) issued by external Security Token Service.
X.509 Certificate – Sentinet user authentication scheme based on a client X.509 certificate.
Note
Sentinet has some means to resolve identity assignment ambiguities for identities associated with Windows integrated security. For example, suppose that two Sentinet User accounts are assigned their own Windows Group identity. An Active Directory Windows User account can be a member of both Windows Groups. When that Windows User signs-in to the Sentinet Console using Windows integrated security, the Sentinet application cannot uniquely resolve which Sentinet account this user should be associated with because the user is the member of both Windows Groups. Nevertheless, the ambiguities are resolved according to the following simple priority rule: User Role with the lowest ID (in the SecurityRoles Repository database table) will take the precedence.
User Audit
Click AUDIT tab to review and search for all Repository changes done by the selected Sentinet user (see Repository Audit chapter of this guide for more details on the Sentinet Repository Audit).
User Session
Sentinet maintains audit records of the Sentinet user sessions. A user session is a time stamp and duration showing when a user signed-in and signed-out of the Sentinet Console. The length of each user session is calculated based on either explicit user logins and logouts, or his idle use of the Sentinet Console. User sessions can be filtered by date/time, specific user account Identity Name (from the User SUMMARY screen) and the client machine's IP address from which the user logged-in.
