Add serverless service type

[dbyrns]

Magpie starts its journey as a services adapter for twitcher.
All services have a private url proxied by twitcher and magpie keep a resources / permissions database allowing twitcher to authorize or block access to them.

However, Magpie alone provides authentification and has a complete API to handle resources / permissions. So the following question arises : What if I want to use Magpie as a service to handle permissions of my micro-service that doesn't have any public API to be protected by Twitcher?

So the current issue is to bring that possibility to Magpie. We should be able to register a micro-service as a serverless service type. Magpie will not let Twitcher access it. The micro-service would then be responsible of creating its resources and checking itself the permissions.

[fmigneault]

@dbyrns
Is this still relevant?
How is Twitcher employed in this case if not via Proxy URL?

For the moment we got a ServiceAccess which is all-or-nothing access to some URL.
Its a bit dirty, but this feature can be worked around by giving any random URL to Magpie under such service. Magpie doesn't verify the provided endpoint as it is not guaranteed to have access to it itself.
Then, the applicable service could have a specific user with sufficient permissions that allows it to check whether some user has access to some given resource.

This last part can be a bit tricky at the moment (requires admin permission to get users/resources/perms) but should be much easier with #341. Also, #170 and #340 (or other specific feature) could add 'owned' service permissions, which would remove the need for admin-level access. (note: Magpie already has user-resource and group-resource ownership tables, just not yet employed extensively in the API).

[dbyrns]

I think it is. A good example is for single page applications that don't have url based restrictions. ServiceAccess is indeed a workaround and was used in the past, but I think Magpie could do better. Removing admin-level access is a needed feature and once available this issue should be as simple as creating a new service type that do not create a new endpoint under twitcher.

[fmigneault]

Magpie is able to respond with effective permissions using the appropriate effective=true query parameter on relevant API permission retrieval endpoints that support it.
Using a ServiceAPI implementation, one could define their custom structure of "roles" similarly to request paths: eg. a "resource" feature/operation/action.
Using this, the Magpie API can then be queried for such "feature/operation/action" resource, and obtain the access of a given user for that resource.
The ServiceAPI only has read, write permissions for now. A derived service implementation would be needed for more custom "scopes".

Closing this issue since no requirements when needed for a long time.
Could reopen and address as needed if a use case ever occurs.