All of the following options leak all your accounts CloudWatch data.
1. Sharing dashboards via AWS console
Warning
All people who you share the dashboard with are granted the permissions listed in Permissions that are granted to people who you share the dashboard with for the account. If you share the dashboard publicly, then everyone who has the link to the dashboard has these permissions.
The cloudwatch:GetMetricData and ec2:DescribeTags permissions cannot be scoped down to specific metrics or EC2 instances, so the people with access to the dashboard can query all CloudWatch metrics and the names and tags of all EC2 instances in the account.
Reference: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-dashboard-sharing.html
2. Adding CloudWatch datasource to Grafana and permit user access to the dashboards in scope only
For example: In a Grafana instance with one data source, one dashboard, and one panel that has one query defined, you might assume that a Viewer can only see the result of the query defined in that panel. Actually, the Viewer has access to send any query to the data source. With a command-line tool like curl (there are lots of tools for this), the Viewer can make their own query to the data source and potentially access sensitive data.
Reference: https://grafana.com/docs/grafana/latest/administration/security/
3. Cross account sharing
Same problem arises that all accounts CloudWatch data is being shared.
Reference: https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html
Cumbersome approach:
Build a backend service that fetches the dashboard relevant data and exposes it in a format that can be read by Grafana. Afterwards one still has to build a dashboard based on that data. Is there an easier way?
We are working with keycloak, In our application, we have different organizations and we created different realms for each organization in keycloak too.
Our requirement is each realm admin need to manage their users and roles (create the user and assign roles etc), but role creation should be restricted. Is there any possible solution to do this?
Please let know the answers to flowing questions,
1 Is there any possibility to inherit/share/copy the User Federation from the Master realm to any other? if not then what is the best practice to handle these types of requirements.
2 Is any options to disable some administration for realms (for Example, role creation need to block from realms except master)
Please see some similar questions
Inherit/Share User Federation in Keycloak
https://keycloak.discourse.group/t/shared-realms-configuration/3642
Thank you
I have 2 users, one with less than 30 roles and one with 400 roles. When I login with the 30 role user, I can reach the redirect URL without issues. But when I log in with the 400 role user, the request to the redirect URL doesn't complete. If I reduce the number of roles in the 400 role user then it will work. So, is there a way to disable passing roles in the java access token or increase some limit somewhere that's causing the failure?
I would suggest to focus rather on roles reduction/optimization than forcing the transmission (raising limits) over the maximum number of roles inside tokens (or anywhere else).
Some interesting questions (among others) to start with:
Which protected resources am I going to serve?
What am I trying to protect? and what are the associated risks? (build a Threat Model)
How do resources are served by each application? and how are they distributed among my applications?
What kind of resources are they? How can I group them? Which sets are identifiable? or what are the relationships between them? What actions are possible against all sets of resources?
Who are the users of each application? How will they interact with my resources? Which flows are sensitive?
What roles can I define for all my resources?
Which role can apply to each application, resource type or set?
What kind of user groups can I create?
Do I need additional attributes or claims for each set of roles or users/groups?
I firmly believe that if you answer all these questions you will end up having a bunch of roles instead of hundreds. Think security by design and follow principle of least privilege.
Focus on your use case
Now as far as I understand, your blocking point is that you are assuming that each resource is unique, sensitive and requires its own permissions, and consequently a role definition. While it may be true in some cases, in most other cases it does not mean that you have to use the token roles/scopes/claims to secure your assets deep at the resource-level. I'll try to illustrate this sentence by an example.
RBAC and authorizations example for your use case
Let's assume that:
you have millions of sensitive resources to serve
each registered user of your application has access to a (different) set of these resources.
your resources are splitted into, say, 3 categories (e-books, videos, musics).
each resource can be downloaded, uploaded, deleted.
your application will meet unregistered users, registered users, contributors and administrators
registered users will always have read access to resources (not a single action will ever allow a modification)
contributors are particular registered users who can perform special actions including modification ('upload', 'edit')
contributors and administrators may have access to various administrative parts of the application
your application will evolve by serving additional categories of resources in the future and new actions will be available to users later (such as 'flag', 'edit' or 'share link').
Then first things first:
organize your resources accordingly by serving them behind categorized paths such as: .../myapp/res/ebooks, .../myapp/res/videos, .../myapp/res/musics
identify your resources via UUID such that a resource may look like: .../myapp/res/ebooks/duz7327abdhgsd95a
Now imagine that your business risks or at least the greatest risks you wish to avoid are:
unregistered users having gaining access or rights for any part of the application or resource
uncontrolled registration process (robots, spam, no mail verification, fake users, ...)
registered users gaining illegal privileges (unauthorized actions, access to other categories, illegal administrative rights)
discovery of available resources by any mean
You will note that I voluntarily didn't listed:
registered user having illegal access to certain resources. For example: maliciously pointed/provided by an existing user.
This is because it is not a high risk as you may hold contact information about registered users as well as log activity and actions, quota or requests throttling, and you may be able to ban them or start legal action against them. Your registration process is also assumed robust and secure. Nonetheless if its considered a critical risk you can address this with extra mechanisms (cf. suggestions at the end). But never will it result in adding extra roles, such as one per resource, as it does not fit in any security model.
That being said, finally, here are the roles and authorizations scheme you may come with:
SCOPE / AUDIENCE
MY_APP
ROLES
USER
CONTRIBUTOR
ADMINISTRATOR
CLAIMS / ATTRIBUTES
CATEGORIES
ACTIONS
--> POSSIBLE USER GROUPS
USERS
Roles: USER
Claims: CATEGORIES(variable), ACTIONS('download')
CONTRIBUTORS
Roles: USER, CONTRIBUTOR
Claims: CATERGORIES(variable), ACTIONS('download', 'upload', 'edit')
ADMINISTRATORS
Roles: USER, CONTRIBUTOR, ADMINISTRATOR
Claims: CATEGORIES(*), ACTIONS(*)
Following this model, assigning the correct group to each registered user will provide high-grade security by mitigating/controlling the main risks. As claims/attributes are defined in the token(s) (managed and signed by Keycloak) then you can trust this information in your application and serve your resources accordingly and safely. There is also no risk of illegal access or discovery of resources as you are using UUIDs, only registered users having had access once to a resource will know it and registration with appropriate category access will be needed for another user to access it (to only be able to read it basically). Of course you may store in a database the list of resources to which each user has access to, raising the overall security to a very high level.
However, if the latest is not enough you may also implement rolling UUIDs or temporary links for your resources when served to users. To go farther you may also define groups and masks for your categories, resources and actions.
In fine, in this example I made use exclusively of token claims to define roles (common claim), categories and actions (custom claims). In terms of security the authentication and identity will be the first-line security followed by roles then categories, actions and stored list of resources per user (db).
Other alternatives are obviously possible, its just an example. Still, I hope it helps!
To fix this problem you should start from defining client scope mappings for each of you applications (e.g. oidc clients). Main idea of this facility is that even if your user is super duper admin with all existing roles, all of his roles actually don't required for any particular application. For example client foo which defines following roles:
foo_user
foo_viewer
to perform its security logic need to know only whether currently logged user has foo_user or foo_viewer, but it doesn't care about has this user roles bar_user or bar_admin from application bar. So our goal is to make Keycloak return for any client access token with only valuable set of roles for this client. And roles scope mappings is you friend here. You can set for client foo scope like:
foo.foo_user
foo.foo_viewer
bar.bar_admin
and now even if logged user has role "bar.bar_admin" this will not go to access_token since client foo doesn't take this role into account. After applying some scope settings you can test them at 'Clients -> $CLIENT_OIDC_ID -> Client scopes tab -> Evaluate sub tab.
As for you case with 400 roles, i'm quite confident that none of your application requires all of 400 roles, so precise scope configuration for you apllications can drammatically reduce access token size.
But if i'm mistaken and you really have an application that rely on large amount of roles you should look into you runtime settings.
For example if you run keycloak behind reverse proxy like nginx large tokens may not fit in default HTTP parameters buffer size (afaik about 2-4kb) so you have to increase it via appropriate nginx configuration option. Another example is tomcat which has about 16kb as default HTTP header buffer, so if you send request with very large access token in Authorization header Tomcat may not handle this request properly.
use case
in icCube
one server instance
icCube users only need to access the reporting
icCube is used to for a standard reporting solution for an industry vertical and can be used by multiple clients, each having their own (copy of the) structures that work with their own data
a client can grant one or more users access to their own dashboards in icCube
authorization requirement
it should be possible to link authorization to the client's identity
management system (such as AD)
for others, it should be possible to assign a local admin at the client that can give access to their own environment to whom they wih
for the rest, it should be possible for a centralized admin to maintain access
a perfect job for ...
keycloak
keycloak needs for each of the requirements a seperate realm with client (see picture)
The icCube documentation only makes mention of one Realm & client.
the question
Is it possible to use multiple keycloak realms & clients with one instance of icCube?
See also icCube documentation on keycloak integration
Right now this is not possible.
The keycloak.json file is used to connect to a Keycloak server that is going to authenticate the HTTP request. So you would need somehow a way to determine which keycloak.json file to use based on the HTTP request before using it meaning having different URL and/or URLs with a specific parameter.
Possibly the multi-tenant support could be extended to be able to configure an authentication logic per tenant with the same constraint about the URL value.
Hope that helps.
I have developed a web application with following architecture:
Frontend : Angular 6
Backend : Java REST APIs with Springboot
I want to add authentication and authorization to it. For that I'm looking for some open source application (e.g. KeyCloak, Gluu etc.). I would like to know in which tool the below scenarios are supported.
There will be predefined set of Activities on UI (e.g. Add, Edit,
Delete etc)
There will be predefined Access Levels (e.g. Read, Write, No Access)
I should be able to create Roles, then assign activities and access levels to those roles and assign those roles to user.
Can you please help me to find out a tool which supports my above scenario?
I tried something for KeyCloak, but i couldn't find a way to add activities, access levels and map roles to it. I think everything there is governed by Role only.
I just realized that I need Activity based authorization and not Role based authorization. Please help me find some tool for that.
I'm not sure what is meant by activity based authorization but i suspect you actually mean permission based authorization, in example: Grant permissions to users to perform certain actions.
Shiro offers you permissions and role based authorization out of the box.
You can create roles, add permissions to these roles and assign them to a user. Supported are implicit and explicit roles, whereas one role can hold any number of permissions. You can even work with wildcards and group the permissions.
For more information you should take a look at the official Shiro entry and especially the web documentation for your project in particular. Shiro offers full support for Spring-Boot applications, you can find a HowTo here.
Shiro fully supports your described scenario.