Who can do what with Form Builder? You guessed it: in this post, we’ll discuss access control, as it relates to Form Builder. More specifically, that question has two facets:
When it comes to people using Form Builder to create or edit forms, often referred to as form authors, who can create or edit which form?
When it comes to the end-users of the forms created with Form Builder, who can access which form?
In both cases:
Permissions are role-based: access isn’t given based on usernames, but on roles. For instance, for Form Builder permissions (the first case above), you could be defining that only users with the role finance can access forms in the app payroll.
Users and roles are not defined in Form Builder or Orbeon Forms. Instead, you configure the container (say, Tomcat), in which you’re running Orbeon to leverage your existing authentication system, say users and roles defined in LDAP. And if you don’t already have users and roles defined somewhere, Tomcat lets you define them is a simple XML file (tomcat-users.xml).
Let’s get back to the two types of access control mentioned earlier:
Access control to Form Builder itself is done through a property file: form-builder-permissions.xml. There, you can define which roles have access to which apps, and which forms. This is most often used to partition your forms into group, and give people access to a specific group. For instance, a local government might have different departments, say police, social services, parks, housing… and would like to keep the forms for each department separate. So they will create an app and a role for each department, and will define in form-builder-permissions.xml that form authors can only access forms of a given app of they have the corresponding role; say, they can only access forms in the social-services app if they have the social-services role. For more on this, see how to define access control to specific apps/forms in Form Builder.
Access control to published forms is a new feature of the upcoming Orbeon Forms 4.0, but you can already give it a try today using a nightly build. With this new feature, you can, as a form author, define who can access the form you’re editing right from Form Builder. You do so through a dialog, as shown in the screenshot below. For more on this, see how to define access control for deployed forms with Orbeon Forms 4.0.
I was wondering about your motivation behind the authorization breakdown of CRUD operations: why are read and update together?
I can understand this from the perspective of an end-user: if you can create a submission, and you can update it, you have to able to read it as well.
But the role responsible for administering the data of the form, which may or may not be the form author , might need read-only access (for all submissions, where-as end-users should only be allowed to update their own submission).
How would you control access to form summary data?
Good question. We have been thinking of separating "read" and "update". In fact, we are already storing those are two separate permissions; it is just that, right now, you can only set or unset them both at the same time. So in the future, we might add support for "read" without "update". The result is that you'll be able to look at the data, but not change it, essentially getting a read-only version of the form, similar to what is generated when you click on "review".
Nice round-up post.
ReplyDeleteI was wondering about your motivation behind the authorization breakdown of CRUD operations: why are read and update together?
I can understand this from the perspective of an end-user: if you can create a submission, and you can update it, you have to able to read it as well.
But the role responsible for administering the data of the form, which may or may not be the form author , might need read-only access (for all submissions, where-as end-users should only be allowed to update their own submission).
How would you control access to form summary data?
Good question. We have been thinking of separating "read" and "update". In fact, we are already storing those are two separate permissions; it is just that, right now, you can only set or unset them both at the same time. So in the future, we might add support for "read" without "update". The result is that you'll be able to look at the data, but not change it, essentially getting a read-only version of the form, similar to what is generated when you click on "review".
ReplyDelete