[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