Nexus repo cannot be used with simple credentials in URL

Cloudogu EcoSystem Dogus
1

First of all, I would like to wish you a happy new year :tada: before I start with the actual topic. It’s about Nexus.

Situation: I want to provide a repository that should not be accessible anonymously. The registration should be specified within the URL - as follows: http(s)://user:password@domain/nexus/repository/raw-private/service.yaml.
The background is to provide a yaml manifest for an Openshift DevSpaces workspace.

How it works in standard Nexus: I try exactly the same situation with a simply set up Nexus container in another docker host and do the following steps:

  • create a raw repository there
  • deactivate anonymous
  • create a role with read rights exclusively to this repo (read, browse and search rights)
  • create a user and give him only this role
    then I can, for example, download this file in a private browser window by specifying the user and password in the URL.

If I leave out the username and password, I get the Nexus login prompt and the download is also possible. This proves that I am using a valid user.
If I log in to the GUI, I only see this repo.

Now, how it appears in the ecosystem: I proceed 1:1 as if I only had the Nexus - so I create the user within Nexus and not in the ecosystem’s user management.

If I call up the URL with username and password in another browser or in a private browser window, I get the ecosystem’s login window, i.e. the /cas/login URL - not the Nexus login window.

I cannot log in with the user created in the Nexus, instead the login data of a user created in the user management is required - that is strange. Why then is there user management within the Nexus?

OK, so a group has been created in the ecosystem’s user management. Additionally, a user who becomes a member of this group.
Now it seems necessary that you have to have started Nexus with the user once so that the user even appears in Nexus. Is there any way to skip this step?
From a user management perspective, it is impractical that a user has to log in first so that I can restrict him afterwards - but that is not the core of this topic.

So, the user exists after registration and he can be reduced to this role.

Now the following happens: The URL is called up with the username and password - with the user that has now been created in the user management by the ecosystem. You still see the login page /cas/login - why?
If I enter the data here now, the download will be offered. I have checked the URL several dozen times, but it seems impossible to start the download directly without the CES login window.
But this is essentially necessary in the case of the Openshift DevSpaces, because you don’t get to the login dialog, but instead get an error message that the specified file or URL doesn’t work directly.
The user and password are correct. If I use the login credentials within ces and starting nexus, I only see that raw private repo in the gui. So, username and password are correct.

For me it seems, that nexus in ecosystem works different.
How can I achieve the same result with the Nexus within the ecosystem as with a solo Nexus?

Many thanks and best regards,
Sascha

1 Like
2

Hi @sbiallas ,
Thank you for your input and questions. We will look at them in more in depth and get back to you.

Regards

Philipp

3

Hello @sbiallas,

thank you for taking the time to write up this nice analysis.
The behavior you describe is somewhat inherent to how we handle authentication for Nexus in the Cloudogu EcoSystem.

Background:
Essentially, we wrapped Nexus in a CAS Authentication Reverse Proxy (CARP). Requests with basic auth only get forwarded to Nexus if they’re not requests from a browser. If browser requests are not authenticated by CAS, they get redirected to CAS for authentication.

Solutions:

  1. Access the Nexus repository without a browser. Here’s an example with wget:
    wget --user "<username>" --password "<password>" "https://<domain>/nexus/repository/<repo>/path/to/file"
    Use --no-check-certificate if you have a self-signed certificate like my test-setup does.
  2. As our code checks if the user-agent string contains mozilla or opera, it is also possible to fetch the files from the browser with a changed user-agent.
    :warning: However, this will cause CAS authentication (in Nexus and potentially other Dogus) to not work anymore. :warning:

I hope I could clarify this behavior and solve your problem in the process. If you have any further questions, feel free to ask.

Thank you and have a nice day,
Jeremias

4

Hi Jeremias,

many thanks for your answer.
That rounds up what we found out in between more or less.
Poked a bit and found out, that I can ship around this if I manipulate the browser and don´t use “mozilla”. But now I understand the background.

As we have to use the basic authentication information inside a browser page to add this into a field to provide the URL, there is no option firing this from any comand line.

Changing the user-agent will not be the accepted way, I guess. As I have to provide that function for a bigger amount of users.

In between, we deployed a nginx pod that provides that file(s) which have to be reached that way. For now, that solves the situation.

Many thanks providing the information and help me to understand what´s the reason behind.

Best regards,
Sascha