Being in a view and you know the area-name, controller-name and action-name of a destination to which you want the user to provide a link to, how can I figure out if the area/controller/action is authorized for the authenticated user.
Imaginary Use-case:
I have a table with a list of books (the result of bookscontroller.index). To the far right are some icons to edit or delete a specific book. The edit link refers to bookscontroller.edit and the delete link to bookscontroller.delete.
On the actions there are custom authorizationattributes and this works perfect. If a user want to access books/edit/1 and the user is not allowed to edit books, the user gets redirected to the logon page.
It is a bit stupid to have that edit-icon there if the user is not allowed to edit books. So at view level I would like to be able to figure out if the user is allowed to use the edit action of the bookscontroller. If he is, show the icon if not, do not show the action.
Goal: use that knowledge to create a custom tag-helper.
The go-to method is reactive, i.e. you check if a user can do action when the user tries to do. Since you do not want to go that way, here is how. (yet, this is anti-pattern)
Have the authentication token of the user send back to backend. The backend should have an API end point for each button on the page user can click. With the authentication token, the back-end resolve whether to dim or enable the buttons.
Now, what the backend does to resolve this is not very efficient. The backend needs to literally attempt certain actions and aborts the transaction. For create and retrieve, it is trivial (you can pre-resolve them) but for edit and delete, this requires a lot of resources.
The standard way of controlling such actions on UI is to use role based authorization.
For the buttons or other such UI elements, setup role tags, e.g. "admin:edit", "viewer:readonly" etc.
When you are authenticating a user, send the applicable roles from the backend server, store them in a way that is globally accessible to your UI and use them for filtering UI elements across your application.
My team is attempting to move towards templatization of our services and their infrastructure.
We have found it to be extremely time-consuming to determine the set of permissions required to execute or update a given Cloudformation template. Our process is:
Create a user with permissions cloudformation:CreateStack and/or cloudformation:UpdateStack
Have that user attempt to create/update the specified stack
Observe which missing permission caused the stack operation to fail
Add that permission to the user
Go to 2.
The alternative to this would be to create a "God User" who has unlimited permissions and have that user execute the create/update - which seems to violate the Principle Of Least Privilege
Alternatively, is there a tool that can list "what permissions have been exercised by a given user in the past N minutes?". If such a tool existed, we could create the "God User", have them execute the template, and then create a more limited-scope user that has precisely the permissions that the God User had used.
There is no simple way/tool to do this.
Here are a couple of approaches you can try-
Using an User that has Admin priviledges, create the Stack. Once done, wait for 15-20 minutes for CloudTrail to populate. Now in CloudTrail list the API calls made by the 'Event Source' - 'cloudformation.amazonaws.com'. That should be roughly all the API calls required. There can be a few more calls required, for other operations as you keep on adding functionalities to the Resources. Again, you would need to figure that out this way.
Create a CFN service role , and add admin privileges to this Role. Use this Role to create/update/delete the Stacks. Allow the IAM users only iam:PassRole and cloudformation:* . However, users will be able to create different resources using CFN.
Use Service Catalog and create Products. Service Catalog Products are CFN Templates which can be launched by a specific user/Role/Group. The user does not need permission to create/modify the Resources in a Stack/Product. Also the end user cannot change the Product to add more Resources. Here's a great video that explains this stuff : https://www.youtube.com/watch?v=A9kKy6WhqVA
Hope this helps...
Hello again every one,
I have a question: I successfully implemented django-auth-ldap, the LDAP users can request successfully my DRF API. But nows, for my projetc needs, I have to define permissions depending of the group.
Indeed, I will have like 12 groups in my app. Depending of the group, I will authorize or not the user to request a given route, BUT even if I defined the global var AUTH_LDAP_MIRROR_GROUPS = True, and saw in my database the are linked to a group (see capture):
Users in database
Groups from LDAP inserted in db thx to django-auth_ldap settings
User linked to the groups defined
But now, I have some other problems: I do not know how to implement permissions depending of the group the user belong. In fact, if a user belong to the group ServerAdministrator, I want to allow him to access to every route accessible, but I dont know where to see this in the received request in my view?
As I understood, I should implement custom permissions I should write programmatically in a User object (which should inherit from django AbstractUser)
If yes, How does it work? Should I empty my whole Database and then let django-auth-ldap insert users and it also will create the given permissions defined inside the database?
Maybe it is not clear, do not hesitate to ask questions if I can be more precise.
Kind regards.
Benjamin
I want to create a fairly simple role-based access control system using Keycloak's authorizaion system. The system Keycloak is replacing allows us to create a "user", who is a member of one or more "groups". In this legacy system, a user is given "permission" to access each of about 250 "capabilities" either through group membership (where groups are assigned permissions) or a direct grant of a permission to the user.
I would like to map the legacy system to keycloak authorizations.
It should be simple for me to map each "capability" in the existing system to a keycloak resource and a set of keycloak scopes. For example, a "viewAccount" capability would obviously map to an "account" resource and a "view" scope; and "viewTransaction" maps to a "transaction" resource... but is it best practice to create just one "view" scope, and use it across multiple resources (account, transaction, etc)? Or should I create a "viewAccount" scope, a "viewTransaction" scope, etc?
Similarly, I'm a little confused about permissions. For each practical combination of resource and scope, is it usual practice to create a permission? If there are multiple permissions matching a given resource/scope, what does Keycloak do? I'm guessing that the intention of Keycloak is to allow me to configure a matrix of permissions against resources and scopes, so for example I could have permission to access "accounts" and permission for "view" scope, so therefore I would have permission to view accounts?
I ask because the result of all this seems to be that my old "viewAccount" capability ends up creating an "Account" resource, with "View" scope, and a "viewAccount" permission, which seems to get me back where I was. Which is fine, if it's correct.
Finally, obviously I need a set of policies that determine if viewAccount should be applied. But am I right that this means I need a policy for each of the legacy groups that a user could belong to? For example, if I have a "helpdesk" role, then I need a "helpdesk membership" policy, which I could then add to the "viewAccount" permission. Is this correct?
Thanks,
Mark
Full transparency- I am by no means a Keycloak/OAuth/OIDC expert and what I know is mostly from reading the docs, books, good ol' YouTube and playing around with the tool.
This post will be comprised of two parts:
I'll attempt to answer all your questions to the best of my ability
I'll show you all how you can play around with policies/scopes/permissions in Keycloak without needing to deploy a separate app in order to better understand some of the core concepts in this thread. Do note though that this is mostly meant to get you all started. I'm using Keycloak 8.0.0.
Part I
Some terminology before we get started:
In Keycloak, you can create 2 types of permissions: Resource-Based and Scope-Based.
Simply put, for Resource-Based permissions, you apply it directly to your resource
For Scoped-Based permission, you apply it to your scope(s) or scope(s) and resource.
is it best practice to create just one "view" scope, and use it across multiple resources (account, transaction, etc)? Or should I create a "viewAccount" scope, a "viewTransaction" scope, etc?
Scopes represent a set of rights at a protected resource. In your case, you have 2 resources: account and transaction, so I would lean towards the second approach.
In the long run, having a global view scope associated with all your resources (e.g. account, transaction, customer, settlement...) makes authorization difficult to both manage and adapt to security requirement changes.
Here are a few examples that you can check out to get a feel for design
Slack API
Box API
Stripe
Do note though - I am not claiming that you shouldn't share scopes across resources. Matter of fact, Keycloak allows this for resources with the same type. You could for instance need both viewAccount and viewTransaction scope to read a transaction under a given account (after all you might need access to the account to view transactions). Your requirements and standards will heavily influence your design.
For each practical combination of resource and scope, is it usual practice to create a permission?
Apologies, I don't fully understand the question so I'll be a bit broad. In order to grant/deny access to a resource, you need to:
Define your policies
Define your permissions
Apply your policies to your permissions
Associate your permissions to a scope or resource (or both)
for policy enforcement to take effect. See Authorization Process.
How you go about setting all this up is entirely up to you. You could for instance:
Define individual policies, and tie each policy under the appropriate permission.
Better yet, define individual policies, then group all your related policies under an aggregated policy (a policy of policies) and then associate that aggregated policy with the scope-based permission. You could have that scoped-based permission apply to both the resource and all its associated scope.
Or, you could further break apart your permissions by leveraging the two separate types. You could create permissions solely for your resources via the resource-based permission type, and separately associate other permissions solely with a scope via the scope-based permission type.
You have options.
If there are multiple permissions matching a given resource/scope, what does Keycloak do?
This depends on
The resource server's Decision Strategy
Each permission's Decision Strategy
Each policy's Logic value.
The Logic value is similar with Java's ! operator. It can either be Positive or Negative. When the Logic is Positive, the policy's final evaluation remains unchanged. When its Negative, the final result is negated (e.g. if a policy evaluates to false and its Logic is Negative, then it will be true). To keep things simple, let's assume that the Logic is always set to Positive.
The Decision Strategy is what we really want to tackle. The Decision Strategy can either be Unanimous or Affirmative. From the docs,
Decision Strategy
This configurations changes how the policy evaluation engine decides whether or not a resource or scope should be granted based on the outcome from all evaluated permissions. Affirmative means that at least one permission must evaluate to a positive decision in order grant access to a resource and its scopes. Unanimous means that all permissions must evaluate to a positive decision in order for the final decision to be also positive. As an example, if two permissions for a same resource or scope are in conflict (one of them is granting access and the other is denying access), the permission to the resource or scope will be granted if the chosen strategy is Affirmative. Otherwise, a single deny from any permission will also deny access to the resource or scope.
Let's use an example to better understand the above. Suppose you have a resource with 2 permissions and someone is trying to access that resource (remember, the Logic is Positive for all policies). Now:
Permission One has a Decision Strategy set to Affirmative. It also has 3 policies where they each evaluate to:
true
false
false
Since one of the policies is set to true, Permission One is set to true (Affirmative - only 1 needs to be true).
Permission Two has a Decision Strategy set to Unanimous with 2 policies:
true
false
In this case Permission Two is false since one policy is false (Unanimous - they all need to be true).
Now comes the final evaluation. If the resource server's Decision Strategy is set to Affirmative, access to that resource would be granted because Permission One is true. If on the other hand, the resource server's Decision Strategy is set to Unanimous, access would be denied.
See:
Resource Server Settings
Managing Permissions
We'll keep revisiting this. I explain how to set the resource sever's Decision Strategy in Part II.
so for example I could have permission to access "accounts" and permission for "view" scope, so therefore I would have permission to view accounts?
The short answer is yes. Now, let's expand on this a bit :)
If you have the following scenario:
Resource server's Decision Strategy set to Unanimous or Affirmative
Permission to access the account/{id} resource is true
Permission to access the view scope is true
You will be granted access to view the account.
true + true is equal to true under the Affirmative or Unanimous Decision Strategy.
Now if you have this
Resource server's Decision Strategy set to Affirmative
Permission to access the account/{id} resource is true
Permission to access the view scope is false
You will also be granted access to view the account.
true + false is true under the Affirmative strategy.
The point here is that access to a given resource also depends on your setup so be careful as you may not want the second scenario.
But am I right that this means I need a policy for each of the legacy groups that a user could belong to?
I'm not sure how Keycloak behaved 2 years ago, but you can specify a Group-Based policy and simply add all your groups under that policy. You certainly do not need to create one policy per group.
For example, if I have a "helpdesk" role, then I need a "helpdesk membership" policy, which I could then add to the "viewAccount" permission. Is this correct?
Pretty much. There are many ways you can set this up. For instance, you can:
Create your resource (e.g. /account/{id}) and associate it with the account:view scope.
create a Role-Based Policy and add the helpdesk role under that policy
Create a Scope-Based permission called viewAccount and tie it with scope, resource and policy
We'll set up something similar in Part II.
Part II
Keycloak has a neat little tool which allows you test all your policies. Better yet, you actually do not need to spin up another application server and deploy a separate app for this to work.
Here's the scenario that we'll set up:
We'll create a new realm called stackoverflow-demo
We'll create a bank-api client under that realm
We will define a resource called /account/{id} for that client
The account/{id} will have the account:view scope
We'll create a user called bob under the new realm
We'll also create three roles: bank_teller, account_owner and user
We will not associate bob with any roles. This is not needed right now.
We'll set up the following two Role-Based policies:
bank_teller and account_owner have access to the /account/{id} resource
account_owner has access to the account:view scope
user does not have access to the resource or scope
We'll play around with the Evaluate tool to see how access can be granted or
denied.
Do forgive me, this example is unrealistic but I'm not familiar with the banking sector :)
Keycloak setup
Download and run Keycloak
cd tmp
wget https://downloads.jboss.org/keycloak/8.0.0/keycloak-8.0.0.zip
unzip keycloak-8.0.0.zip
cd keycloak-8.0.0/bin
./standalone.sh
Create initial admin user
Go to http://localhost:8080/auth
Click on the Administration Console link
Create the admin user and login
Visit Getting Started for more information. For our purposes, the above is enough.
Setting up the stage
Create a new realm
Hover your mouse around the master realm and click on the Add Realm button.
Enter stackoverflow-demo as the name.
Click on Create.
The top left should now say stackoverflow-demo instead of the master realm.
See Creating a New Realm
Create a new user
Click on the Users link on the left
Click on the Add User button
Enter the username (e.g. bob)
Ensure that User Enabled is turned on
Click Save
See Creating a New User
Create new roles
Click on the Roles link
Click on Add Role
Add the following roles: bank_teller, account_owner and user
Again, do not associate your user with the roles. For our purposes, this is not needed.
See Roles
Create a client
Click on the Clients link
Click on Create
Enter bank-api for the Client ID
For the Root URL enter http://127.0.0.1:8080/bank-api
Click on Save
Ensure that Client Protocol is openid-connect
Change the Access Type to confidential
Change Authorization Enabled to On
Scroll down and hit Save. A new Authorization tab should appear at the top.
Click on the Authorization tab and then Settings
Ensure that the Decision Strategy is set to Unanimous
This is the resource server's Decision Strategy
See:
Creating a Client Application
Enabling Authorization Services
Create Custom Scopes
Click on the Authorization tab
Click on Authorization Scopes > Create to bring up Add Scope page
Enter account:view in the name and hit enter.
Create "View Account Resource"
Click on Authorization link above
Click on Resources
Click on Create
Enter View Account Resource for both the Name and Display name
Enter account/{id} for the URI
Enter account:view in the Scopes textbox
Click Save
See Creating Resources
Create your policies
Again under the Authorization tab, click on Policies
Select Role from the the Create Policy dropdown
In the Name section, type Only Bank Teller and Account Owner Policy
Under Realm Roles select both the bank_teller and account_owner role
Ensure that Logic is set to Positive
Click Save
Click on the Policies link
Select Role again from the Create Policy dropdown.
This time use Only Account Owner Policy for the Name
Under Realm Roles select account_owner
Ensure that Logic is set to Positive
Click Save
Click on the Policies link at the top, you should now see your newly created policies.
See Role-Based Policy
Do note that Keycloak has much more powerful policies. See Managing Policies
Create Resource-Based Permission
Again under the Authorization tab, click on Permissions
Select Resource-Based
Type View Account Resource Permission for the Name
Under Resources type View Account Resource Permission
Under Apply Policy select Only Bank Teller and Account Owner Policy
Ensure that the Decision Strategy is set to Unanimous
Click Save
See Create Resource-Based Permissions
Phew...
Evaluating the Resource-Based permission
Again under the Authorization tab, select Evaluate
Under User enter bob
Under Roles select user
This is where we will associate our user with our created roles.
Under Resources select View Account Resource and click Add
Click on Evaluate.
Expand the View Account Resource with scopes [account:view] to see the results and you should see DENY.
This makes sense because we only allow two roles access to that resource via the Only Bank Teller and Account Owner Policy. Let's test this to make sure this is true!
Click on the Back link right above the evaluation result
Change bob's role to account_owner and click on Evaluate. You should now see the result as PERMIT. Same deal if you go back and change the role to bank_teller
See Evaluating and Testing Policies
Create Scope-Based Permission
Go back to the Permissions section
Select Scope-Based this time under the Create Permission dropdown.
Under Name, enter View Account Scope Permission
Under Scopes, enter account:view
Under Apply Policy, enter Only Account Owner Policy
Ensure that the Decision Strategy is set to Unanimous
Click Save
See Creating Scope-Based Permissions
Second test run
Evaluating our new changes
Go back to the Authorization section
Click on Evaluate
User should be bob
Roles should be bank_teller
Resources should be View Account Resource and click Add
Click on Evaluate and we should get DENY.
Again this should come as no surprise as the bank_teller has access to the resource but not the scope. Here one permission evaluates to true, and the other to false. Given that the resource server's Decision Strategy is set to Unanimous, the final decision is DENY.
Click on Settings under the Authorization tab, and change the Decision Strategy to Affirmative and go back to steps 1-6 again. This time, the final result should be PERMIT (one permission is true, so final decision is true).
For the sake of completeness, turn the resource server's Decision Strategy back to Unanimous. Again, go back to steps 1 through 6 but this time, set the role as account_owner. This time, the final result is again PERMIT which makes sense, given that the account_owner has access to both the resource and scope.
i know i am bit late to the party but let me try to explain as much as i can.
in keycloak we have terms like :
Resource : object which users will be accessing or performing the action on
Auth scopes : Actions that users can perform on the specific object
Policies : Policy
Permission : Mapping actually occur here
If you don't want to follow manual way you can export this JSON and all the users, resources, permissions will be auto-set bu keycloak
JSON configuration file
Now let's see a scenario where :
Now we have few resources like :
Account
Bot
Report
We want to implement the scenario where only specific user can performe specific actions.
Setting up the Keycloak
Create a new realm
Click on the Add Realm button.
Enter test-v1 as the name.
Click on Create.
Create new roles
Click on the Roles
Click on Add Role
Create the roles "admin", "agent" & "super_admin"
Create a client
Click on the Clients tab
Enter app-client in Client ID textbox
Click on Save
Select and choose client again to configure other settings
Verify the client Protocol is openid-connect
Set Access Type to confidential
Set Authorization Enabled to On
Click on Save button at last.
A new Authorization tab will appear at the top.
Select on the Authorization tab and then Settings
Check that the Decision Strategy is set to Unanimous. This is the resource server strategy
Create Custom Auth Scopes
Go the Authorization tab
Select Authorization Scopes > and click on Create
Enter scopes:create & scopes:view in the text and save values.
Create Resource
Go to Resources tab now > and click on Create
Enter one by one and create the following resources res:account & res:bot & res:report
For all resource in scope text select both scopes that we created early scopes:create & scopes:view
Click Save
Create policies
Again inside the Authorization tab, select on Policies
Click on the Create Policy dropdown and select the Role
In the Name textbox, Admin
In Realm Roles select role Admin
Check Logic is set to Positive
Click Save, Do it same for "Agent" & "Super_admin"
Again inside the Authorization tab, select on Policies
Click on the Create Policy dropdown and select the Aggregated
In the Name textbox, Admin or Super_admin or Agent
In Realm Roles select role Admin & Super_admin & Agent
Check Logic is set to Affirmative
Click Save
Create permission
Again inside the Authorization tab, select on Permission
Click on the Create Permissions dropdown and select the Scope-Based
In the Name textbox, account-create
In resource box, select the "resource res:account"
In scopes select, scopes:create
Apply policy Admin
We have to set permission same way for all the resources as per requirement
Create user
Inside the user tab create one test user
We will not assign any roles, scopes, or group to it for testing
Let's Evaluate
Again inside the Authorization tab, select on Evaluate
Select the client we created, app-client
In user select the created user, test
In roles select the created user, admin
Resource value, res:account
Click on Add button
Click on Evaluate button
You will see grant is permitted as Admin role has access to do operations create and view on resource account.
Let's Evaluate Again
Again inside the Authorization tab, select on Evaluate
Select the client we created, app-client
In user select the created user, test
In roles select the created user, admin
Resource value, res:report
Scopes value, scopes:create
Click on Add button
Click on Evaluate button
You will see grant is Deny as only Super_Admin role has access to do operations create on resource report.
I was looking to enforce authorization via pure HTTP methods, without using the adapter as Lua did not have an adapter. Hope this answer helps people looking for non-adapter based method.
If you are looking for the adapter the quick start guide is the best place to start. Especially the spring boot authz example.
For pure HTTP based implementation:
Step 1:
Define the policies and permission in the Keycloak Admin UI
Step 2
Have an internal mapping of which HTTP paths belong to which resources and the required scopes for each path. This can be also saved in the configuration file. When a particular route is invoked, call the Keycloak token endpoint to validate the claims of the access token.
{
"policy-enforcer": {
"user-managed-access" : {},
"enforcement-mode" : "ENFORCING"
"paths": [
{
"path" : "/someUri/*",
"methods" : [
{
"method": "GET",
"scopes" : ["urn:app.com:scopes:view"]
},
{
"method": "POST",
"scopes" : ["urn:app.com:scopes:create"]
}
]
}
]
}
}
If you are using an adapter and does not specify the path or resource, the adapter will internally search for the paths and resources from Keycloak.
Step 3:
Use the token endpoint to get or evaluate the permissions. You can use response_mode parameter to either obtain the final decision (whether to provide access) or retrieve the entire permissions.
curl -X POST \
http://${host}:${port}/auth/realms/${realm}/protocol/openid-connect/token \
-H "Authorization: Bearer ${access_token}" \
--data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
--data "permission=Resource A#Scope A"
If the authorization request does not map to any permission, a 403 HTTP status code is returned instead.
A working solution with resources, scopes and permissions can be found here
keycloak-nodejs-example
Just run already configured Keycloak using docker-compose using Quick Start guide.
Other useful examples in the project
Custom login without using Keycloak login page.
Stateless Node.js server without using a session. Keycloak token is stored using cookies.
A centralized middleware to check permissions. Routes are not described explicitly can't be accessed.
Configuration without keycloak.json. It can be used to having configuration for multiple environments. For example — DEV, QA.
Examples of using Keycloak REST API to create users, roles and custom attributes.
How to handle Authorization in GraphQL servers?
Shall I pass the JWT token in the Authentication header of every requests and check for the authorized user after resolve() and check for the role of user on every query and mutation
Introduction
First of all, a common approach for authentication as you state is using a signed JWT that contains the id of the user making the request.
Now let's have a look at the different parameters we can use when considering the authorization of a given request.
who is making the request?
determined by the user id mentioned above. More information about the requester like associated user roles can be looked up in the database. This means that we need to maintain a User table if we are using SQL for example, and add new users to this table on registration.
which operation should be executed?
users might be granted read-only access. Certain mutations or queries are only allowed for certain users.
which fields are included in the query/mutation response?
some fields should be only accessed by certain users.
Permissions
With this information in mind, we can come up with different permission systems. Most commonly, in such a system, no operation is allowed by default. When a request comes in, the parameters mentioned above can be matched with the existing permissions and if a matching permission is found, the request is granted.
Role-based permissions
In certain applications, a role-based approach works great.
For example, for a simpler version of Stack Overflow, we could have the roles EVERYONE, AUTHENTICATED and MODERATOR. A sensible permission rule could be this:
EVERYONE can read questions/answers
requester: doesn't matter (everyone)
operations: allQuestions, allAnswers queries
fields: text
Other rules (leaving parameters out):
* AUTHENTICATED users can create new questions/answers
* MODERATOR users can create new questions/answers
* MODERATOR users can delete questions/answers.
Now for example, if a non-authenticated requests comes in that asks for the allQuestions query, that's fine as we find a permission that allows it (the first).
If on the other hand an authenticated requests comes in for a user that doesn't have the MODERATOR role and includes the deleteQuestion mutation, there is no permission to be found for these parameters. So the request is rejected.
Graph permissions
While role-based permissions represent a solid permission system already, they are not suited at all if we want to make granting permission dependant on things like the relation between the requester and the requested node. In our example, it would be quite the work to add the simple rule that any user is allowed to delete their own questions/answers.
At Graphcool, we have come up with a powerful yet rather simple approach that we call graph permissions to tackle this issue. Let's make the following additional parameters available when checking permissions:
which node is about to be accessed or modified?
determined by a node id
Then we can express permissions using a GraphQL query against a special permission schema to grant or reject permissions on a node level. Access to a given node is only given, if the permission query contains at least one leaf-node that is not null.
In our case, we could specify this permission query:
query {
allAnswers(filter:{
authorId: $userId,
id: $nodeId
}) {
id
}
}
For a given node and user specified by GraphQL variables $userId and $nodeId, we use a query argument filter to either return an empty list if the node wasn't created by the current user, or something non-null otherwise.