I am new to Keycloak. I was working on auth0 and in auth0 we have rules (part of the authentication pipeline). In rules, we could have custom Javascript files and code needed to complete the process.
https://auth0.com/docs/customize/rules
so is there anything in the keycloak that will provide the same functionality?
See Protocols Mappers - there is many types of mappers and of them is Script mapper, where you can script some additional functionality.
Related
The API Gateway handles the token validation and then routes it to the appropriate service.
similar situation is described here.
I want to use a javax.annotation.security.RolesAllowed annotation (Secured or similar) to protect easily endpoints with role-based rules. Just to confirm if the already validated JWT token has the required role for the specific endpoint.
Without activating security in the Micronaut that annotation doesn't work. Is any way to make it work and not make an additional validation on the service side? Unfortunately, I couldn't find any nice solution.
Background information: The REST API will be used by a web application and server
We are thinking to have the code flow for the web application and client credential flow for the server part (machine to machine authentication). As tool, we will be using keycloak
But the problem is now that we are not sure if it is possible to have two oauth flow on one REST API.
Is it possible to have two oauth flow for one REST API?
And if it's possible, how can you do it?
This is fine. In both cases the clients will perform OAuth flows using Keycloak, and these can be completely different. Your API needs to knows nothing about how clients authenticated, and in both cases receives a JWT access token.
The two different clients will not always call the same API endpoints. They are likely to use different scopes and claims, and your API authorization design needs to deal with this. The server client will not provide a user identity via a subject claim, whereas the web app will.
The way to cope with these differences is usually to design a ClaimsPrincipal during JWT processing, then apply authorization rules based on the data received within the API's business logic.
In some cases, operations designed for the server client should not be callable from the web app, and vice versa. Scopes and claims will enable you to achieve this.
EXAMPLE API
Maybe have a look at this code sample of mine and the blog post. The key point is that the API performs these steps. If you do the same steps you will be in good shape:
Validates JWT access tokens
Builds a claims principal
Enforces scopes for each operation
Uses the claims principal to apply business authorization rules
My API does some slightly advanced stuff like look up extra claims, which you can ignore. Note that the API doesn't know or care which flow clients used - there could be 5 different flows. The API's job is just to work with scopes and claims.
I am trying to integrate a legacy OAuth 2.0 provider which does not support OpenID Connect 1.0 as identity provider on Keycloak.
This legacy provider provides a xml service that returns the user details similar to userinfo.
I see that Keycloak has the concept of social providers but I can’t find any resources of how to implement and register on GUI a new one.
Here is the part of the documentation in Keycloak that is referring to this sort of providers: Identity Brokering APIs.
I also suggest you to take a look at the source code of some custom providers implemented as Keycloak extensions. That can be quite helpful.
Implementing a custom identity provider is typically not a straightforward task and there will be a lot of edge cases and unpredictable scenarios. If your Keycloak server can have access to the database of your identity provider (e.g. via a readonly view) then it would be much easier to just implement a custom UserStorageProvider that fetches users for Keycloak. All the other stuff will be handled by Keycloak itself. Then you can also have some custom mappers that fetch those user attributes and allowing you to put them inside tokens.
I am using AWS AppSync with keycloak as the OIDC provider and left the clientID blanked. This means that I can generate an access token using any clientId and client secret and start making requests (query or mutation) to my AppSync GraphQL endpoint.
However, I have to ask...how do I define fine grained access control with the scopes in the jwt token. I don't really understand what benefit this authorisation flow provides apart from just leveraging existing clients previously setup in keycloak or any other oidc providers.
So...what's the real benefit of using oidc auth for AppSync? Am I missing anything important here? Any feedback appreciated!
Thankyou!
You get access to the OIDC claims in the $ctx.identity.claims map within the resolver mapping templates which you can basically use to do your fine grained access control logic. Imagine if you have a groups claim meaning your user belongs to a group such as Admin then you can write custom logic in your mapping template based on that.
Here is an example of how to do this (it uses Cognito but OIDC should be pretty similar).
https://adrianhall.github.io/cloud/2018/06/01/how-developers-can-auth-with-aws-appsync/
I have a Django backend which will be served as my API endpoints. Users are identified by username and password and have some extra information and should be able to consume my same API, so I want to grant tokens for them.
How to create API keys for them to use? (Would a uuid serve a good purpose here?)
How to generate tokens for them? (I could imagine that some way like sha256(api_key + password + some_salt), where salt is some timestamp object would do the trick and also help in expiration)
How to generate a refresh token to be used for refreshing an expired token? (I have no idea here)
I took a look at Oauth 2.0 but TBH I could not figure it out completely and it is overly complicated as my API server will also be my authentication server.
I would not recommend to build your own authentication scheme, nor deploy your own cryptographic functions. Nowadays the industry standard for API authentication and authorization is OAuth 2.0, it provides all the requirements you've described in a robust but rather simple to implement solution.
If the mentioned application does not require any of the OAuth 2.0 authorization concepts, using OpenID Connect is certainly a great approach. OpenID Connect is a protocol built on top of OAuth 2.0:
It allows Clients to verify the identity of the End-User based on the
authentication performed by an Authorization Server, as well as to
obtain basic profile information about the End-User in an
interoperable and REST-like manner.
API authentication technologies are widely available in different forms, even SAML 2.0 can be implemented for such scenarios (more infrastructure is required), anyhow for what you have described, OpenID Connect certainly cover all requirements.
The easiest way to solve this is a classical Session-Cookie, Django directly offers this functionality.
If you do not want to hold state on the server side you may look into JSON Web Tokens.