We recently launched Onshape Enterprise, our premium platform for companies with more sophisticated and complex design processes – usually involving multiple product lines and teams spread across multiple locations. Our development team has spent the last 18 months building Onshape Enterprise, including six months of testing with hundreds of pilot users. (For a comprehensive outsider’s look, check out DEVELOP3D editor Al Dean’s product review here).

Now for an insider’s view… As Onshape’s team lead for Enterprise features, I’m proud of the unprecedented visibility we’re bringing to each stage of the product development cycle. Your talented employees and the products they create are not distinct, disconnected atoms that randomly come and go. Everyone and everything are interrelated – and Onshape Enterprise helps companies of all sizes tightly pull together and manage people and products for the long haul.

Sounds awesome, you say, but how does it all work? The best place to get a quick overview of Enterprise’s full functionality is to take my colleague Neil Cooke’s product tour in this video. However, in this blog, I’d like to explore the value of role-based access control.

"Role-based access control" (RBAC) is a widely used term but its meaning varies across systems that use an RBAC model. At a high level, the goal of all RBAC models is to allow you to specify "who can access what" in terms of the "roles" that people fill, rather than in terms of specific users. Another attribute of many RBAC models (including Onshape's) is that the role a person fills depends on the context. For example, in Onshape, the same person could be in the "Project Administrator" role in one project, but serving in the "Design Engineer" role for another project.

Defining Roles

In Onshape, a company's set of roles is defined at the company level – i.e., there is a single set of roles that applies to the whole company. At the company level, a role is just a name – such as Design Engineer or Supplier – and by itself doesn't control access to anything. Simply put, it is any logical role that people can fill within the company.

Your Onshape Enterprise Company comes with a set of "out of the box" roles. A company administrator can add to and remove from his/her company's set of roles and modify existing roles.

Using Permission Schemes

In addition to roles, Onshape lets a company administrator create, delete, and modify a set of "permission schemes" for his/her company. A permission scheme defines a set of relationships between roles and a set of permissions. For example, a permission scheme might specify that the Design Engineer role has Edit permission and the Supplier role has View and Comment permission. Like roles, by itself a permission scheme doesn't control access to anything. You can think of it as a sort of "template" for permissions that (as described in the next section) will control access to things.

Your Onshape Enterprise Company comes with a set of "out of the box" permission schemes. A company administrator can add to and remove from his/her company's set of permission schemes and modify existing permission schemes.

Creating Projects

Roles and permission schemes come together and control access to things in the context of projects. Unique to Onshape Enterprise, projects are like top-level folders that help you organize your company’s documents – but they come with some extra features (including role-based permissions).

One attribute of every project is what permission scheme the project uses. Put another way, every project refers to one of the company's permission schemes. When you create a project you must specify what permission scheme you want to associate with that project. Later, you can change which permission scheme a project refers to.

Another attribute of every project is the "role map," a list of entries that specifies which people fill which particular roles. For example, a project's role map might say that in that project, John and Mary are Design Engineers, and Fred is a Supplier.

Tying all this together visually, the following diagram shows a company with three roles, two permission schemes (named External Permission Scheme and Internal Permission Scheme), and one project (named My Project):

My Project uses the External Permission Scheme. Note how My Project's role map defines which users play the various roles that are defined by External Permission Scheme.

Suppose Fred tries to access one of My Project's documents. Fred is listed in the project's role map as a Supplier. The project uses the External Permission Scheme, which specifies that the Supplier role has View & Comment permission. Hence Fred gets View & Comment permission to the documents.

How Does Your Company Want to Organize Its Work?

You might be wondering "Why have all these types of objects in your RBAC model?"

To be clear, we expect that most companies will have a relatively small number of roles and a relatively small number (maybe even just one or two) of permission schemes. The number of projects could be anywhere from small to large depending on the amount of work the company is doing and how the company wants to organize its work.

Also, it's important to understand that almost all of the above need not be understood by the vast bulk of users. Users who create projects need to have a rough idea of the model, while company administrators need to understand the whole thing. But end users just create and access documents and automatically get appropriate access to those documents.

The main reason for this model is to help ensure that resources (documents and folders) are uniformly protected over time and it lets company administrators establish and maintain a set of policies about protection. When users create a project, they need only pick one of the established set of permission schemes and then plug in the names of the users they want to fill the various roles associated with the chosen permission scheme.

Relatedly, this model makes it easy for a company administrator to make changes to the company's protection policies. By making changes to a permission scheme (e.g., changing the permissions that a role is granted), all projects that use that permission scheme automatically get updated so the projects' documents are now protected according to the new policies.

When a company has a lot of projects, it's likely that the projects' permissions requirements can be categorized into a number of "buckets." For example, one bucket might cover projects that are being done as part of military contracts. Another bucket might be for projects that contain prototype work. Yet another bucket might be for projects that the company considers to be tightly controlled within the company. And so on.

Each of these buckets can be implemented in Onshape as a permission scheme. For example, all projects for prototyping work might have no need for suppliers, so such projects would use a permission scheme that doesn't mention the Supplier role at all. And the actual people working on projects will likely vary from project to project. Judy might be allowed to access one tightly controlled project, but not another. Even though she's a design engineer, she might not be assigned the Design Engineer role in every tightly controlled project.

Interested in learning more? Stay tuned to this blog for an upcoming series of posts on the unprecedented benefits of Onshape Enterprise.