I have two realms, a public webapp and an extranet where only employees can access.
I have tried setting group policies.
When I try to connect with an non-employee user, keycloak still returns the access token.
What did I miss?
EDIT.
I made a mistake, I only have 2 clients.
You have to limit the access granted to your access token to achieve this. There are three ways to do it (that I know of)
Audience: Allows listing the resource providers that should accept an access token.
Roles: Through controlling what roles a client has access to, it is
possible to control what roles an application can access on behalf
of the user.
Scope: In Keycloak, scopes are created through client scopes, and an
application can only have access to a specific list of scopes.
You can look at this example which explains the flow on how to achieve this using role based method. You can refer this as well.
Related
I've become very frustrated with the landscape of API creation and authentication/authorization. I would like to find a solution that doesn't require lots of additional complexity (creating new services myself, standing up and maintaining an instance of Keycloak, and so forth) – ideally a managed service (like Auth0 ... but Auth0 doesn't meet my requirements) – that centralizes the management of users and permissions, and allows me to add attributes to users.
Some context:
Suppose you have an API that has a variety of routes:
GET /customers
GET/POST/DELETE /customers/{id}
GET /customers/{id}/orders
GET/POST/DELETE /customers/{id}/orders
You can imagine that you have a case where you have users that have read-only access, and others that can read, create and delete customers and orders. You can also imagine that you may have the need to programmatically access the API, via a service account or access token (such as with Github PATs).
This could be set up with FastAPI or some other framework, such that when a route is accessed it checks that the user, or the access token – or in essence the credentials being used to access the API – has the necessary permissions.
What would be ideal, then, is to have a system that allows me to create users, and from that system the users can – provided they have the permissions in the identity management system to do so – create machine credentials (again, like with Github PATs, but perhaps something that can generate a JWT for consistency of credentials). Users can be added to groups that provide them with roles, and therefore permissions, or they can be assigned roles directly. Ultimately, it's a system that:
Allows user creation and management
Allows users to be grouped, groups can have roles that cascade to users
Allows users to be assigned to roles directly
Allow users to create credentials for programmatic access
Does not make management of users, roles, and so forth, onerous
Allows services (such as a REST API) using these identities for authentication to get the permissions and other information associated with credentials. In the case of other information, this could be included as claims in a JWT – this would require a system that allows claims to be added programmatically to the ID token/JWT.
In my experience, the closest thing to this is Keycloak. Unfortunately, it is a decent amount of work to maintain a Keycloak instance. Still, Keycloak does not provide number 4 in the list above. Does anyone else have experience addressing this issue? I would like to avoid have to manage users and permissions myself, because I have limited resources and that isn't my area of expertise.
Similar solutions:
Keycloak – hits most of the points, except for allowing users to create machine credentials. I'd like to avoid having to set up and maintain a Keycloak instance. Not sure if I can add attributes (claims or something else) to a machine/service account JWT.
Auth0 – Hits some of these, but doesn't allow me to add attributes to machine/service account JWTs, although it will add permissions to them (but that isn't enough).
We have one realm with many users and multiple OIDC clients configured. We would like to connect another application (OIDC Client) to the realm. Unfortunately, the client cannot check for any attributes or roles to be present.
How can I configure Keycloak to authenticate with a specific OIDC-client but return failing authentication if users have not a specific role?
Generally this type of option will not work, since authorization redirects occur before you know who the user is, and therefore before you know which roles are involved.
WHAT I WOULD DO
Make an authorization redirect perform only the following job:
Signing in the user and returning the user id (sub claim), along with perhaps a couple of scopes
Then manage roles within your app - the second app should call a Web API that does this:
Get claims from the access token, and also from other sources, then use them for identification and authorization
If a user authenticates but is not entitled to use a particular app, detect this via an API call, then present an Access Denied page in the app after login.
To reach this you should implement the AuthenticatorFactory and Authenticator interfaces of Keycloak. Look here for more infos.
In the authenticate() method you will write something similar to this:
If(client == yourClient){
// Check for roles
}
Otherwise, expected behaviour in case of failure.
I am trying to understand the use of access tokens to authorize an API fronted by API Gateway.
My current understanding of the process is as follows:
After setting up a Cognito User Pool, I can define a resource server and associated scopes (e.g. https://wibble-api.com/read, https://wibble-api.com/full).
Then, I can select the allowed custom scopes for a user pool app client.
In AWS Gateway, I can create a Cognito Authorizer to authorize incoming requests.
For each AWS Gateway resource, I can go into the Method Request and select the Cognito Authorizer and determine which OAuth scopes are necessary in order to be able to execute the API method e.g. I can enter https://wibble-api.com/read, https://wibble-api.com/full to indicate that either of those two scopes are sufficient to be allowed to execute the API resource.
When using the hosted UI, the scope parameter will include all of the allowed scopes configured for that app client, and the returned access token (if using implicit grant) will contain those scopes as part of the JWT.
What I don't understand is, I have what must be a very common scenario where I want to be able to give the read-only scope to, say, a user that hasn't paid for the service, and the full scope to a user that has paid. Yet it looks like I would need to have two separate app clients if I'm going to be using the Hosted UI, because there doesn't seem to be a way to return different scopes depending on, say, what group the user has been assigned, or some other metadata in their user profile such as department, etc. I won't know what sort of user they are until after they have been authenticated, but I still need to enter the exact scope when I am authenticating. Is there a solution for this, please?
I have a question regarding Keycloak and obtaining an Access Token.
Our setup is as follows:
· users are created and maintained in Keycloak
· resources, policies and permissions are also maintained in Keycloak
Our use case is:
As a third party application, I want to obtain authorization information (e.g. resource- and scope-based permissions) for a specific user by only providing the username to Keycloak, so I can allow or prohibit further actions.
To be more specific:
In our application the need to validate each request to other services based on the access token.But we have only the user name with us.
The question is now:
> How can we obtain an access token for the user by only knowing the username ?
>
Is there a solution to obtain an access token for such a user?
You don't specify in your question if the current user is logged in. Are you validating user specific actions, or you want to retrieve user roles for the application instead?
The user is logged in and he is performing some action
I suppose you're using some keycloak adapter. Then just retrieve the session object and you should have the extra info somewhere in there.
If not, you can just parse the request yourself. When using OpenId Connect, the access token is always sent for each of the requests, in the Authorization header. The token is base64 encoded, you can decode the token yourself.
The application is performing some action for some registered user, without him logged in
User access tokens are meant to provide permissions for users. As you say in your question: As a third party application, I want... so here you are not acting as a logged user, but as an application, so you need to go with client credentials instead. Just give the client permissions to list all the users and their roles (probably it's enough with the view-users role, see the link below) and log in with client credentials grant. Then you can handle fine grained permissions in your application business logic.
See also:
Keycloak Client Credentials Flow Clarification
Keycloak spring security client credential grant
How to get Keycloak users via REST without admin account
For those who really needs to impersonate a user from a client, there is a new RFC for this : token-echange.
Keycloak loosely implement it at the time of this answer
See particularly https://www.keycloak.org/docs/latest/securing_apps/#direct-naked-impersonation
I'm trying to figure out how to use the Azure Graph API to query a user's full name (first and last) from a given username. I understand I can do this with the following Graph API call...
https://graph.windows.net/myorganization/users/{user_id}?api-version
However, I am not sure how I go about getting an access token to use with this, because this process will be called without a user logging in, which is usually how we obtain an access token.
Is there anyway I can pass a username/password to a given URL using cURL or something and obtain an access token that way, so it is done behind-the-scenes?
There are two main authentication methods which are supported by OAuth 2:
Authorization Code Grant Flow
Client Credentials Grant Flow
The first flow requires a user agent to be present to sign into the client service and results in a delegated token. The second method does not require a user to sign in, as it only authenticates using the client secret; this results in an app only token.
If you want to create a background service that captures data from the AAD Graph API, you can absolutely do this using the Client Credentials Grant Flow, which does not require a user to be present at any point during the authentication flow.
You simply need to configure your application to to have app only scopes. Read here: Permission scopes | Graph API concepts. App only scopes all require tenant administrators to consent to the application in order to get access to data.
Finally, I feel I must mention that there is another less used flow specified in the OAuth 2 spec: Resource Owner Password Credentials Grant. This flow specifies how a client application who has knowledge of a user's username and password could directly pass those parameters and get an access token on behalf of the user. However using this flow is not good practice at all.
The resource owner password credentials grant type is suitable in
cases where the resource owner has a trust relationship with the
client, such as the device operating system or a highly privileged
application. The authorization server should take special care when
enabling this grant type and only allow it when other flows are not
viable.
We support this in our V1 endpoint, but not in our new V2 endpoint. You can read this blog to learn more.