Create admin API like Google does it for its services

[labkode]

• Account transfers
• Integration with other deployed system for user lifecycle management

[ishank011]

Hi @refs let's carry forward the discussion regarding the admin API here.

The points mentioned in the ADR look quite good. If I'm not mistaken, the CS3APIs admin service would look like the AccountsServiceHandler interface.

A few questions:

• We're giving the option of configuring different backends in OCIS itself - ldap, glauth or the reva user provider via CS3APIs. Would it make sense to delegate this whole thing to reva? Might lead to less code duplication. We already have the ldap driver, will need to add the glauth drop-ins. On the other hand, we might introduce concept and pieces of code in reva which don't make sense to be present there.
• "User permissions for roles are always managed in oCIS (settings service) because they are specific to oCIS." How would we ensure that proper roles are assigned in ocis if the users backend doesn't support that? This question comes from the recent issue we faced in ocis https://github.com/owncloud/ocis/issues/1825.
• The user and group provider services currently run pretty separately from one another. Once we introduce the admin service, I would like that these three be tied together somehow to ensure consistency. This is just a thought though and can be ignored for later.

[refs]

the CS3APIs admin service would look like the AccountsServiceHandler interface.

This is what I'm modeling first, correct :)

[...] Once we introduce the admin service, I would like that these three be tied together somehow to ensure consistency

I considered merging groups and users within the admin service in the upcoming proposal. They will be added.

How would we ensure that proper roles are assigned in ocis if the users backend doesn't support that?

For this, we have another concepting ticket opened that will be as well tackled in this sprint. It is conveniently named [Proposal] Add roles API to CS3 APIs