3.0

[ferrerojosh]

A few ideas that may come up in the next major version:

- [ ] Multi-tenancy support (moved to 1.8.0 release)

• Create permissions
• Create policies and map them to resources, permissions, etc.
• WebSocket support
• Annotation API Overhaul

I'll slowly add more that I can think of.

I think the idea is that you can programmatically create (or say generate) them using the library without manually configuring it inside the Keycloak admin portal.

Feel free to give ideas. As I'll slowly add them since I can only work on this when I have free time.

[EFritzsche90]

I was thinking about multi tenancy support. In this case we can also call it multi realm support. My use case it, that I want to support different customers with only one Keycloak by using one realm per customer. My nest service should handle data depending on the realm/tenant. It would mean, that we cannot configure the module like now, but have some way to change it on runtime per request.

What do you think?

I would also support your ideas. I would also like to create my clients on startup, so that I can handle the client secret (also per tenant). This would be the best approach for a dynamic backend setup within a Microservice architecture.

[ferrerojosh]

I was thinking about multi tenancy support. In this case we can also call it multi realm support. My use case it, that I want to support different customers with only one Keycloak by using one realm per customer. My nest service should handle data depending on the realm/tenant. It would mean, that we cannot configure the module like now, but have some way to change it on runtime per request.

What do you think?

I would also support your ideas. I would also like to create my clients on startup, so that I can handle the client secret (also per tenant). This would be the best approach for a dynamic backend setup within a Microservice architecture.

This seems to be a great idea, I didn't think about creating the client on start-up, as dangerous as it sounds, it requires a realm
master account which is useful for use-cases like this.

For multi-realm support, at its core, this library is an adapter to keycloak-connect. This can be currently done by having different Keycloak module per Nest module (by not having it global since it isn't required to simply put it in your root module).

As for changing the current configured realm on runtime, I'll think of some way but it'll probably be hacky like changing the internal keycloak instance, which could probably cause some issues and I myself wouldn't recommend it. I still prefer the 1 realm per module approach, as I stated above.

[EFritzsche90]

I was thinking about multi tenancy support. In this case we can also call it multi realm support. My use case it, that I want to support different customers with only one Keycloak by using one realm per customer. My nest service should handle data depending on the realm/tenant. It would mean, that we cannot configure the module like now, but have some way to change it on runtime per request.
What do you think?
I would also support your ideas. I would also like to create my clients on startup, so that I can handle the client secret (also per tenant). This would be the best approach for a dynamic backend setup within a Microservice architecture.

This seems to be a great idea, I didn't think about creating the client on start-up, as dangerous as it sounds, it requires a realm
master account which is useful for use-cases like this.

For multi-realm support, at its core, this library is an adapter to keycloak-connect. This can be currently done by having different Keycloak module per Nest module (by not having it global since it isn't required to simply put it in your root module).

As for changing the current configured realm on runtime, I'll think of some way but it'll probably be hacky like changing the internal keycloak instance, which could probably cause some issues and I myself wouldn't recommend it. I still prefer the 1 realm per module approach, as I stated above.

Yep, this master account will be needed, but it will give you some flexibility, especially when working with Microservices and flexible architectures, i.E. when you want to add a new service to a customer environment you do not need to manually add its configuration to Keycloak, but the service is responsible on his own. It will be easier to deploy those services automatically.

Mutli-realm support has to be done dynamically. When there is a running environment on the cloud and I want to add a new customer, I do not want to make code changes. I just want to press a button and there is a new customer realm and all clients of each service are created. By doing it with modules would remove such possibilities. But I am open for other solutions. :D

Edit: There is already this project for node applications, which implements most of the Keycloak API: https://github.com/keycloak/keycloak-nodejs-admin-client
I think it is important to support the token and grant validation for multiple realms. Setting up Keycloak can be done by using this module.

[ferrerojosh]

I was thinking about multi tenancy support. In this case we can also call it multi realm support. My use case it, that I want to support different customers with only one Keycloak by using one realm per customer. My nest service should handle data depending on the realm/tenant. It would mean, that we cannot configure the module like now, but have some way to change it on runtime per request.
What do you think?
I would also support your ideas. I would also like to create my clients on startup, so that I can handle the client secret (also per tenant). This would be the best approach for a dynamic backend setup within a Microservice architecture.

This seems to be a great idea, I didn't think about creating the client on start-up, as dangerous as it sounds, it requires a realm
master account which is useful for use-cases like this.
For multi-realm support, at its core, this library is an adapter to keycloak-connect. This can be currently done by having different Keycloak module per Nest module (by not having it global since it isn't required to simply put it in your root module).
As for changing the current configured realm on runtime, I'll think of some way but it'll probably be hacky like changing the internal keycloak instance, which could probably cause some issues and I myself wouldn't recommend it. I still prefer the 1 realm per module approach, as I stated above.

Yep, this master account will be needed, but it will give you some flexibility, especially when working with Microservices and flexible architectures, i.E. when you want to add a new service to a customer environment you do not need to manually add its configuration to Keycloak, but the service is responsible on his own. It will be easier to deploy those services automatically.

Mutli-realm support has to be done dynamically. When there is a running environment on the cloud and I want to add a new customer, I do not want to make code changes. I just want to press a button and there is a new customer realm and all clients of each service are created. By doing it with modules would remove such possibilities. But I am open for other solutions. :D

Edit: There is already this project for node applications, which implements most of the Keycloak API: https://github.com/keycloak/keycloak-nodejs-admin-client
I think it is important to support the token and grant validation for multiple realms. Setting up Keycloak can be done by using this module.

Well all I can think of is an API gateway with different instances behind each endpoint but that is just one of the solutions. I'm still thinking of a clean way for changing realms on runtime. If it's changing realms every endpoint call, I'd need to investigate how much chaos will it create and if possible use a pseudo thread local behavior using continuation local storage just to fix the issues that might revolve around it.

[EFritzsche90]

I found following issue for Keycloak NodeJS: https://issues.redhat.com/browse/KEYCLOAK-4162
Might be helpful.

[jalorenz]

@ferrerojosh Hey, is there any chance of creating specialized issues for each bullet point? I think it would be better to not discuss all bullet points in one conversation.

[ferrerojosh]

@ferrerojosh Hey, is there any chance of creating specialized issues for each bullet point? I think it would be better to not discuss all bullet points in one conversation.

I'll do that once I start development so I can track them correctly in commits, for now I put this up to summarize what 2.0 should be, feel free to open a new issue if its going to be a lengthy discussion.

[smolinari]

One can do multi-tenancy without doing a realm per customer by using groups. (theoretical on my part as it's only what I've learned from my research). Also AFAIK, it is even suggested that doing multi-tenancy with realms is an overall bad idea for the sake of Keycloak's performance (with 100s and 100s of realms, Keycloak will dog down).

The only reason you might want to do a different realm per customer/ tenant is to offer them the abilities of having their own user federation system (i.e. LDAP, Active Directory, Kerberos, etc.) or different identity providers (i.e. Facebook, Google, Github and co.), and IMHO, if your application is going to be that complicated, having it all run off of one Nest app will become a veritable nightmare.

Just adding 2 cents to the discussion from my humble point of view, as I'd like to also do multi-tenancy with Keycloak, but don't see it happening in a single Nest app and for sure not with dynamic realm changes and all of the prior setup needed to make requests of different tenants a possibility. That would be like putting a ball and chain on Nest as I see it. I'm going the direction of a Nest app per customer/ tenant with containerization. It will make the infrastructure more complex (i.e. needing something like a k8s environment), but will help keep the apps themselves much more simpler.

Scott

[EFritzsche90]

One can do multi-tenancy without doing a realm per customer by using groups. (theoretical on my part as it's only what I've learned from my research). Also AFAIK, it is even suggested that doing multi-tenancy with realms is an overall bad idea for the sake of Keycloak's performance (with 100s and 100s of realms, Keycloak will dog down).

The only reason you might want to do a different realm per customer/ tenant is to offer them the abilities of having their own user federation system (i.e. LDAP, Active Directory, Kerberos, etc.) or different identity providers (i.e. Facebook, Google, Github and co.), and IMHO, if your application is going to be that complicated, having it all run off of one Nest app will become a veritable nightmare.

Just adding 2 cents to the discussion from my humble point of view, as I'd like to also do multi-tenancy with Keycloak, but don't see it happening in a single Nest app and for sure not with dynamic realm changes and all of the prior setup needed to make requests of different tenants a possibility. That would be like putting a ball and chain on Nest as I see it. I'm going the direction of a Nest app per customer/ tenant with containerization. It will make the infrastructure more complex (i.e. needing something like a k8s environment), but will help keep the apps themselves much more simpler.

Scott

Hi Scott,

there are a lot of things in your post I would agree, but exactly the reason you have mentioned as only reason where it might make sense is my use case. :D
Of course you can solve it by infrastructure, but in the end the whole solution should be somehow economically. Having a complete installation for each customer would blow up the costs of my infrastructure (already running in K8s). There are customers with only 10 users. They will never pay the amount of money I need to make some profit. For that reason, I would like to put all these small customers to one shared installation.
I hope you got my point. :D

I am happy for other solutions. ;)

[smolinari]

@EFritzsche90 - What is it you are considering "too expensive"? You'd only need a single pod per customer (and obviously not having some sort of High Availability SLA), which costs, depending on your nodes, say a 100th of the node cost to run (assuming you can get 100 pods running on a node, which should be doable even with a moderate node). So, if a node costs $100 to run a month, and that would be a decent sized node, the customer costs for their "app pod" would be $1. Of course, you'd need 100 customers to fill the node to cover costs ( and I know I'm making the calculation pretty naive, but you hopefully get the point). Everything else, traffic, storage, etc. would be the same extra costs anyway, right?

In my research, the real cost point comes from the database/app data storage, IF you intend to have a database per customer. For this I have a solution, which I still need to build. But, basically, it's a database sharing scheme for small/ demo customers, and still with a pod per customer, so even offering a free tier for experimentation.

But, this has nothing to do with scaling Nest apps for multi-tenancy and using Keycloak in parallel. 😁

@ferrerojosh - Sorry for the off-topic. A small suggestion, but how about opening up Discussions on this repo, so such things can be taken there? 😃

[ferrerojosh]

I have decided to move most of the stuff I listed here to 3.0 release, because I'll have breaking changes soon due to the removal of the custom logger.

Moving forward to 2.0, I'll be fixing most pending issues in that major release.