Add support for authentication via Trusted Header (SSO support)

[scic]

We would like to integrate verdaccio in our existing SSO (Single-Sign On) service which is provided by our IAM. Thus we would like to delegate the authentication to a reverse proxy that runs in front of verdaccio.

We will proxy all requests through the Reverse Proxy like described in the Verdaccio Reverse Proxy Docs. Additionally this Reverse Proxy will authenticate all request with a user. If a valid user is detected it will set two headers one with the user and the other with his groups. Verdaccio should then just trust these headers and take them for granted because the user validation has already been done.

E.g. the reverse proxy sets the headers:

• X-Forwarded-User (containing the user name)
• X-Forwarded-Groups (containing the groups of the user - delimited by e.g "|")

This works securely because we will allow traffic to verdaccio only through this reverse proxy. No other server is allowed to access verdaccio directly. All communication is configured to be possible only through the reverse proxy.

See as an example the following plugin that does something similar for Jenkins:
https://plugins.jenkins.io/reverse-proxy-auth-plugin

For this to work we need verdaccio to be able to read or propagate the trusted headers (that the reverse proxy sets) in/to an authentication plugin.

The problem now seems to be that with the current authentication plugin interface we have no way to access the request headers. Because only user, password and callback are provided in the authenticate method: https://verdaccio.org/docs/en/dev-plugins#api

A solution would be to add another parameter to the authenticate method containing the original request. Thus an authentication plugin could then read these headers and set the user and groups accordingly.
Event better if you could also provide an implementation for such a plugin.

E.g the method signature of authenticate in the Authentication Plugin Api could look something like:

authenticate(user: string, password: string, cb: Callback, request: Request): void;

Like this the plugin would be able to read these headers from the request.

The following three aspects need to be configurable in the authentication plugin:

• trusted user header name
• trusted groups header name
• groups header delimiter

[juanpicado]

Hi @scic , perhaps you can give me a bit more of context, I don't fully understand the whole flow of this.

[scic]

@juanpicado I have updated the text of initial feature request to be more precise. Is this now more understandable?
The delegated authentication is useful so that your product does not have to implement every possible authentication flow yourself. E.g. a plugin for SAML, openid connect, client certificates, kerberos, ...
With the trusted header method an arbitrary IAM, SSO, Reverse Proxy Authentication can propagate the authentication to verdaccio without verdaccio implementing that flow for each product/protocol themselves.

[kumarvi]

@scic We're trying to do something similar for our internal registry and we use Kerberos for SSO in our firm. Were you guys able to proceed on this? It'd be great if you can share the approach you guys went with.

It looks like we can't get away with password, given the authToken generated in ~/.npmrc after a successful authentication is a hash of username:password rather than a token. And the npm client relies on this authToken for all further operations.

[hansiemithun]

What's the status on this? Even we are trying to rely upon SSO having verdaccio, but not able to find much help on it?

[juanpicado]

@hansiemithun the solution proposed by @scic makes sense and seems easy to achieve, are you willing to PR? I'm busy with other things so I cannot work on this. If someone decides to give a step forward I'd suggest work on top of the branch 4.1.x, this will require:

• Update https://github.com/verdaccio/flow-types
• Add unit testing and functional test https://github.com/verdaccio/verdaccio/blob/master/test/README.md
• Update documentation https://github.com/verdaccio/website/blob/master/CONTRIBUTING.md

Let me know if someone needs more guidance, you can find me in the community chat.

[snacks-lord]

I'm interested in something like this. We use Okta for SSO/SAML authentication.

[juanpicado]

Do you know guys a way to mock this locally? local service either OSS or something?

[snacks-lord]

I can look, but I am sure you'll need an Okta account for what I am trying to do. Fortunately, they do offer free developer accounts.

[niklaskorz]

@juanpicado Keycloak is open source and supports single sign on through OpenID Connect as well as SAML.

[juanpicado]

Nice, thanks for sharing that.

[niklaskorz]

There also seems to be an in development plugin by @buschtoens for directly supporting openid connect: https://github.com/ClarkSource/verdaccio-oidc

There hasn't been any progress recently though.

[buschtoens]

State of development of verdaccio-oidc is further detailed in ClarkSource/verdaccio-oidc#2 ☺️

[DanielRuf]

Awesome, so there is some progress. 👍

[juanpicado]

FYI Related to this npm/rfcs#93
and #1515

[ThisIsMissEm]

I think the feature requested here, to support headers from an oauth proxy in front of Verdaccio is actually going to be incompatible with the npm cli — even with the RFC implemented. This is because the CLI needs to gain an auth token somehow, which you wouldn't be able to gain when using something like oauth_proxy

Unless the oauth proxy implements the Device Code Grant Flow?