I recently used keycloak as an authorisation server for my application that manipulate some kind of workspaces, so i created a resource in keycloak for each workspace and assigned users to it using keycloak console administration.
i wonder if there is a some kind of endpoint in keycloak API or another way to get the number of users assigned to a resource.
Related
I am using Keycloak 18.0 for Angular 13 + Spring Boot App. The solution utilizes Microservices architecture pattern for this app so basically Keycloak already guards access to other solution resources. I am using only Keycloak REST API.
The problem is Keycloak security itself:
I want to restrict Keycloak client token only to user creation.
Any user has to be able:
1. Fully access and manage ONLY his own profile.
2. Has restricted access to profiles of other users.
3. Any other operation of viewing other users, adjusting
roles etc. should be enabled only if authenticated user
has some kind of permission to do it.
For example:
Anybody can create user (signup).
After user is verified, some role is assigned to that user.
User logs in and acquire its token that has permissions to fully manage only his own resources including user itself and has restricted access to other users and user resources.
I am not sure I want to integrate Keycloak as resource security manager (i am considering that option but for now, only Spring Boot Adapter was implemented to control corresponding resources security) but at least i would like to prevent e.g. reading full list of users using Keycloak client token.
I have basic understanding of Keycloak Resource/Policy/Permission Feature but I am not sure i understand how can i apply it to Keycloak users itself.
Thanks a lot in advance for your help.
I have configured a custom SAML app in Google Workspace and configured AWS Opensearch to use SP-initiated SSO.
I am able to access OpenSearch via the URL but I get the following error
Missing Role
No roles available for this user, please contact your system administrator.
I guess there are some SAML attribute mapping and group set up that are required. I've created an opensearch group in Google for users that I wish to have access.
I think the following AWS Opensearch parameters require a value
SAML master backend role
Subject key
Roles key
From what I can see, the issue is that you need to create a custom attribute inside the Admin console of Google Workspace with the "roles" for AWS Opensearch.
You can also read this information in the AWS documentation.
This was resolved using and IdP initiated authentication flow instead. The links posted in answers above helped us implement this.
I want to create base authentication in kubernetes. every document say that I should create CSV or file then enter the username and password in it. but I do not want to use file I want to some database or kubernetes handle it.
what can I do for base authentication?
You can based your authentication on tokens if you don't want to use static pasword file.
First option:
Service Account Tokens
A service account is an automatically enabled authenticator that uses signed bearer tokens to verify requests.
The plugin uses two flags(which are optional):
Service accounts are usually created automatically by the API server and associated with pods running in the cluster through the ServiceAccount Admission Controller. Bearer tokens are mounted into pods at well-known locations, and allow in-cluster processes to talk to the API server. Accounts may be explicitly associated with pods using the serviceAccountName field of a PodSpec.
Service account bearer tokens are perfectly valid to use outside the cluster and can be used to create identities for long standing jobs that wish to talk to the Kubernetes API. To manually create a service account, simply use the kubectl create serviceaccount (NAME) command. This creates a service account in the current namespace and an associated secret.
The created secret holds the public CA of the API server and a signed JSON Web Token (JWT).
The signed JWT can be used as a bearer token to authenticate as the given service account. See above for how the token is included in a request. Normally these secrets are mounted into pods for in-cluster access to the API server, but can be used from outside the cluster as well.
There is some drawbacks because service account tokens are stored in secrets, any user with read access to those secrets can authenticate as the service account. Be careful when granting permissions to service accounts and read capabilities for secrets.
Second:
Install OpenID Connect (full documentation you can find here: oidc).
OpenID Connect (OIDC) is a superset of OAuth2 supported by some service providers, notably Azure Active Directory, Salesforce, and Google. The protocol’s main addition on top of OAuth2 is a field returned with the access token called an ID Token. This token is a JSON Web Token (JWT) with well known fields, such as a user’s email, signed by the server.
To identify the user, the authenticator uses the id_token (not the access_token) from the OAuth2 token response as a bearer token.
Since all of the data needed to validate who you are is in the id_token, Kubernetes doesn’t need to “phone home” to the identity provider. In a model where every request is stateless this provides a very scalable solution for authentication.
Kubernetes has no “web interface” to trigger the authentication process. There is no browser or interface to collect credentials which is why you need to authenticate to your identity provider first.
There’s no easy way to authenticate to the Kubernetes dashboard without using the kubectl proxy command or a reverse proxy that injects the id_token.
More information you can find here: kubernetes-authentication.
I followed the steps mentioned in the below WSO2 documentation to use WSO2 IS as an Identity Server with WSO2 APIM.
I use WSO2 IS 5.3.0 and WSO2 APIM 2.1.0.
https://docs.wso2.com/display/AM210/Configuring+WSO2+Identity+Server+as+a+Key+Manager
I am able to access the carbon admin console in both the WSO2 IS and WSO2 APIM (in two ports)
https://localhost:9443/carbon/admin/login.jsp
https://localhost:9444/carbon/admin/login.jsp
When I use WSO2 IS console (9443) to change the user roles, most of the times it is getting reflected immediately, using the same access token. How can it be possible ? An access token is provided by WSO2 with some pre configured scopes. Within the same login session, even before the access token expires, If we change the roles of the logged in user, the roles changes are applied immediately and my access rights are changed ? Is it a valid ?
Assume a user "USER1" got an access token with privileged rights and he/she is able to access privileged APIs. Suddenly if the roles are changed and user "USER1" is assigned a normal user rights, and the user is not able to access the privileged APIs within the same login session. Is this how OAuth works ?
Please help me understand.
If I change the roles in WSO2 APIM (9444), the roles are not getting reflected immediately. Some times, it wait for the access token to expire and the gets a new access token. Sometimes, role changes are getting applied even before the access token expire.
What is the synchronization interval between WSO2 IS and WSO2 APIM, to sync the roles?
I couldn't find these roles in mysql db or ldap. Where are they stored in the backend ?
There are differences in IS as a key manager and the inbuilt key manager of API Manager. The key manager comes with API Manager is not a full fledged Identity solution. Hence its role to scope mapping, access control, etc. are somewhat limited in the point of view of Identity Management aspects.
Identity server acting as a key manager provides the full access control mechanism, hence the change in the role should affect fast as possible, even for issues keys. This is one of the reasons of using IS as a key manager.
Question 1
Ans:
Lets say a user has an admin right when he got the access token. The enterprise may decide the user has no longer needs this right and changes that on their LDAP. It should be reflected on key validation as fast as possible. Otherwise the user has continued access to the service as privileged user until key expires, which is undesirable. So the behavior is valid.
Question 2
Ans: Yes, API Manager is strong on managing APIs. However, it is not a use/role management system. Hence there will be considerable delay in reflecting the role change. So, make sure you use IS to manage the user/roles, etc. when your API Manager is configured with IS.
Where is your configured roles
It should be in WSO2UM_DB configured (UM_ROLE table), if JDBC user store is your primary UserStore.
We are considering to use the keycloak as our SSO framework.
According to the keycloak documentation for multi-tenancy support the application server should hold all the keycloak.json authentication files, the way to acquire those files is from the keycloak admin, is there a way to get them dynamically via API ? or at least to get the realm public key ? we would like to avoid to manually add this file for each realm to the application server (to avoid downtime, etc).
Another multi-tenancy related question - according to the documentation the same clients should be created for each realm, so if I have 100 realms and 10 clients, I should define the same 10 clients 100 times ? is there an alternative ?
One of our flows is backend micro-service that should be authenticated against an application (defined as keycloak client), we would like to avoid keeping user/psw on the server for security reasons, is there a way that an admin can acquire a token and place it manually on the server file system for that micro service ? is there a option to generate this token in the keycloak UI ?
Thanks in advance.
All Keycloak functionality is available via the admin REST API, so you can automate this. The realm's public key is available via http://localhost:8080/auth/realms/{realm}/
A realm for each tenant will give a tenant-specific login page. Therefore this is the way to go - 10 clients registered 100 times. See more in the chapter Client Registration of the Keycloak documentation. If you don't need specific themes, you can opt to put everything in one realm, but you will lose a lot of flexibility on that path.
If your backend micro service should appear like one (technical) user, you can issue an offline token that doesn't expire. This is the online documentation for offline tokens. Currently there is no admin functionality to retrieve an offline token for a user by an admin. You'll need to build this yourself. An admin can later revoke offline tokens using the given admin API.