# User Management
CloudWright authentication and user management is organized around Users, Teams, and Organizations.
CloudWright customers are provided a CloudWright Organization, accessible via a custom subdomain like
mycompany.cloudwright.io. Customers have control over which users are able to log into and use resources in their Organization.
A CloudWright Organization will have one or more Teams. Team membership is how permissions are granted in CloudWright — a user will have 'Viewer', 'User', 'Editor', 'Publisher', or 'Admin' permission on one or more Teams.
Teams are the basic unit of sharing in CloudWright — when a Module or Application is created within an Team, all Team members with appropriate permissions can edit, view, or run the Application.
CloudWright uses Google Sign-In for user authentication. If your organization wants to use CloudWright but needs to use a non-Google authentication provider, let us know and we will hook you up.
# User management
One or more users will be 'System Administrators' in a CloudWright Organization, with permission to add, remove, or change the permissions assigned to other users. CloudWright system administrators also control who is allowed to log into a CloudWright Instance.
Users can be added two different ways: manually, or via self-registration.
# Manual registration
A system administrator can manually add users via the 'Manage Users' tab of the admin view. 'Add New Users' will prompt for the new users and the permissions to grant the new user.
Once a user is added, they will be able to authenticate into the application using the standard authentication provider log-in flow.
Selecting a user from the list of users will allow the administrator to grant and remove permissions, or to entirely delete the user.
In a large organization, CloudWright administrators may want to allow users to self-register into a CloudWright instance. CloudWright allows administrators to configure a list of 'Allowed Domains' in the 'Global Permissions' tab:
If a domain whitelist is configured, any attempt to log in using an email matching the domain whitelist will be automatically created.
Administrators are free to modify or delete self-registered users in the same manner as manually-registered users.
The following Team permissions can be granted to users:
- Viewer - Allows the user to view the source code and configurations of all applications on a Team.
- User - Grants Viewer permissions, and also allows the user to run all applications on a Team via the Run Console
- Editor - Grants User permissions, and also allows editing all applications on a Team
- Publisher - Grants Editor permissions, allows users to create and edit modules, and allows publishing of applications
- Admin - Grants Editor permissions, and also allows editing Team metadata (e.g. the Team's name)
The following Organization permissions can be granted to users:
- Viewer - Equivalent to granting Viewer on all Teams
- User - Equivalent to granting User on all Teams
- Editor - Equivalent to granting Editor on all Teams
- Publisher - Equivalent to granting Publisher on all Teams
- Admin - Gives full edit access to all non-personal resources, and gives access to the Admin console, where user permissions can be changed and where Deployment Zones can be created and managed.
# Global permissions
In a large organization, adding permissions to individual users may be burdensome. Administrators may want to grant all users a minimum set of permissions for various reasons:
- All users able to register from a given email domain should be authorized users
- All users should be granted 'View' access on several Teams
- The user has created an 'Examples' Team viewable by anyone in the company
The 'Default Permissions' tab allows administrators to configure a set of permissions granted to all users in a CloudWright Organization, including both self-registered and manually-registered users.
Note that all permissions augment, but never subtract from, other granted permissions — so a globally-granted 'Edit' permission on a Team cannot be downgraded for a particular set of users.
# Single Sign-On
CloudWright supports single sign-on using the SAML protocol. Any SAML identity provider is supported as long as they provide an Identity Provider Metadata XML document. Below we describe how to integrate with Okta, a popular SAML Identity Provider. If you'd like to integrate with another SAML provider and need assistance, email us at email@example.com. Once single sign-on is enabled, signing in from other sources will be disabled.
First, you'll need to create a new Application in Okta. In the Okta Admin console, go to Applications > Add Application > Create New App and select "Web" and "SAML 2.0"
Once the app is created, set the application name to "CloudWright", and if you wish download the CloudWright logo banner here and upload it as the application icon.
Click "Next", then enter
If you want to manage permissions in CloudWright based on groups you've configured in Okta, add a Group-Attribute Statement which specifies which groups should be sent to CloudWright, and name it "group". Here, we've configured Okta to send all groups that a user is in if they start with "cloudwright":
Click next, then select "I'm an Okta customer adding an internal app", and then click "Finish". On the screen that appears, click "View Setup Instructions"
On the screen that shows, scroll down to the last section which says "Provide the following IDP metadata to your SP provider." Copy the XML document in this section.
In the CloudWright UI, go to Admin > Single Sign-On Management and click "Enable SAML SSO". In the textbox that appears, paste the XML metadata document you copied above, then click "Save".
Single sign-on with Okta is now configured for your Organization.
# Group Permission Management
If your SSO provider supplies SAML assertions with the name "group", users will automatically be assigned to or removed from groups in CloudWright based on these assertions. You can configure permissions for these groups in the Admin > Single Sign-On Management view, under the "Group Permissions" heading. Configuring permissions for a group functions like assigning permissions to users, except that every member of the group will gain those permissions.