Add Authentication and Authorization Support to the ServiceControl REST API

[fafachd]

See the following for background:

• https://github.com/Particular/ServicePulse/issues/3

There needs to be a way to do authentication and authorization on the SC REST API so IT OPS can run ServiceInsight on their desktops without exposing the REST API to everyone on the network. The alternative is to have IT Ops remote into the server, but in larger orgs this access is very difficult to obtain.

[wooliet]

+1 Gaining access to anything in a moderately sized org is almost universally a painful process (especially as an outside contractor). Their ability to keep the production server locked down while still granting access to the web service is critical.

[jarrettv]

+1 agree

[ghost]

+1 Totally the case here - this would be a great improvement.

[rsutkowski]

WE NEED THIS!!!! Production servers are so locked down, nobody outside of the production control group has access nor will ever get access. PLEASE MAKE THIS A PRIORITY!

[fafachd]

Any update on this, @johnsimons or @andreasohlund?

[johnsimons]

No updates @fafachd, at the moment we are focusing on performance improvements.

@Particular/servicecontrol-maintainers should we raise this in plat dev ?

[gbiellem]

@johnsimons I'd say yes as it concerns multiple products.

[johnsimons]

This issue has been raised internally in plat dev.

@fafachd thanks a lot for starting this discussion, the way we manage this kind of suggestions, is by raising them internally in a private repo, where we prioritise it and manage it from now on. So with that in mind, I'll close this suggestion for now, and once we are ready to act on it we will reopen it. This does not mean we will not be working on it.

[fafachd]

Thanks, @johnsimons.

[andreasnilsen]

It's been 8 years, will there be any release of authentication/authorization features in ServiceControl in the foreseeable future?

It's a pity that one of the main selling points of the product (the tooling platform) either requires RDP login (bad UX), an "archaic" setup with IIS AAR + windows authentication or for the customer to implement their own proxy/auth mechanism in front of the systems.

Related issues:

• https://github.com/Particular/ServicePulse/issues/3
• https://github.com/Particular/ServiceControl/issues/2937

[DavidBoike]

The focus for a very long time in ServiceControl has been support for Linux containers which we are still technically finishing up on.

However, the landscape for authentication has fundamentally changed with the updates for containers. The ServicePulse container now includes a reverse proxy to provide a cloud-deployed application with a single point of ingress/egress, and that is the point at which you would use your cloud container hosting environment to layer on authentication features. We're still working on the details of this, so stay tuned.

Aside from that, we need more information from the community. Saying "add authentication" is…incredibly vague. We need to know exactly what you would expect "adding authentication" would mean for you.

And of course there's really no point talking about authorization until authentication is covered. That's a completely separate can of worms.

I'm going to reopen this issue as it seems more valuable than https://github.com/Particular/ServiceControl/issues/2937 (which exists becuase it was ejected from a private repo some time ago) which I will close. It would be great if we could use this space to discover more requirements around authentication so we can begin to understand what a solution around that would look like.

[ramonsmits]

My POV regarding authentication and authorization:

Authenticating reverse proxy:

Adding an authenticating reverse proxy is easy with tools like Traefik in a containerized environment but it will not add authorization via RBAC. For example, ability to execute certain tasks based on role or data (endpoint, namespace, or message type.

External identity management:

These days authentication is pretty much all done via a gatekeeper that will return an oauth style bearer token. That token would need to be parsed and have RBAC applied in the various API's. This would allow for very flexible identity/authentication providers where identity management would not need to be performed by the Particular Platform itself.

Basic login:

We could add a very basic login portal to specify one master password like for example Pihole but as a reverse proxy is easy to setup this would not be a priority. Doing this via a reverse proxy is also much more secure.

This issue likely is best to be split into:

• basic authentication (master password)
  • Sample showing reverse proxy with basic auth
• advanced authentication (token api)
  • Extend SC to work with external identities
• basic authorization (view [R] vs modify [W])
  • Add authorization to controller API's
• advanced authorization (authorization per endpoint, namespace, or message type)
  • Add authorization to data attributes