Return-Path: X-Original-To: apmail-archiva-commits-archive@www.apache.org Delivered-To: apmail-archiva-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5778DDC40 for ; Wed, 29 Aug 2012 13:55:58 +0000 (UTC) Received: (qmail 33584 invoked by uid 500); 29 Aug 2012 13:55:58 -0000 Delivered-To: apmail-archiva-commits-archive@archiva.apache.org Received: (qmail 33532 invoked by uid 500); 29 Aug 2012 13:55:58 -0000 Mailing-List: contact commits-help@archiva.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@archiva.apache.org Delivered-To: mailing list commits@archiva.apache.org Received: (qmail 33525 invoked by uid 99); 29 Aug 2012 13:55:58 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Aug 2012 13:55:58 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Aug 2012 13:55:43 +0000 Received: from eris.apache.org (localhost [127.0.0.1]) by eris.apache.org (Postfix) with ESMTP id 3D1312388AA9 for ; Wed, 29 Aug 2012 13:54:58 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r1378558 [5/13] - in /archiva/site-content/docs/1.4-M3-SNAPSHOT: ./ adminguide/ adminguide/webservices/ css/ customising/ images/ images/logos/ images/profiles/ images/tour/ img/ js/ tour/ userguide/ Date: Wed, 29 Aug 2012 13:54:55 -0000 To: commits@archiva.apache.org From: olamy@apache.org X-Mailer: svnmailer-1.0.8-patched Message-Id: <20120829135458.3D1312388AA9@eris.apache.org> Added: archiva/site-content/docs/1.4-M3-SNAPSHOT/adminguide/roles.html URL: http://svn.apache.org/viewvc/archiva/site-content/docs/1.4-M3-SNAPSHOT/adminguide/roles.html?rev=1378558&view=auto ============================================================================== --- archiva/site-content/docs/1.4-M3-SNAPSHOT/adminguide/roles.html (added) +++ archiva/site-content/docs/1.4-M3-SNAPSHOT/adminguide/roles.html Wed Aug 29 13:54:51 2012 @@ -0,0 +1,372 @@ + + + + + + + + + Archiva :: Documentation - Understanding Apache Archiva Security Roles + + + + + + + + + + + + + + + + + + + + +
+ + + + + +
+
+ +
+ + +
+ +

Understanding Apache Archiva Security Roles

Archiva uses the Redback security framework for managing repository security. When the server is first started, you will be prompted to create an administration user. This user will be given permission to administer all aspects of the system (as well as access to all of the repositories). This user can then be used to grant permissions to other users.

A guest user is also created by default, and given read access to the default repositories (internal and snapshots). Repositories with guest user access can be accessed without the use of a username and password (or without being logged in to the web interface).

However, when new repositories are created, by default no permissions are assigned and only the administrators will have access until it is explicitly granted.

Note that Redback has the concept of inferred roles, so the assignm ent of some roles will imply other roles (which will be displayed in the web interface).

Repository Roles

Archiva contains the following roles for repository access:

  • Repository Observer: users with this role can read from the given repository that the role is for (including access through the browse and search features of the web interface)
  • Repository Manager: users with this role can write to and administer the given repository that the role is for
  • Global Repository Observer: users with this role can read from any repository (including access through the browse and search features of the web interface)
  • Global Repository Manager: users with this role can write to and administer any repository in the instance

General Roles

Archiva also contains the following general roles for security of the instance:

  • System Administrator: full access to all functionality in the system
  • User Administrator: ability to create, edit, and grant roles to other users in the system

The guest and registered user roles do not affect repository access.

+
+
+
+ +
+ + + + \ No newline at end of file Added: archiva/site-content/docs/1.4-M3-SNAPSHOT/adminguide/security-logs.html URL: http://svn.apache.org/viewvc/archiva/site-content/docs/1.4-M3-SNAPSHOT/adminguide/security-logs.html?rev=1378558&view=auto ============================================================================== --- archiva/site-content/docs/1.4-M3-SNAPSHOT/adminguide/security-logs.html (added) +++ archiva/site-content/docs/1.4-M3-SNAPSHOT/adminguide/security-logs.html Wed Aug 29 13:54:51 2012 @@ -0,0 +1,383 @@ + + + + + + + + + + Archiva :: Documentation - Security Logs + + + + + + + + + + + + + + + + + + + + +
+ + + + + +
+
+ +
+ + +
+ +

Security Logs

Archiva's logs directory contains a security log file named archiva-security-audit.log, which keeps track of all the security operations such as user creation/deletion, user role assignments, and user log in/out.

A typical record looks like this:

2009-07-22 12:03:11 -  - Successful Login for user admin
+2009-07-22 12:05:03 - admin - User Created: archiva
+2009-07-22 12:05:25 - admin - Role Assigned to user archiva: Global Repository Manager
+2009-07-22 12:05:33 - admin - User Modified: archiva

The hyphen delimited records are:

  • date and time (server local time)
  • current user performing the operation
  • the operation performed

Currently, the following events are logged:

  • user creation/modification/deletion
  • user log in/out
  • assigning roles to a user
+
+
+
+ +
+ + + + \ No newline at end of file Added: archiva/site-content/docs/1.4-M3-SNAPSHOT/adminguide/security.html URL: http://svn.apache.org/viewvc/archiva/site-content/docs/1.4-M3-SNAPSHOT/adminguide/security.html?rev=1378558&view=auto ============================================================================== --- archiva/site-content/docs/1.4-M3-SNAPSHOT/adminguide/security.html (added) +++ archiva/site-content/docs/1.4-M3-SNAPSHOT/adminguide/security.html Wed Aug 29 13:54:51 2012 @@ -0,0 +1,372 @@ + + + + + + + + + Archiva :: Documentation - Understanding Apache Archiva Security + + + + + + + + + + + + + + + + + + + + +
+ + + + + +
+
+ +
+ + +
+ +

Understanding Apache Archiva Security

Archiva's security is managed by Redback. The following document describes how to configure your repository security:

+
+
+
+ +
+ + + + \ No newline at end of file Added: archiva/site-content/docs/1.4-M3-SNAPSHOT/adminguide/staging-repositories.html URL: http://svn.apache.org/viewvc/archiva/site-content/docs/1.4-M3-SNAPSHOT/adminguide/staging-repositories.html?rev=1378558&view=auto ============================================================================== --- archiva/site-content/docs/1.4-M3-SNAPSHOT/adminguide/staging-repositories.html (added) +++ archiva/site-content/docs/1.4-M3-SNAPSHOT/adminguide/staging-repositories.html Wed Aug 29 13:54:51 2012 @@ -0,0 +1,407 @@ + + + + + + + + + Archiva :: Documentation - Staging Repositories + + + + + + + + + + + + + + + + + + + + +
+ + + + + +
+
+ +
+ + +
+ +

Staging Repositories

Starting with Archiva 1.4, staging repositories are supported. A staging repository is a repository you use to stage a release (while it undergoes testing and voting), before the release is officially announced and published to a releases repository where users can obtain it.

With the support of staging repositories comes the ability to merge repositories from the web UI. By merging, we mean promoting the artifacts in the staging repository to the managed repository. In the current implementation, a user with the System Administrator role can create and attach a staging repository to an existing managed repository. An attached staging repository is a shadow of its managed repository, meaning they have the same configuration.

We append -stage to the managed repository's ID to identify its staging repository. For example, repository test would have a staging repository called test-stage.

If you're creating a new managed repository, just tick the Create stage repository check box. Otherwise, if you already have an existing managed repository and you want to create a staging repository, just edit the managed repository's configuration and tick the Create stage repository checkbox, then save the configuration. A staging repository directory will be created beside (as a sibling of) the managed repository directory, again with -stage appended to the name.

Note: By un-ticking the Create stage repository checkbox, the user can delete the attached staging repository. If the managed repository is deleted, then its attached staging repository is also deleted.

The default snapshots and internal repositories do not have staging repositories configured by default, however they can be added by editing the repository configuration.

Populating the Staging Repository

The staging rep ository can be populated in the same way as a normal managed repository. You can configure your Maven build's distributionManagement section to deploy to the repository, or use Archiva's web-based upload feature.

Merging Repositories

To merge or promote the artifacts in a staging repository to the managed repository, just click the Merge button in the repository configuration page.

Merge Button

Archiva will check for conflicting artifacts between the two repositories, and list them (if it finds conflicts). The user will be asked to choose between two actions:

  1. Merge All - ignore all conflicting artifacts and perform merging for all.
  2. Merge With Skip - skip all conflicting artifacts and merge only the non-conflicting ones.
Merge Actions

In future, we plan to enhance this by allowing a user to select only specific artifacts to merge.

+
+
+
+ +
+ + + + \ No newline at end of file