This is just bad - throwing a ReadOnlyException rather than telling up
front that it can't do it is bad. I'm worried this will require changing
the user storage spi in the future to be able to support it properly.
On 2 December 2016 at 15:26, Bill Burke <bburke(a)redhat.com> wrote:
Providers are supposed to throw a ReadOnlyException in this scenario.
I
don't know if the LDAP provider handles this well. I was a bit confused
on how it worked, it seems like if a mapper is read-only, it allows you
to edit the change in the import. Basically unsynced mode.
In looking at your SSSD provider, you only throw ReadOnlyException for
attributes loaded by SSSD. For the rest, you allow the local import to
be updated (unsynced).
On 12/2/16 4:22 AM, Bruno Oliveira wrote:
> Good morning,
>
> Today for SSSD Federation storage everything is read-only. This
> is pretty much because we don't have any way to synchronize the changes
> made at the admin console back to SSSD.
>
> QE identified this bug[1], that kind of affects LDAP federation provider
> in read-only mode too. Correct if I'm wrong, but in theory, if the
federation
> provider is read-only, people should not be able to edit groups or
> roles.
>
> Do we anything in the new API to prevent people from changing roles and
> groups when the Federation provider is read-only?
>
>
> [1] -
https://issues.jboss.org/browse/KEYCLOAK-3904
>
> --
>
> 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