[keycloak-dev] Fwd: Remove address from registration and account management by default

Stian Thorgersen stian at redhat.com
Mon Aug 17 05:31:28 EDT 2015



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 13 August, 2015 8:47:56 PM
> Subject: Re: [keycloak-dev] Fwd: Remove address from registration and account management by default
> 
> 
> 
> 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.

No, that's not true - what I've proposed does not at all re-create CSS/HTML within the admin console. It would just provide the users the ability to define what attributes goes into a user, what type they are, some validation, which can be edited, which are required etc. Beyond basic "label - input" users would need to define a template themselves for how it is displayed in the login screen. Users would still define the html/template, but they would do it on a per-input level instead of for a full form.

> 
> >  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.
> 
> >  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.
> 
> 
> 
> --
> 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
>



More information about the keycloak-dev mailing list