[keycloak-dev] Fwd: Remove address from registration and account management by default
Lennart Jörelid
lennart.jorelid at gmail.com
Thu Aug 13 17:34:58 EDT 2015
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 at 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 at 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 at jguru.se
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150813/38e84eca/attachment.html
More information about the keycloak-dev
mailing list