OK; I hear you.

I do believe, however, that the things above - and quite a few other things - are really required to get
the usability of an "Out Of The Box" product. Let me suggest some things below:

2015-08-13 20:47 GMT+02:00 Bill Burke <bburke@redhat.com>:

On 8/13/2015 2:18 PM, Lennart Jörelid wrote:
> [Forwarding to the list; not meant as a personal reply.]
>
> Hello there,
>
> This is exacly what I am struggling with at the moment. I have found a
> number of things which would need clarification in documentation as well
> as in examples:
>
>  1. *Custom user data properties/fields*. It seems that one has to/ought
>     to add custom properties to three places in the theme files:
>     account, admin and registration. However, the ways to add them
>     differ greatly, as each FTL template structure is quite different.
>     (Account uses account.ftl; Admin uses
>     partials/user-attribute-entry.ftl). Pattern definitions and
>     explanations are missing from examples and documentation, as far as
>     I can tell.

Stian wants a generic service.  I disagree because I don't think it will
be used.  I just look at developers.redhat.com for example, and they
have differing formatting requirements.  You would end up recreating cSS
and HTML within the admin console.  Not something I'm kean on doing.

This is a tricky task to create in a simple manner; I agree with that.
The model and view could be created separately, and joined to a result using DI. So ...
  1. Model - from a Dev perspective: Defining entity classes (JPA and JAXB to combine storage and transport) is pretty common for developers, as is extending specified interfaces. If you simplify the model for users to a standard Entity and include a setter/getter pair for something which is an interface (instead of today's mapping between unvalidateable string and unvalidateable string), developers can simply implement their own custom metadata class which can include Validation on any of the fields - not only passwords. Today, we cannot validate the content of any custom properties, as they are stored as Strings.
  2. Model - from a Non-Dev perspective: Non-developers require quite a lot of tooling to create the model classes. Is it your idea of an "Out of the Box" solution that non-devs should be able to define the custom properties of each user? If so, I believe that the "generate-the-model" tooling is currently missing from the codebase.
  3. Model - performance: The current solution ought to give really poor performance when the number of users in the keycloak database rises; the JPA implementation of custom attributes stashes all of them in a single table with a String containing an UUID for primary key... at least with an integer, custom attributes for a single user will be stored at similar locations. Your UUID approach guarantees that each user attribtue is scattered evenly across the table, and re-indexing will happen every time a new value is inserted. There are quite a few other options to implement this functionality that would improve performance compared to the current solution - but these require some form of development backround from a user. Which approach will KeyCloak take?
  4. View - from a Dev perspective: We architects and developers like standards that we have encountered before, and creating a complete theme with the level of control you envision above is, quite frankly, really difficult today. Not only is the documentation lacking on theme basic semantics, but you need to understand how quite a lot of fragments are joined together by Freemarker to a live page. While Freemarker is not unheard of, it is an oddball (i.e. not part of the standard JavaEE platform).
  5. View - usability: Usability is king. If you would like to improve usability for people trying to create custom user properties, I believe that you must use standard JavaScript frameworks or JavaEE tech. A suggestion: create a KeyCloak AngularJS module which contains a set of custom directives - this implies that users can create complete pages containing keycloak-specific tags. This implies that we can see all views in a theme, including the directives for custom attributes. I believe this would be considerably simpler than understanding which Freemarker fragments are used in a particular use case, as is the case today. With improved usability comes reduced burden of documentation, which should please quite a lot of you KeyCloak devs.
  6. View - conclusion: I don't think that today's freemarker approach works - and while I can certainly create another ProviderFactory than the Freemarker one, I don't know the end result which I should target. What pages should be done, and in which order are they called?
>  2. *Editable properties per role*. Realm admins/editors could perhaps
>     be able to edit all properties (except primary key/ID value) for all
>     the users in a realm - but we would typically like to restrict which
>     properties (both basic and custom attributes) are editable depending
>     on the roles/privileges a user has in the realm. (For example, it
>     would likely be a bad ide to permit users to change their names and
>     birthday arbitrarily after registration). How do we restrict
>     editability of normaly and custom user properteis - both in terms of
>     the data and the forms required to interact with keycloak? Pattern
>     definitions and explanations are missing from examples and
>     documentation, as far as I can tell.

We don't have a way to do this in the account service yet.  You can
modify the forms to display whatever you want, but a rogue user would be
able to modify any attribute they wanted.  Ugh, we probably need to fix
this.

I think that this is core functionality, if KeyCloak should really work as an out-of-the-box solution.
In particular, since you folks have taken the approach that KeyCloak should hold a set of base
properties for each user, and supply means to extend those base properties with custom properties.

This means that using KeyCloak should really imply 3 initial steps after installation:

  1. Define your set of custom user properties.
  2. Create a theme in order to be able to handle your custom user properties (store, manage, etc.)
  3. Migrate (or Federate) all users from the current IDM database/application to KeyCloak. This means that it must be a trivial (and well-example'd/well-documented) task to develop a Class which reads the currnet IDM data and makes instances of KeyCloak UserModel instances, including all its extra properties.
This means that the KeyCloak documentation must walk users/developers through these steps. In some detail. Right?
 

>  3. *Linking users to roles/privileges in other realms.* How should one
>     construct realms to grant roles & privileges automatically to users
>     in other realms? (For example: All Users in Literary Society A can
>     register for a party hosted by Literary Society B. Hence, how does
>     realm admin B grant role KnownGuest to all users in realm A, to
>     permit them to access Society B's register-to-the-event-page?
>     Assume, of course, that both A and B are managed by the same
>     Keycloak DB, so basic identity attributes should be extracted
>     normally from Keycloak. Neither realm admins from A or B have master
>     realm access.) Pattern definitions and explanations are missing from
>     examples and documentation, as far as I can tell.
>

I don't think we'll ever have the ability to link realms.  If we did
ever add it it would be next year.  Too much in queue at the moment.

Hm. This feasture is really important to me.
I can certainly summon up some JIRAs for it, and suggest some compliant solution and PRs.
If you wish, ping me on Skype to discuss.
 
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@jguru.se
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+