CloudReady Teams for Access Control

Exoprise recently added flexible team and Role Based Access Control (RBAC) support to the CloudReady platform. As customers have expanded usage, there’s been a need for more control and delegation within the product. The engineers at Exoprise took a step back, investigated various implementations and put together a framework that should scale for years. Additionally, we migrated the platform — in place — with no downtime or interruption to our customers’ experience.

Inspiration

When we set out to add more control within our product, we didn’t want to reinvent the wheel. The engineers also didn’t want to over-complicate as we’ve all seen projects spiral out of control trying to add lots of access control features.

One existing popular SaaS product that inspired us was Github.  We don’t use Github for our hosted source-control but the service had similarities we thought were relevant:

• SaaS-based, easy to use
• Enterprise capable
• “Right-weight” team concepts (not too light, not too heavy)
• Simple roles within teams

Exoprise engineers concluded that the concepts were similar enough and that we could leverage some of the terminology and modality from the Github examples. Thus, our Team and Organization implementation was born.

Organizations

Originally, Exoprise had every person for themselves within our database and you could share out access to individual sensors on a person-to-person basis. It wasn’t scalable and our customers needed more. Re-organizing would have to be done carefully. Internally, we had to convert every account to an “Organization” and then carefully merge them together, sometimes manually ourselves. For some accounts, we gave customers the ability to import their own legacy “shares” to Organization members.

Organizations are now the root level within CloudReady. Every person that signs up is put in their own organization to start and additional users can be added to an organization. When organizations convert to payed accounts (as opposed to free trials) additional features can be unlocked. In the back-end, we have the capability to merge organizations together if two people within the same real organization happen to start consecutive or concurrent trials (a no-no according to our MSA).

Roles

Users can have organization-wide roles and team-wide roles.  The difference between organization and team roles is what resources; sites, sensors, alarms, etc. are included in the team.  This gives customers flexibility in organizing access while not being overly complex.

Access levels are controlled by the following roles,  starting with the most privilege:

• Owner
  Organization Owners can do absolutely everything within the product including adjusting billing, payment records, and giving other users Ownership rights.
• Admin
  Organization Admins can invite additional users, add teams, and can do pretty much everything within the Organization except adjust payments and billing.
• Deployer
  Organization Deployers can deploy and edit sites and sensors within the product but can’t invite additional users or create teams.
• Operator
  Organization Operators can add, edit, snooze and adjust alarms but can’t alter existing sensors or change settings for sites.
• Viewer
  Organization Viewers can view sensors and alarms but can’t make any adjustments – they’re just viewers (hence the name!)
• Member
  Members have no permissions within the Organization as a whole but are a reference for removing all access quickly. Members within an Organization don’t have any rights from the Organization so they must be in a Team to have access to any sites or sensors.

All access levels are data-driven, defined by discrete bits within the system and new roles can be added in the future.

Teams

Teams enable Organizations more fine-grained control to CloudReady Sites, Sensors and other resources within the CloudReady product. To leverage teams:

1. Create a team giving it a name, like Europe SharePoint Monitoring
2. Optionally, add sites for deployment or access to the team. You can set up sites in each region and designate different persons within the team to deploy sensors to those sites.
3. Optionally, add already deployed sensors to the team
4. Add users to the team with team specific roles – the same roles as above

A couple of other important points about inheritance and teams:

• Alarm access is inherited by the sensors that are added to a team.
• Sensor access is inherited if a site is added to a team. All sensors for a site are accessible to the team if you add the site to the team. If you don’t want all sensors to be accessible, then just add the sensors individually.

Sites & Sensors

We’ve mentioned resources, sites and sensors in regards to team access control a number of times. Currently, those are the primary resources that are added to teams. We will expand this to include alarms, integration’s and other types of sensors and monitoring in the future.

Futures

Speaking of the future, we have more plans in the works for our Organization and Teams functionality. We will soon be integrating Active Directory Federation Services into our Organizations and Teams. Additionally, we are building support for more expressive resource inclusion in teams. For example, we are adding support for dynamically including all sensors of certain types (e.g. SharePoint, Exchange Online, etc.) to teams. These are features that our customers are asking for as they expand their deployments of CloudReady.

If you have any questions about how this works or whether its suitable for your organization, send us a note: success@exoprise.com