Is it possible to integrate OIDC authentication in Nexus OSS?

Sonatype Nexus Repository
, ,
1

Hi, I am currently looking into implementing OIDC authentication via Microsoft Entra in the Nexus Repository.
As far as I know, there doesn’t seem to be an official way to implement SSO authentication other than SAML, which is supported by Pro.

So currently, I’m trying to implement it with Custom Auth Server (e.g. OAuth2-Proxy) + RUT Authentication, but I’m struggling with the following issues.

  1. when signing out, I can’t clear the cookie with the token and refresh the page, i.e. there is no endpoint for OIDC Logout.
  2. When I try to customize and build from the Public Repository, it does not include the RUT functionality.
  3. Even if I try to utilize the plugin supported by GitHub - tumbl3w33d/nexus-oauth2-proxy-plugin: Nexus plugin for OIDC login via OAuth2 Proxy, there is an incompatibility issue with version 3.78 and above.

For these reasons, I am currently struggling to implement SSO authentication in Nexus OSS. If anyone has encountered or solved similar issues to mine, I would love to hear your advice.

2

On the old Nexus, where SAML was not a thing at all I implemented an OpenID plugin, that overrode
import org.apache.shiro.web.filter.authc.AuthenticatingFilter;

to capture the endpoint. I did not do it in NXRM3, because it contains a SAML. I had to install the filters inside a configure method of my class overriding com.google.inject.AbstractModule.

It looked like this:
@Override
protected void configure() {
logger.debug(“configure is running”);

    requireBinding(FilterChainResolver.class);

    logger.debug("filter Key "+filterKey("jbossFilter"));

    bind(filterKey("casFilter")).toProvider(KeycloakSecurityCasFilterProvider.class).in(Singleton.class);
    bind(filterKey("indexFilter")).toProvider(KeycloakSecurityIndexFilterProvider.class).in(Singleton.class);

    install(new FilterChainModule()
    {
        @Override
        protected void configure() {
            addFilterChain(KeycloakSecurityReturnFilter.ENDPOINT, "casFilter");
            addFilterChain("/index.html*", "indexFilter");
            addFilterChain("/", "indexFilter");
            addFilterChain("/#*", "indexFilter");
        }
    });
   
}

I believe the Google injection framework is no longer in use, but you might find some other way how to add custom filters and implement their logic. They still use the Shiro framework so the authentication part should be similar.

Regarding 3.78 incompatibility with any customization, I already spent two full days trying to find a way how to bypass it. So far no luck. I have to admit I know very little about Springboot, I briefly encountered Spring 15 years ago. Most of the documentation covers basic dependency injection and only few articles cover plugins. It is possible to use plugins with Spring Boot, but those articles usually cover the case, where the application allows it. And I am not sure Sonatype had this extensibility in mind when creating 3.78.

I hope they did or at least they think about it now, but I am not sure it is a priority for them.

I hope it will help you at least a bit.

2 Likes
3

And those Singleton notifications were the (back then) standard javax.inject notifications.

4

Releases up to 3.82 still use Guice through Sisu, but we are working on Spring DI.

5

From your answer, I took it to mean that it’s difficult to implement SSO authentication without creating a plugin or directly modifying the public source code.
I thought I could implement SSO authentication via this Authentication via Remote User Token link, but I guess not…

6

A good source of how to do it using a plugin is the implementation of default realm:

The problem I see in your approach is the anonymous access. If you want everything authenticated, it think might work as you want to, but I see a problem with repositories you want to access with no authentication (but being able to update using authentication for example). I do not know how you would do it nicely.

Possibly forcing the remote token authentication for web UI and to require generated tokens from Nexus for updates (they are sent as basic authentication). But it creates a hell of configuration on the reverse proxy side (some URLs authenticated, some not…).

Creating your own plugin fixes this. You need to resolve the part with web access authentication and then you need to implement the authorization part. The SAML implementation by Sonatype is not very agile. It only works on a single domain - if you use multiple domains to access Nexus, you have a problem. If your identity provider changes configuration, you also have a problem and must fix it manually. In my case the biggest hurdle of it is the single-domain support.

Edit: I strongly suggest you do NOT try to update Sonatype code. I do not know how you would compile everything and create a working application, because starting with 3.80 the free and professional version were merged so you would have to compile parts you do not have (or add them through build hacking). And I am not considering the legality of this attempt.