<div dir="ltr">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?<div><br></div><div>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:<br></div><div><br></div><div>* 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.</div><div>* 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.</div><div>* 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.</div><div><br></div><div>As an educated guess from your pros/cons (a list of requirements would have been better):</div><div><br></div><div>* Use a single realm</div><div>* Use a client per produce store</div><div>* 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</div><div>* 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)</div><div>* 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</div><div>* 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<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 26 May 2016 at 21:10, Hristo Stoyanov <span dir="ltr"><<a href="mailto:hr.stoyanov@peruncs.com" target="_blank">hr.stoyanov@peruncs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hi all,<br>
I wanted to share my thought process of fitting KC against a very common use case.<br>
Perhaps this would lead to better docs (so other can avoid this process or ask the same questions in this forum) </p>
<p dir="ltr">Use case:<br>
Build a fictious "Utlimate Produce Store Web App" SaaS application for produce store management. Basically,<br>
a produce store owner wants to register his/her store, link it to credit ard/bank account,<br>
and add other staffers under the store registration. It boils down to two roles per store registartion:<br>
1. admins - can add/delete staffers, store credit cards and everything a staffer can do.<br>
2. staffers - limited store management activites.</p>
<p dir="ltr">Here is how I look at KC for utilizing it for this kind of SaaS app:</p>
<p dir="ltr">1. Map each produce store to a separate Realm. Register store admin users with "manage users" realm-level built-in role.<br>
==================<br>
A. pros<br>
a1 Leverage almost all of UI of KC<br>
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. <br>
B. cons<br>
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<br>
b2 WAR app files need to have the realm hard-coded in the web.xml<br>
b2 No attributes for realms? There are attributes for users and groups, but not for clients,roles,realms. (Someone explain the thought process here...)<br>
b3 How does KC scales with 1000s of realms?<br>
b4 Realms can not share users (A store staffer can work at two stores, I suppose, and a manager can have several stores)<br>
b5 Produce store manager will see "user federation" in the menu that would confuse them a lot!<br>
<br>
<br>
2. Map each produce store to a KC client. All under the same realm "Utlimate Produce Store Web App"<br>
===================<br>
A. pros<br>
a1. It looks like clients can be created dynamically without json/xml configuration. <br>
a2. There are "cleint templates" which can make the process even simpler.<br>
a3. The admin console has search for clients, which suggests that this approach may scale - e.g. having 1000s of clients<br>
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.<br>
a5. A user can work in one or more stores (clients)<br>
B. cons<br>
b1. There is no admin console at the client level in KC to be leveraged. This would need to be developed from scratch.<br>
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)<br>
b3. UI for adding/removing people to store registration needs to be developed from scratch. Nothing out-of-the-box.</p>
<p dir="ltr"> <br>
3. Map each produce store to a group. Have a single client "Utlimate Produce Store Web App" under a bogus realm.<br>
====================<br>
A. pros<br>
a1. Groups have attributes. There can even be a hierarchy of them for more sophisticated arrangements.<br>
a2. Each store can have specific group hierarchy.<br>
a3. A user can work in one or more stores (clients)<br>
B. cons<br>
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<br>
b2. The realm admin console does not look like optimized for serch managaement of large number of groups<br>
<br>
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 <br>
A/ if KC is a good choice, and B/ if so, which appoach is best for such a common SaaS business case. </p>
<p dir="ltr">The point here is that the KC documentation should discuss such business scenarious a lot more and help solution architects decide <br>
quickly the 2 most important questions:<br>
- Is KC right for my web/mobile app needs.<br>
- If so, how do I map KC concepts to my business domain withouth making costly mistakes.<span class="HOEnZb"><font color="#888888"><br></font></span></p><span class="HOEnZb"><font color="#888888">
<p dir="ltr">/Hristo Stoyanov</p>
</font></span><br>_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br></blockquote></div><br></div>