Authorizations

[briantopping]

Great project, thanks! Works effortlessly.

Any interest in Shiro as an authorization provider? Other ideas come to mind? This being the Scala world, it strikes me that someone out there has created the perfect RBAC in five lines with scalaz, but alas, I don't have those five lines :)

[adamw]

I'm not really familiar with Shiro, but if there would be an integration point, then sure! As I see it provides session management - would it be in any way possible to integrate the two session concepts?

[briantopping]

Shiro is kind of a Java standard for authentication. Looks like some others have copied it in Scala, which is nice. Check out https://github.com/eikek/porter. I think this is a much better candidate to integrate or merge.

[adamw]

Though it has only 1 star :) But sure, ideally that would be a module separate from both projects (integrating them)

[briantopping]

haha, yah. I don't think people doing Scala are doing a lot of apps with traditional enterprise features. Project like this isn't needed.

I'll look at the JWT module and see how the integration works..

[briantopping]

Some notes since I am uploading this to Bountysource:

In general terms, I'd like to add permissions checks for users. https://shiro.apache.org/authorization-features.html has a good overview of the things most people wonder about when they are first exposed to authorizations.

The core api an application needs is the ability to check if a user has a permission to do something, just a binary check of the permission key, i.e. a string such as "AddUsers" that is hardcoded into a specific piece of functionality. If they have a permission, the UI for adding a user could be presented. As one can imagine in a distributed app, the server also needs to perform this check if a new user is actually submitted, just to make sure the app wasn't hacked or someone put rogue commands on the wire.

In an app with hundreds of functions, there would be hundreds of permissions, so the check has to be lightweight or cacheable. In a naive implementation, one could just put all these permissions in a map with the keys as strings and the values as sets. A permission check would involve dereferencing the map and returning a boolean corresponding to whether the requesting user was in the set stored for that key of the map.

There are two big improvements required to this base case:

• Administering hundreds of discrete permissions like this is error prone. If one has 10,000 users with 100 permissions, there's a million potential permissions. Most apps are much larger.
• Apps filter data and offer behaviors depending on the user. As a manager, I may be able to add a user to groups I manage, but not to groups managed by others.

The first problem is solved by roles. Roles are basically parent groupings of permissions or other roles. A role called "Manager" might have the ability to add and remove users from groups. Now, instead of manually adding all these permissions to a new manager, the "Manager" role is given to the new manager and he has all the permissions other managers have. Even better, if a new permission is created for managers, it is simply added to the role, and all managers get the permission.

The dynamic problem could probably be built as time goes on. Generally, it's about creating a combinator that takes a discriminator function, there's a bazillion ways to skin that cat.

https://github.com/eikek/porter goes in to how some of this is done in the README.md, but it doesn't do anything with Akka HTTP Directives. As can be seen, doing them really really well takes a lot of investment and getting it wrong is a big liability. I've looked briefly at Porter and it seems to be 90% of what needs to be there. It seems to be patterned off Shiro, which is very robust. More importantly, much of that work is in place with unit tests. That's a few weeks just to get started.

[veotax]

jCasbin is an authorization library that supports models like ACL, RBAC, ABAC.

Related to RBAC, casbin has several advantages:

1. roles can be cascaded, aka roles can have roles.
2. support resource roles, so users have their roles and resource have their roles too. role = group here.
3. the permission assignments (or policy in casbin's language) can be persisted in files or database.
4. multiple models like ACL, BLP, RBAC, ABAC, RESTful are supported.

And you can even customize your own access control model, for example, mix RBAC and ABAC together by using roles and attributes at the same time. It's very flexible.

I saw there's an authorization need here, and I think jCasbin is a good choice. What do you think? Thanks.

[adamw]

@veotax do you have any specific idea on how would jcasbin integrate with akka-http? I suppose you could use any kind of authorization library and store the result in the session data.