我应该如何使用 Keycloak 为“无角色”（ACL、ABAC）REST API 设置授权？

Question

My reasoning is based on the premise that when it comes to security, one should not reinvent the wheel and is better off studying which of the available solutions fits best.

Suppose you have an application that lets users create things and allow their friends to change them in some way. I imagine that using a role-based approach would not work well in this situation and that something like an access control list for each thing is closer to ideal.

Following the premise I presented in the first paragraph, I studied Keycloak's documentation in search of something akin to ACLs, as I'll also need an authentication mechanism. I could not come up with a solution that didn't feel "hacky", to say the least...

Instead of writing an exhaustive list of what I thought of, I'd like to ask:

• Is my reasoning correct?
• Is Keycloak really what I'm looking for or I should use it in tandem with something like casbin?
• How would you solve this?

Thanks!

Edit (14/05/20)

To further discuss this topic, I'll provide a more concrete (albeit simple) example. I'll also share some advice from a key contributor to Keycloak.

Let's say we're developing a simple Medium clone that allows users to coedit articles. Lance is an already registered and authenticated user that wants to start writing an article on bicycles, so he navigates to an "editing screen" in our SPA. Lance then gives it a title, write a few words and hits a "Create" button that sends a POST request to a resource server (already protected by Keycloak). The resource server (service) will then: 1. Persist the article to a database; 2. Create a resource via Keycloak's Protection API with its owner attribute set to Lances's user ID and an empty "editors" attribute.

Later on Lance decides that it would be good to have his friend Chris' opinion as well and therefore adds him to the list of editors. This could be done via Keycloak's Protection API, too.

This set-up would then allow us to set a JavaScript-Based policy to protect further edits.

Answer 1

Your reasoning is correct, as it actually fits the definition of "resource". Being your own application the resource server, Keycloak provides the authorization to access it or not, depending on what you consider.

I guess your concrete case is covered by User Managed Access :

As an example, consider a user Alice (resource owner) using an Internet Banking Service (resource server) to manage his Bank Account (resource). One day, Alice decides to open her bank account to Bob (requesting party), a accounting professional. However, Bob should only have access to view (scope) Alice's account.

As a resource server, the Internet Banking Service must be able to protect Alice's Bank Account. For that, it relies on Keycloak Resource Registration Endpoint to create a resource in the server representing Alice's Bank Account.

At this moment, if Bob tries to access Alice's Bank Account, access will be denied. The Internet Banking Service defines a few default policies for banking accounts. One of them is that only the owner, in this case Alice, is allowed to access her bank account.

However, Internet Banking Service in respect to Alice's privacy also allows her to change specific policies for the banking account. One of these policies that she can change is to define which people are allowed to view her bank account. For that, Internet Banking Service relies on Keycloak to provide to Alice a space where she can select individuals and the operations (or data) they are allowed to access. At any time, Alice can revoke access or grant additional permissions to Bob.

For your case the resource would be the thing and your application would need to register it in the Resource Registration Endpoint. Then, you might use policies to define who accesses the resource and how .

Answer 2

From what I've been told from the contributor I mentioned in my question (post-edit), this reasoning is correct and it is one way it could be done. Also, as @Xtreme Biker said, we could also make use of the UMA features Keycloak provides to let users manage their resources.

The contributor also said one should weigh in the overhead and duplication of this solution might add and consider keeping fine-grained authorization closer to the application/resource server/service.