[keycloak-user] Is KC a good fit for your business case?

Fri May 27 02:04:52 EDT 2016

I'm not sure what type of documentation you have in mind, but one thought
we had in the past was to create blueprints for various architectures.
Correct me if I'm wrong, but I wouldn't think a SaaS application like this
would be that common and it also comes with a lot of nuances that
drastically changes how you setup things. So maybe in this type of
situations it's better to ask on the user forum or contact Red Hat sales to
get some support?

Based on your questions (or cons) below you've not included near details to
give you any exact advice. It also sounds like you have a fairly advanced
use-case. A few comments though:

* It doesn't sound like you should use realms as they are designed to be
fully isolated from each other. Although you can use identity brokering to
allow users from one realm to authenticate to another realm.
* We're aware that the admin endpoints/console doesn't allow more fine
grained authorization. Hence you're not able to create admins that can only
manage a subset of users and clients.
* Keycloak is not a datastore. It sounds like you want to store attributes
against a realm and/or clients that really don't belong there. Realms store
configuration data specific to Keycloak and same with clients. You need an
application level database for your produce store for those details.

As an educated guess from your pros/cons (a list of requirements would have
been better):

* Use a single realm
* Use a client per produce store
* Use a group or roles to associate users with produce stores. Do you have
users that are admins in one store and staff in another? Probably not, so
you could have two roles (admin, staff) and one group per produce store
* Use the multi tenancy support in the adapter to select the correct client
for the produce store (I assume based on a URL or something)
* Store details about produce store in your produce store application, not
in Keycloak. This includes safely storing credit card details, which needs
to be encrypted in your produce store database
* For user management you'd need to create your own application as we don't
have a way to allow admins to only manage a subset of users. That is
planned for the future, but it's going to be a while until we get to it

On 26 May 2016 at 21:10, Hristo Stoyanov <hr.stoyanov at peruncs.com> wrote:

> Hi all,
> I wanted to share my thought process of fitting KC against a very common
> use case.
> Perhaps this would lead to better docs (so other can avoid this process or
> ask the same questions in this forum)
>
> Use case:
> Build a fictious "Utlimate Produce Store Web App" SaaS application for
> produce store management. Basically,
> a produce store owner wants to register his/her store, link it to credit
> ard/bank account,
> and add other staffers under the store registration. It boils down to two
> roles per store registartion:
> 1. admins - can add/delete staffers, store credit cards and everything a
> staffer can do.
> 2. staffers - limited store management activites.
>
> Here is how I look at KC for utilizing it for this kind of SaaS app:
>
> 1. Map each produce store to a separate Realm. Register store admin users
> with "manage users" realm-level built-in role.
> ==================
> A. pros
>    a1 Leverage almost all of UI of KC
>    a2 there is some "multi-tenancy" section of the documentation, but it
> is not clear if the one can dynamically assign/remove realm to a WAR app.
> B. cons
>    b1 Nothing in the KC suggest that realms can be created dynamically.
> There is lots of xml/json configurations that go into specific places, and
> with each realm
>    b2 WAR app files need to have the realm hard-coded in the web.xml
>    b2 No attributes for realms? There are attributes for users and groups,
> but not for clients,roles,realms. (Someone explain the thought process
> here...)
>    b3 How does KC scales with 1000s of realms?
>    b4 Realms can not share users (A store staffer can work at two stores,
> I suppose, and a manager can have several stores)
>    b5 Produce store manager will see "user federation" in the menu that
> would confuse them a lot!
>
>
> 2. Map each produce store to a KC client. All under the same realm
> "Utlimate Produce Store Web App"
> ===================
> A. pros
>    a1. It looks like clients can be created dynamically without json/xml
> configuration.
>    a2. There are "cleint templates" which can make the process even
> simpler.
>    a3. The admin console has search for clients, which suggests that this
> approach may scale - e.g. having 1000s of clients
>    a4. Via the KC Events, one can detect when a new user registers under
> the realm and automatically create a client(produce store) for him/her.
>    a5. A user can work in one or more stores (clients)
> B. cons
>    b1. There is no admin console at the client level in KC to be
> leveraged. This would need to be developed from scratch.
>    b2. Clients do not have attributes. A workaround is to create a
> surrogate group in each client, solely for the purpose of storing produce
> store attributes (e.g credit card)
>    b3. UI for adding/removing people to store registration needs to be
> developed from scratch. Nothing out-of-the-box.
>
>
> 3. Map each produce store to a group. Have a single client "Utlimate
> Produce Store Web App" under a bogus realm.
> ====================
> A. pros
>    a1. Groups have attributes. There can even be a hierarchy of them for
> more sophisticated arrangements.
>    a2. Each store can have specific group hierarchy.
>    a3. A user can work in one or more stores (clients)
> B. cons
>    b1. Virtually no usefull KC out-of-the-box UI for managing groups on
> per-group bases. You cant really give store owners realm-level priviledges
>    b2. The realm admin console does not look like optimized for serch
> managaement of large number of groups
>
> I do not know if I am on the right track and would have to spend
> significant time reading KC docs and Java sources to figure out
> A/ if KC is a good choice, and B/ if so, which appoach is best for such a
> common SaaS business case.
>
> The point here is that the KC documentation should discuss such business
> scenarious a lot more and help solution architects decide
> quickly the 2 most important questions:
> - Is KC right for my web/mobile app needs.
> - If so, how do I map KC concepts to my business domain withouth making
> costly mistakes.
>
> /Hristo Stoyanov
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160527/754dd6fd/attachment-0001.html 