| Name | Server Side Requirement | Client Side Requirement | Authentication | Access control |
|---|
| Nexus | Nexus | Curl or Web UI | LDAP Native Nexus's authenticator | Nexus. LDAP Group mapping to local roles is available. |
Pros: Cons: - rather Java-world/Maven related
- Nexus pro is not open source (but free for OSS organizations)
- Nexus's API is not as robust as we might expect to
|
| SFTP | OpenSSH + pam_ldap + nslcd + nscd
LDAP PosixAccount/PosixGroup | any SFTP client | LDAP w/ pam_ldap | sshd_config |
Pros: - POC provided
- Posix properties handled within FD
- openssh allows you to grant access to any Posix group matching a pattern (with Match Group *-manager)
Cons: - The system would rely on LDAP Posix classes (posixGroup, posixAccount) which at some point would duplicates with already defined regular LDAP's Group/Roles objects (groupOfNames/organizationalRole) in every projects, adding complexity and uncontrolled data dups to the system.
- File structure enforcement isn't possible
- Per previous item : very difficult to compute statistics with erratic files/folders structure
|
| GitLab w/ Release Page | GitLab + the release page feature | GitLab | GitLab's LDAP authenticator | GitLab (no group mapping) |
Pros: - Everything we need if implemented correctly (thinking about stats)
Cons: - The feature is not implemented yet
- The chance for the required feature to be implemented in GitLab is close to zero
- Rely on GitLab local groups (rather that LDAP roles/groups)
|
| Gitlab w/ file upload to tags | Gitlab | Gitlab | GitLab's LDAP authenticator | GitLab (no group mapping) |
Pros: - Available now
- Fully integrated
Cons: |
| SVN / svnpubsub (ala apache) | a SVN repository w/ hook + Apache related modules (DAV) | svn client over HTTPS | Apache's mod_ldap | Apache's LDAP "Requires ldap-group" (see limitation cons) |
Pros: - svnpubsub is an elegant and proven mechanism
- Svn handles binaries very well
- A single SVN repo for all projects (see dists at Apache)
- Being registered to a svnpubsub stream opens doors to anything we can think about what can be done after publishing a release
- Used by ASF for the past ten years
- POC almost proven
Cons: - No file structure enforcement
- Per previous item : very difficult to compute statistics with erratic files/folders structure
- Rely on ASF's svnpubsub python code which is pretty undocumented
- Need to find and test a proper access control management against release manager roles from FD (currently one role object per project)
- study option 1 : Path based access control using authz based on LDAP groups/roles isn't straight forward: as stated in the workaround scripts "Subversion’s authz architecture requires your group definitions to be defined within the authz file."
- study option 2 : no authz file but usage of apache's Require ldap-group. Problem is we currently have as many groups to grant as projects.
|
| XWiki | XWiki form handling a POST upload | Curl or Web UI | XWiki's LDAP | LDAP groups using FD's webservice or XWiki local groups |
Pros: - Total control of the implementation
Cons: - Rely 100% in XWiki in terms of service availability and coding skills. (XWiki offline = no FRS service)
- code fully maintained by OW2 team
- kind of "Reinventing the wheel"
|
| OW2's Standalone FRS | TBD | Curl / REST calls | TBD | TBD |
Pros: - Total control of the implementation
Cons: - code fully maintained by OW2 team
- kind of "Reinventing the wheel"
|
