Authorization: The Idea

A Smalldb state machine performs operations only when a transition is invoked. So the control what a user can do is reduced to what transitions he can invoke. When the user is not allowed to invoke a transition, it is as the given arrow is missing in the state diagram.

The state machine definition contains rules specifying who can invoke a transition, and each transition has one of these rules assigned. The rule can refer to user’s role or his relation to another entity (to express ownership or similar features).

Since the whole security model is defined in one place, it is relatively easy to verify the correctness of the application’s security model. Also, the rules can be visualized in the state diagram, making the verification even easier.

Controllers and views can check the availability of relevant transitions to hide parts of a user interface, which would invoke unavailable transitions. But it is only a matter of usability and aesthetics because even if the user interface is available to the unprivileged user, the permissions are always verified at the state machine (model) level, and the user is not allowed to do anything he is not supposed to.

Authorization: Example

The following diagram shows an article state machine with two user roles. An author is allowed (hollow blue arrows) to write and submit an article. An editor is allowed (filled red arrows) to return the article to the author or reject/accept it for publishing. Once the article is in “Published”, “Rejected”, or “Waiting” state the author cannot do anything with it because no blue arrows are leading from these states (and the author does not see the red arrows).

Note that while the editor is defined using a simple role-based condition, the authorship is a relation between a particular article and its author. The “Create” transition is available to all users (black arrow) because there is no author to a non-existent article.

Article with permissions

From a perspective of formal analysis, the otherwise tiresome properties, like state reachability or liveness of a state machine, are much more interesting when access control is in play. We can use these properties to make sure users would not get stuck somewhere, and they can reach their goals.

Authentication & Session management

Smalldb implements authentication in two components: CookieAuth and SharedTokenMachine. CookieAuth implements IAuth interface, which tells Smalldb state machine who is current user, so the state machine can determine, whether or not is the user allowed to invoke a transition. CookieAuth reads and updates cookies and maintains reference to SharedTokenMachine.

SharedTokenMachine is a state machine which maintains and represents user’s session. Smalldb does not define all aspects of this machine, programmer is expected to extend it for needs of a particular application, but it covers typical life cycle of such session. Login, logout and other actions are implemented as transitions of the SharedTokenMachine and rest of the Smalldb framework is completely isolated from these.

Relation between user’s session and the user itself is completely up to the session state machine implementation. The session state machine is expected to use calculated properties to retrive some details about the logged-in user.

AllowAllAuth can be used in place of CookieAuth to allow everything for everyone. It effectively disables any access control in Smalldb.

Permission model in SQL

Comming soon.

See also …