[keycloak-dev] Fwd: Remove address from registration and account management by default
Stian Thorgersen
stian at redhat.com
Mon Aug 17 05:28:56 EDT 2015
----- Original Message -----
> From: "Lennart Jörelid" <lennart.jorelid at gmail.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 13 August, 2015 11:34:58 PM
> Subject: Re: [keycloak-dev] Fwd: Remove address from registration and account management by default
>
> 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.
Assuming you want users in realm "Society A" to be able to login to applications in realm "Society B" you can use identity brokering for that. Through mappers you can then control what roles users from Society A is given in Society B.
There's no cross-linking between users in different realms at the moment beyond identity brokering. We would probably not add this either, as identity brokering already provides this capability.
>
>
>
> --
> 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
> +==============================+
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
More information about the keycloak-dev
mailing list