[keycloak-dev] Readonly UserModel

[Scott Rossillo]

Bill, you’re planning to remove user federation support? Did I read that correctly?

Scott Rossillo
Smartling | Senior Software Engineer
srossillo at smartling.com

> On Aug 11, 2016, at 4:51 PM, Bill Burke <bburke at redhat.com> wrote:
> 
> 
> 
> On 8/11/16 4:33 PM, Bruno Oliveira wrote:
>> 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.
> I'm currently working on revamping credential storage and validation.  
> Hope to get to documentation right after than.  If you look tat the 
> example though, you can pick and choose which interfaces you want to 
> implement.  If you just want to make a user available for lookup for 
> login, just implement that interface.  If you want admin console 
> support, implement another interface.
> 
>>> 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?
> For userFed SPI, yes...but the new stuff needs review.
> 
>>> 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.
> 
> Some implementations may only be readonly for certain attributes, 
> properties, and/or credentials.  For example, LDAP might be read-only, 
> but the provider may be storing other things within Keycloak.
> 
> Bill
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160811/6a920144/attachment-0001.html