We are running some tests on Keycloak to implement it on our company and I am are wondering what is the best approach to make Keycloak interact with our legacy system.
In our scenario, we have a native login interface and we are going to use direct grant - we are not going to authorization code flow / redirect flow using a browser and we don't have any kind of social login.
The other point is: we must to keep our native interface.
Based on that, what is the best/right approach to implement this flow? I have set my client on Keycloak with direct grant but the problem is that every user must exists in Keycloak. Isn't possible to use Keycloak as a "token emissor" instead of IDP?
In case of Keycloak must be an IDP, what is the right approach to allow Keycloak log in legacy system? Should I implement a custom Identity Provider? Will mobile make a login request to Keycloak or to legacy system?
Keycloak must somehow be able to either authenticate the user or delegate the authentication of the user to a federated identity provider. A few options:
If you want to use Keycloak as an identity provider, you could do
this by migrating your user base to Keycloak, or by making use of
User Storage Federation, which means Keycloak will use your existing
user database as a source. In this case, the login interface will be
a Keycloak interface (which you can customize to your wishes). See:
https://www.keycloak.org/docs/latest/server_admin/#_user-storage-federation
Another option is to convert your legacy system into an identity
provider that complies with either the OIDC or SAML protocol, and
set it up as an identity provider for Keycloak. In this case you can
keep your existing login interface, but it will probably require
quite some changes to your legacy system. See:
https://www.keycloak.org/docs/latest/server_admin/#_identity_broker
Related
I have a setup where my application uses Keycloak (version 20.0.2) as identity provider. Keycloak allows also delegating the login to some external IdP that responds with SAML token. I'm mapping the roles in Keycloak based on attributes in the token, which works fine. However, sometimes I would like to reject access for a user (if is does not have any roles assigned) or in some more complex scenario (user can access only if he has some attribute and role combination).
What is the easiest way to do that? Do I have to write my own SPI that will handle that (what kind of SPI?)?
I'm part of a small team as a nodeJS dev and I've been tasked into researching how this can be accomplished. I'm fairly new to OAuth and authentication so please bear with me.
Currently we have a next.js webapp that uses NextAuth for authentication with the user store in DynamoDB. What we want to do is provide an Oauth2 flow so a user can consent to a 3rd party service having access to their profile information via an endpoint. In this case we are the resource server, the 3rd party is the "client" and our user is the resource owner.
The piece of the puzzle I'm trying to put together is how does Auth0 work with NextAuth in this scenario? I want Auth0 to check if the user is logged in (otherwise prompting them to do so) via NextAuth, and for NextAuth to say "this is fine" and then for Auth0 to issue a token to the 3rd party (concluding a "normal" OAuth flow). Is this were SAML comes into play? I see there's a software package called SAML Jackson (lol) and there's a Next-auth integration for it.
Most examples I see usually work the other way around, with Auth0 as the identity provider, and what we're doing may be unique. Sorry if this question comes across as abstract but that's how it exists in my mind currently. Any help understanding this would be greatly appreciated.
You can connect your user store to Auth0 as a custom database connection. And then create an application inside Auth0 and enable the DB connection for the app. This way Auth0 acts as the Authorization server for your client app.
NextAuth.js is just an authentication library that supports the OAuth2.0/OpenID protocols. The role of NextAuth is simply to initiate the authentication flow, take the user to the Identity Provider (in this case Auth0 backed by a custom user store) and finally process the authorization response from Auth0. The authorization response (code) is received at the application end and then exchanged for access_token and user profile (all handled by NextAuth.js).
And for your query on SAML, it's a standard for exchanging identity information between two parties an Identity Provider (IdP) and a service provider (SP). The same is achieved by its more modern counterparts OAuth2.0/OpenID Connect. Typically third-party apps which are deployed in an enterprise setting use SAML to integrate with on-premise Identity Management Systems like ActiveDirectory. You can read more about SAML on https://boxyhq.com/blog/understanding-saml-sso-the-basics-from-the-user-side.
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.
We're planning integration between two services: A and B.
The service A is going to be an OpenID Provider, the service B relies on it to log users in and create new accounts.
The service A also provides access to its resources via REST API using OAuth authorization, the service B uses the OAuth Access Token obtained via OpenID Authorization Code Flow.
However, there are some cases when A wants to get data from B. There is an established agreement between these services, that A can access any data from B in the scope of a user that was created via OpenID Connect.
How could I design authorization for the service B API? What could A provide to B in an HTTP request?
I'm considering things like a classic API Key, but it doesn't look natural in this workflow.
There are no direct solution to your mentioned scenario from OAuth and OpenID Connect protocol perspective.
But from what you have explained, you have OAuth 2.0 access token protected services in service A. Also, A acts as an identity provider (with OpenID Connect support). If this the case, I believe you control token issuing process and validations.
One options is to enable services from B , which are protected from OAuth 2.0 access tokens. Which is similar to what you already have in A. And to consume those services, you will have some service/client implementations bound to A. What they would do is obtain tokens from A itself to communicate with B. This can follow client credential grant from OAuth 2.0 as there is no end user involvement (scenario involve service to service interaction).
This suggested solution is similar to API key usage but with added benefit of OAuth 2.0 protocol.This allows you to generate Access tokens with limited life time and allow refreshing them if required. Also, in case you want B's services to be consumed by another client, then things are straightforward.
We have a working REST API which uses OAuth2 password grant (for access through our own Web UI) and client credentials grant (for scripted access), and may allow other grants in the future.
Recently a request came up to support 3rd party Single Sign On through OpenId Connect (so we can support identity providers such as Google and LinkedIn, but also some of our client's internal SSO systems that support OpenId Connect.
I'm trying to understand how to integrate the OpenId Connect flow into our existing authentication, authorization and identity management architecture.
One important thing is our system still needs to control authorization and access token grants and expiry. We just want to allow 3rd party authentication and identity management as an option, from a selected (but flexible) list of providers. Basically the way I see it, OpenId Connect can, optionally, replace the password grant for some users.
Can anyone recommend a guide or a reference implementation for such setup? Am I trying to do something that doesn't make sense?
EDIT: By "existing architecture" I mean our own existing user database, which supports email / password based authentication (that using OAuth2 password grant). We want to maintain this DB / authentication flow but also allow 3rd party OpenId Connect based authentication.