[keycloak-dev] Proper handling of read only users from user storage

[Bill Burke]

I know it is far from ideal.  I think it can be added on later. Storage 
providers could implement a UserCapabilitiesProvider interface which 
returns an object that specifies which attributes, mappings, etc. are 
readonly/writeable, etc.


On 12/2/16 10:36 AM, Stian Thorgersen wrote:
> Can we with confidence do this early in 3.x without having to change 
> the user storage SPI? If so I've got no issue with postponing it to 3.x.
>
> On 2 December 2016 at 16:30, Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>> wrote:
>
>     That's far from ideal. Dealing with this through an exception is
>     horrible. I've said several times that all we need at minimum is a
>     way for a provider to tell Keycloak if it's read or read/write. A
>     boolean is fine for now. Once we had that it would take an hour or
>     two to do the UI work.
>
>     On 2 December 2016 at 15:15, Bill Burke <bburke at redhat.com
>     <mailto:bburke at redhat.com>> wrote:
>
>         All we're going to be able to implement is better handling of
>         the ReadOnlyException.  I just don't have time to do UI work,
>         it takes too long.  As it is, many providers will be hybrid,
>         that will be both read-only and writable depending on the
>         attribute, role, credential type, or whatever. LDAP is a
>         perfect example where attributes and role/group mappings can
>         be read only or writable in the same deployment.  So, anything
>         more elegant will require reworking LDAP as well.
>
>
>
>         On 12/1/16 5:59 AM, Stian Thorgersen wrote:
>
>             We should solve the following issues for 2.5.0:
>
>             https://issues.jboss.org/browse/KEYCLOAK-3060
>             <https://issues.jboss.org/browse/KEYCLOAK-3060>
>             https://issues.jboss.org/browse/KEYCLOAK-3613
>             <https://issues.jboss.org/browse/KEYCLOAK-3613>
>
>             The current behavior of showing a form and throwing an
>             error is not very elegant and this should be resolved
>             before as part of user storage SPI work.
>
>
>
>