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
> 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.
> 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.