I am willing to create a private maven repository, where the access rules are not based on groups/patterns, but on completely custom rules. I've checked both nexus and jfrog, both of them keeping the simple user/group/pattern approach. And (AFAICS), although they provide custom ways to authenticate, they don't provide a was for custom access rules.
For this reason I have started thinking the opposite: what if I can create a simple repository with my custom rules. But when I searched in the Apache documentation, there was no clear explanation how authentication is performed on the back side.
Does anyone knows how this is done, and maybe point me to the correct documentation?
Authentication is done by HTTP Basic Authentication which basically concats the username and password and base64 encodes that. So Maven and Apache do understand each other.
But out of the box the Apache authorization is based on, you guessed, it. Directories (which represent Maven's artifact groups), username and groups. So unless you are willing to write a custom Apache model you won't gain a lot. Probably IP based access control can be done with Apache alone better than with Nexus/JFrog but I haven't looked at the authentication settings for ages.
In Artifactory what you can do, in order to achieve what you mentioned, is to create permission target per user. Meaning that all of your Maven users will deploy to the same repository BUT each to a different name space. For example, 'com/{company}/{project}/' (please replace the company and project with real values)
This is done on the permission target using the 'Include Pattern' so let's say that my company name is JFrog, and I'm working on a project named 'artifactory' I will have a permission target with the following include pattern '/com/jfrog/artifactory/**/*'.
You can also create those permission targets using a script that will automate it for you using this REST API.
That means that I will only be able to reach this namespace.
Does that help?
Related
Do you know a way to configure Nexus OSS so that it publishes the artifact repository to a remote server in a form that can be statically served, e.g. by Apache Httpd? I'd like to use this static copy to serve only my own artifacts, so the nexus server could actively trigger an update in case there is something new published.
Technically, I think it should be possible to create the metadata for the repo and store them in a static file, but I'm not sure with that. Any hints appreciated.
If there is another repo manager to achieve that, it would be fine for me as well.
I clearly understand the advantages to use the repo manager directly, but due to IT rules I can run Nexus only internally and it would be necessary to have these artifacts available in a (private) repo copy on the Internet as well.
A typical way to solve this IT requirement of only exposing known servers like Apache httpd is to setup Apache httpd as a reverse proxy as documented here.
You can use that approach in a more restrictive way by only exposing a specific repository or better repository group (so you can combine snapshots and releases) and tying that together with a specific user or a specifically restricted setup of the anonymous user that is used by default when no credentials are passed through.
Also if you need more help feel free to contact us in the user mailinglist or on hipchat.
I have installed Nexus 2.0.6 and the integration with my LDAP server is working (authentication only). Is there a way to configure Nexus so that only a set of developers are able to deploy a given artifact, or group?
I basically do not want a developer in Team A deploying an artifact that Team B is reponsible for.
You may partition a repository using repository targets, privileges, and roles as described in this Sonatype blog post. I tested this a few months back and it seemed to work well.
Under Nexus 2.0.1, this is the solution that I've worked through and verified.
Caveats:
This allows one to restrict the "Artifact Upload" option to a directory hierarchy.
This is not quite the same as "deploy" or in conjunction with "release prepare".
Steps:
Remove the single privilege of "Artifact Upload" from all that presently have it, that you do not want to have it.
Create the "Repository-Target" that includes the directory mask of where you want to give access. Ex. .*/com/mycompany/target-dir/.* Double check the mask, it starts with period-asterisk AND ends with period-asterisk.
Create the "Repository-Privilege" that maps to the Repository-Target you just created. Typically I include the repo-name in this repository-privilege-name, like "releases.com.mycompany.target-dir". This creates the CRUD entries (4) for said directory.
Next, create the "Role" based on the Repository Privileges you just created (4), plus "Artifact Upload". Total of 5 entries for the role. Use the "Apply Filter" here to help you find these items. I name this role something like "Upload.Role.Releases.Target-Dir". Again, when finished there should be 5 entries for this role:
Artifact Upload
com.mycompany.target-dir(create)
com.mycompany.target-dir(delete)
com.mycompany.target-dir(read)
com.mycompany.target-dir(update)
This is what constrains the upload role to this repo.directory.
Create the User if it does not already exist, assign password.
Give the user the following Roles:
Nexus Deployment
Repo: All Maven Repositories(Read)
UI: Base UI Privileges
Upload.Role.Relases.Target-Dir
Hit save and you've got it. Later on, you can use this same approach to create a new Role for other repos (say Snapshot or 3rd Party), and keep the same directory mask.
big problem. My Archiva internal repo (and maybe snapshot repo, although I don't know yet as I have not put any snapshots in there yet) seem to be accessible to the public.
I.e. if someone wanted the surefire plugin from my repo, they could download it by simply going to https://my.repo.url.com/archiva/repository/internal/org/apache/maven/surefire/surefire-junit3/2.7.1/surefire-junit3-2.7.1.jar
They could download the file right then and there. Would be a shame if there were actual project jar's and such in there also available to the general public and I can't seem to figure out how to disable private access to save the life of me.
I authenticate via LDAP.
Thanks!
To expand on Raghuram's answer, you should consider using different managed repositories for your own releases, as opposed to those proxied from an internet repository (as internal is configured to do by default).
Part of the confusion here is the legacy name of internal, which no longer accurately represents its meaning.
One possibility is you have a guest user, which has the repository observer role. You can either remove the user or disable the role. There is an FAQ which asks for the opposite of what you need.
Is it possible to create a new user in sonar without using the web interface?
I need to write a script that inserts the same users for some tools, including sonar.
There are three ways you can do this:
Write directly to the database (there is a simple table called users).
Use the LDAP plugin, if you specify sonar.authenticator.createUsers: true in sonar.properties, it will create the users in the sonar database automatically the first time they authenticate.
Write a java application that depends on the sonar plugin API, you can then use constructor injection to get a Sonar hibernate session and persist the user you want. See Here.
Since SonarQube version 3.6, there is support for user management in webservice API:
https://sonarqube.com/web_api/api/users
http://docs.sonarqube.org/display/DEV/Web+API
The web service API does not seem to support user management. Anything's possible, but it doesn't look like this is offered directly via Sonar.
You could probably use some web automation library (webbrowser, webunit, watir, twill) to do it through the running server; it might even be possible to just use something like 'curl' by looking carefully at the page source for the users/create form.
Or, if you want to go straight to the database, you could try to pull out the user creation functionality from the code and mess with the sonar.users table directly.
There is the LDAP Plugin, which would take care of authentication, but it still requires you to create the users in Sonar, so that wouldn't solve your problem.
We use ACLs to grant access to svn repositories. The users/groups are stored in LDAP (openLDAP 2.4 (LDAP3). Does anyone know or used libraries/package (gems) I can use. Basically, I will traverse LDAP DIT and update my svn file based on that.
Connect to ldaps://xxxxxxxxxxx:636
Traverse DIT (subtree based on 'ou')
Read attributes
Write svn ACL file.
That's the high-level overview of what I would need to do. So, my question is regarding ldap package/library that I could use. I have heard of Net::LDAP. I'm very new to Ruby, so, I'm learning it as I go along.
Also, please correct me if I am mistaken. We are using ldaps:// that means when I connect to ldap server, the server will send a certificate. Do I need to do anything special to handle the certificate? Thank you
I have used Ruby/LDAP before, things worked fine with me.
There is a code example that comes with the gem. Also have a look at the documentation.