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-...
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/af30b4da101fd7f7775e74b93c6da2...
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
abstractj
PGP: 0x84DC9914