Skip to main content

Authentication via Remote User Token

Nexus Repository's Rut Auth capability allows authentication using an external security systems that passes along user details via HTTP headers for all requests to the Nexus Repository. This is a communication method common in authentication systems which share a single trust authority rather than managing the authorization separately in every tool. When the external system passes a value through the header, Nexus Repository grants authentication, and the value is used as the username for the authorization.

This model is common in authentication systems such as:

  • Public Key Infrastructure (PKI)

  • Central Authentication Systems (CAS)

  • Single Sign-On (SSO)

Users log in to the environment through a central login page that propagates the login status via HTTP headers. A reverse proxy server (e.g., Apache HTTPD or nginx) can be used to perform this authentication and direct all communication with the Nexus Repository. The proxy server may defer this role to another authentication storage systems (e.g., via the Kerberos network authentication protocol).

116230375.png

Authorization

Authentication determines who the user is but not what the users are authorized to access. Remote User Token authentication needs to be combined with another authorization realm such as LDAP to provide for external role mappings. Otherwise, only internally configured users/role will be used. See SAML documentation for an alternate SSO authentication method.

Configuring the Reverse Proxy

The following is an example proxy configuration in Apache. It connects to the proxy server, tries to authenticate, and if successful, it inserts the X-SSO-USER header and passes the traffic through.

SSLProxyEngine on
   SSLProxyVerify none
   SSLProxyCheckPeerCN off
   SSLProxyCheckPeerName off

   SSLOptions +StdEnvVars
   SSLVerifyClient require
   SSLCACertificateFile “/etc/pki/tls/certs/Your-CA-Cert.crt”

   # set header to upstream, SSL_CLIENT_S_DN_CN can change to use other identifiers
   RequestHeader set X-SSO-USER “%{SSL_CLIENT_S_DN_CN}

Note

NOTE: It doesn’t matter what you use as the request header name (in this case X-SSO-USER) - it just has to be the same on both the reverse proxy and the respective Nexus Repository.

The following snippet is appropriate for a reverse proxy running on the same host as the Nexus Repository, with incoming traffic going to port 443 being proxied to the server on port 8443. The Nexus Repository on port 8443 should be bound to localhost only, or the firewall should block direct traffic to port 8443.

# Proxy requests
#<LocationMatch “/(.*)“>
 ProxyPass / https://127.0.0.1:8443/ connectiontimeout=5 timeout=90 retry=0
 ProxyPassReverse / https://127.0.0.1:8443/
#</LocationMatch>

Configuring Nexus Repository

Activate HTTP header integration by adding and enabling the Rut Auth capability:

  1. Log in as a user with administrative rights.

  2. Access the Server configuration in the Administration menu section on the left.

  3. Navigate to the System section and select Capabilities.

  4. Click Create Capability and then select Rut Auth.

  5. Configure the HTTP Header name to the value used by your PKI system, e.g. X-SSO-USER, and click Create capability.

  6. Now click Realms under Security in the Administration menu on the left.

  7. Move the Rut Auth Realm to the top of the Active list.

  8. Click Save.

The enabled capability (see our capabilities documentation) automatically adds the Rut Auth Realm to the Active realms in the Realms configuration described in Realms.

With this configuration in place, any username that is passed to Nexus Repository via the configured HTTP header field is assumed to be authenticated. The access level for the specific user is determined by the access rights for a matching username found in the internal security setup or any configured LDAP system and the associated roles.