Getting Started with Roles, Groups, and Users in Altair SmartWorks Hub
Altair EmployeeGetting Started with Roles, Groups, and Users in Altair SmartWorks Hub
[Needs to be extended to cover NameSpaces and Execution Profiles for Hub 2.1 onwards.]
Ref: Hub Documentation of the access control framework is here: https://hubdoc.worldprogramming.com/5EA-2.1.3.186/use/accesscontrol/
When you first synchronise Altair SmartWorks Hub with LDAP or Active Directory then your selected groups and user definitions are assimilated into Hub alongside the pre-defined users and groups.
Note that each imported user has a UPN (User Principal Name) and any jobs are invoked using that UPN. However the pre-defined user HubAdministrator does not have a UPN and cannot invoke jobs - though all other hub admin tasks are available to this user of course.
Initially, even though your users and groups have been synchronised into Hub, they do not have any permissions to do anything. To give then permissions they need to be added to the relevant pre-defined groups.
At a typical site, one administrator and a group of end-users are going to be given access to the Hub functionality.
1. Your administrator should be added to the predefined group HubAdministrators. The HubAdministrators group has a binding to the HubAdministrator role, and therefore all members of the HubAdministrators group have HubAdministrator role permissions.
Note: If you don’t want to make a named user to be a HubAdministrator that is perfectly okay – but be sure to keep a record of the password of the build-in user HubAdministrator for when it is needed.
2. Next, the external (LDAP/AD) group containing the end-users should be added as a nested group inside the pre-defined group HubUsers. If there is no convenient external group containing all the relevant people, then the individual external users can be added to the HubUsers group.
3. Finally, you may well also wish to add your external group (or your individual users) to the following pre-defined groups (though obviously this may be tailored to suit the intended Hub usage at your site):
- GROUP:DataAccessConsumers – so that your users can use Library Definitions.
- GROUP:InvocationPortalUsers – so that your users can use the Invocation options in the portal to run/test their programs.
- GROUP:ArtifactDevelopers – so your users can upload their programs from Workbench.
- GROUP:LinkSessionUsers – so your users can connect to Hub from Workbench.
- GROUP:PipelineUsers – so your users can create, view, and submit pipeline tasks.
We would recommend that you do not alter or delete any of the pre-defined users and groups except to add new members and subgroups to pre-defined groups.
APPENDIX: Pre-defined Entities in SmartWorks Hub
Note: SmartWorks Hub is still under development so these may have changed since this document was written.
Pre-defined Users
The following 8 users are pre-defined in SmartWorks Hub. (Not including the internal-only service accounts.) You may never need to use these special users - with the except of HubAdministrator.
- USER:ClusterAdministrator "Cluster Admin"
- USER:DataAccessAdministrator "Data Access Administrator"
- USER:CredentialManager "Credential Manager"
- USER:DeploymentServicesAdministrator "Deployment Services Admin"
- USER:HubAdministrator "Hub Administrator"
- USER:HubUser "Hub User"
- USER:NoRoles "No Roles"
- USER:SimpleUser "User with just User Role"
Pre-defined Groups
The following 11 groups are pre-defined.
The first 5 contain a single user with the same name as the group.
- GROUP:ClusterAdministrators = { USER:ClusterAdministrator }
- GROUP:DataAccessAdministrators = { USER:DataAccessAdministrator }
- GROUP:CredentialManagers = { USER:CredentialManager }
- GROUP:DeploymentServicesAdministrators = { USER:DeploymentServicesAdministrator }
- GROUP:HubAdministrators = { USER:HubAdministrator }
The group HubUsers is prepopulated with 6 users and 1 subgroup:
- GROUP:HubUsers = { USER:HubAdministrator USER:HubUser USER:SimpleUser USER:DataAccessAdministrator USER:DeploymentServicesAdministrator GROUP:CredentialManagers }
The user HubUser is also a member of these 3 groups:
- GROUP:DataAccessConsumers = { USER:HubUser }
- GROUP:LinkSessionUsers = { USER:HubUser }
- GROUP:PipelineUsers = { USER:HubUser }
These two groups are created empty:
- GROUP:InvocationPortalUsers = { }
- GROUP:ArtifactDevelopers = { }
Role Bindings
There is a 1:1 correspondence between these 11 role-bindings and groups, so that in each case, members of the group are assigned the capability of the role.
- BINDING:ClusterAdministrator = { GROUP:ClusterAdministrators }
- BINDING:DataAccessAdministrator = { GROUP:DataAccessAdministrators }
- BINDING:DataAccessConsumer = { GROUP:DataAccessConsumers }
- BINDING:CredentialManager = { GROUP:CredentialManagers }
- BINDING:DeploymentServicesAdministrator = { GROUP:DeploymentServicesAdministrators }
- BINDING:InvocationPortalUser = { GROUP:InvocationPortalUsers }
- BINDING:ArtifactDeveloper = { GROUP:ArtifactDevelopers }
- BINDING:HubAdministrator = { GROUP:HubAdministrators }
- BINDING:LinkSessionUser = { GROUP:LinkSessionUsers }
- BINDING:PipelineUser = { GROUP:PipelineUsers }
- BINDING:User = { GROUP:HubUsers }
Roles
14 roles are pre-defined:
- ROLE:ClusterAdministrator
- Users with this role can manage nodes in the Hub cluster
- They also have access to the route for the admin page
- ROLE:DataAccessAdministrator
- Users with the DataAccessAdministrator role can do anything with library-definitions.
- ROLE:DataAccessConsumer
- Users with this role have read access to LibraryDefinitions
- ROLE:CredentialManager
- Users with this role can manage Authentication Domains and related credentials
- ROLE:DeploymentServicesAdministrator
- Users with this role can do anything within the Deployment Services application
- Currently only users with the DeploymentServicesAdministrator can get to the DeploymentServices application and associated routes
- DeploymentServicesAdministrator need to be able to administer ArtifactRepos and Artifacts
- ROLE:InvocationPortalUser
- Users with this role have access to the invocation portal
- ROLE:AnyDeployedProgramConsumer
- Users with this role may invoke any deployed program
- ROLE:ArtifactDeveloper
- Users with this role may upload artifacts
- ROLE:LinkSessionAdministrator
- Users with this role can manage link sessions and configurations
- They also need access to the route for the admin page
- ROLE:LinkSessionUser
- Users with this role can create link sessions and manage their own sessions
- ROLE:PipelineUser
- Users with this role can create/view/submit pipelines and pipeline runs
- ROLE:User
- We currently allow any authenticated user to be able to access the
- root page of the portal. This doesn't necessarily allow then to see
- any applications in itself.
- We allow any authenticated user permission to see their settings page.
- All authenticated users are able to get to the "my credentials" page.
- Any authenticated user has "lookup" permission for groups and users.
- And in order to create credentials in MyCredentials, a user needs to list available Auth Domains.
- ROLE:HubAdministrator
- The HubAdministrator role has permission to do anything
- ROLE:AllPortal
- Users with this role access any part of the portal. For testing purposes.