Security in Hum

Enterprise Security

Enterprise applications need to secure access to certain features. A party[1] has to be authorized to request a service, control a robot, make a journal entry. In Hum, permits may be required for various actions:

1. Task level: Define who can invoke a goal in a task frame.
2. Action level: Define who can invoke an action via a dialog.
3. View level: Define who may view the data in the view.

To keep things simple, if no authorization constraint is declared, then no authorization is required.

[1] A party is a person, organization, or actor.

Authorization Annotation

In the example below, we use an annotation to declare the authorization required to perform the task: "Move customer to new-residence." The annotation: "[Allow call-center.]" means that actors operating with a call-center permit will be allowed to invoke this goal.

Similarly, the action statement "Change to new-billing-address ..." has the annotation: "[Allow call-center, self-service.]" and that means that the action statement can be invoked when an actor has either a call-center permit or a self-service permit.

Finally, the annotation on the Customer-Address view indicates that an actor holding any one of three permits is authorized to see a customer's address.

---
Task: Move customer to new-residence. [Allow call-center.]
. . .
---
Role: Billing. 
Action: Change to new-billing-address. [Allow call-center, self-service.] 
. for all the customer's customer-accounts. 
. . . 
---
View: Customer-Address. [Allow call-center, self-service, field-operations.]
. . . 
---

Authorization As Configuration Data

In some programming frameworks, the declaration of authorizations is separated from the definition of the program. This is done for two reasons:

1. The program may be run in more than one organization and therefore the permits will vary from organization to organization and should not be hard-coded into the program itself.
2. The permits can be changed without modifying the tested code.

Hum supports this concept and keeps things simple. The following example shows a data frame containing authorizations as configuration data. One simply copies the statement requiring authorization into the data frame and appends the appropriate authorization annotation. This data frame may be one of several used to configure an operating environment.

---
Data: Authorizations.
Task: Move customer to new-residence. [Allow call-center.]
Role: Billing. 
Action: Change to new-billing-address.  [Allow call-center, self-service.] 
View: Customer-Address. [Allow call-center, self-service, field-operations.]
---