This post was originally published on the website of Pavouk OÜ (Estonia). On 2020-06-12, I announced that Pavouk OÜ was closing. The posts I wrote have been moved here.
We’re pleased to announce the release of Tigrosa 1.1—the secure authentication and authorisation proxy. This version introduces a flexible roles permissions system, introducing the concepts of a user realm (such as admin) and a role for a specific organisation (usually member, but now can also be an organisation admin). Tigrosa is like a guard-spider, protecting a backend REST API using JSON, abstracting away the notions of users and organisations from the upstream. This decreases the logic necessary in the upstream API, decreasing time-til-market and increasing security.
User Realms
Users can now be assigned realms, which override the normal realms which would otherwise be calculated automatically. Using this, it’s possible to mark a user as admin, enabling top-level setup of a backend application to take place through the API. It is also now possible to assign a user to the existing public realm, which in effect blocks them and consigns them to wander the corridors of the public-accessible routes (such as the API apex).
{
"href": "/user/a080b4fe-fe56-11e8-9a91-525400b2f83e",
"user_key_href": "/user/a080b4fe-fe56-11e8-9a91-525400b2f83e/user_key",
"user_ses_href": "/user/a080b4fe-fe56-11e8-9a91-525400b2f83e/user_ses",
"realm": "private"
}
Organisation-User Levels
In addition to assigning a user to an organisation, it is now possible to assign a level. By default, users are assigned as member, typically granting them access to a variety of operations permitted by virtue of being associated with that organisation. Now, it’s also possible to assign a user as an organisation admin, which can be used to allow them management of more protected operations. This operates independently to the user realms, and a user can be an admin of one organisation, but only a member of another.
{
"href": "/org/6180c5ea-30d1-11e8-8001-0242ac170004/user/a8825b3c-290c-11e8-ac92-080027673e13",
"org": {
"href": "/org/6180c5ea-30d1-11e8-8001-0242ac170004"
},
"user": {
"href": "/user/a8825b3c-290c-11e8-ac92-080027673e13"
},
"level": "member"
}
Vastly-Increased Performance
All database calls have been cached through an intelligent in-memory caching layer, vastly increasing possible performance throughout. Not only does session validation now usually happen entirely in-memory, but dependent resources such as users and organisations are now loaded and cached separately, accessed as needed for permissions enforcement. We haven’t conducted any benchmarks, as yet, but we anticipate the performance of many use-cases improving by a couple of orders of magnitude or so.
We’ve also paved the way for seamless split-query logic for read-write nodes using streaming replication in clusters, as well as split read-write cache access for the extreme use-cases where even this performance isn’t enough. We hope to launch this functionality fully in a future release.