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

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

On 12/5/16 5:01 AM, Marek Posolda wrote: > On 02/12/16 15:26, Bill Burke 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. > Yes, the current read-only mode for GroupMapper is defacto > "unsynced". It allows you to add new group memberships, but those > memberships are saved in Keycloak DB, not in LDAP itself. So the > group membership is the merge of memberships from DB and from LDAP. > Removing group membership, which is saved in LDAP throws an exception. > > I am going to add new mode "read-only" and rename the current > read-only mode to "unsynced" to be better aligned with the modes for > userStorage. Created https://issues.jboss.org/browse/KEYCLOAK-4025 Don't forget to edit the migration script to handle this.