[keycloak-dev] Readonly UserModel

[Bruno Oliveira]

On 2016-08-11, Bill Burke wrote:
> IMO, you don't need to put a lot of work into this as UserFederation SPI
> is going to be deprecated.

Thanks Bill, will replace it at SSSD federation provider.

>
> Here's an example of new UserStorageProvider SPI.  Its very similar.
>
> https://github.com/keycloak/keycloak/tree/master/examples/providers/user-storage-jpa
>
> There will be no more importing of users.  If you think about it, what
> we had before was a persistent cache, which IMO, doesn't make much
> sense.  The biggest reason for imports was it made querying easier, but
> I think I've got a solution for that implemented, albeit an inefficient
> one for large role sets.

Should we just put the idea to bed for now?

>
> What I think we will need is a common exception i.e. ModelReadOnly or
> something and have it handled gracefully in the admin console and rest API.

Maybe I'm oversimplifying and missing the big picture. But why not have a
UserModel with boolean field like "editable"? Something close to what we
have today for enabled/disabled users.

>
>
> On 8/11/16 3:12 PM, Bruno Oliveira wrote:
> > Ahoy, after exploring some ideas I implemented the initial draft[1] for KEYCLOAK-3060[2]. Before submitting any changes, I would like some feedback.
> >
> > - Motivation
> >
> > Disable input fields when read-only federation providers like SSSD or LDAP (read-only mode) are enabled.
> >
> > Another alternative would be just hide sections which people are not supposed to edit. For example: account, OTP and password section.
> >
> > To be honest, I'm 50/50 about it, because hiding sections could be confusing to users.
> >
> > - Pros
> >
> > * Users won't get frustrated trying to update their profile, to later find out that's not possible.
> > * Input fields will truly represent what our user is, into other words, read-only
> >
> > - Cons
> >
> > * UserModel from my perspective is the only possible place to introduce this change[3] (I can be wrong). The drawback is that the change will affect all the implementing classes.
> >
> > - Options
> >
> > 1. If you are fine with the changes here[1]. I could do some clean up, write the proper integration tests and work to get it merged.
> >
> > 2. Do nothing and leave it as is.
> >
> > Thoughts?
> >
> >
> > [1] - https://github.com/abstractj/keycloak/tree/KEYCLOAK-3060
> > [2] - https://issues.jboss.org/browse/KEYCLOAK-3060
> > [3] - https://github.com/abstractj/keycloak/blob/af30b4da101fd7f7775e74b93c6da2f611d364ae/server-spi/src/main/java/org/keycloak/models/UserModel.java#L61-L64
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj
PGP: 0x84DC9914