 -----
 Configuration     
 -----
 -----
 23 May 2014
 -----

~~ Licensed to the Apache Software Foundation (ASF) under one
~~ or more contributor license agreements.  See the NOTICE file
~~ distributed with this work for additional information
~~ regarding copyright ownership.  The ASF licenses this file
~~ to you under the Apache License, Version 2.0 (the
~~ "License"); you may not use this file except in compliance
~~ with the License.  You may obtain a copy of the License at
~~
~~   http://www.apache.org/licenses/LICENSE-2.0
~~
~~ Unless required by applicable law or agreed to in writing,
~~ software distributed under the License is distributed on an
~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
~~ KIND, either express or implied.  See the License for the
~~ specific language governing permissions and limitations
~~ under the License.

~~ NOTE: For help with the syntax of this file, see:
~~ http://maven.apache.org/guides/mini/guide-apt-format.html

Redback Configuration

  Configuration in Redback is governed by a plexus configuration setup making
use of properties files.  Below is a listing of all of the available configuration options along with default values and notes on what they are where applicable.

%{toc}
  
* Configuration File Locations

  Configuration file location can depend on the application that is embedding Redback.  Since Redback is currently built up off of Plexus, it would be ideal to check out the application.xml of the relevant application and look for an entry similar to the following.

--------------------------------------------

  <bean name="userConfiguration" class="org.apache.archiva.redback.configuration.DefaultUserConfiguration"
      init-method="initialize">
    <property name="configs">
      <list>
        <value>src/test/resources/security.properties</value>
      </list>
    </property>

    <property name="registry" ref="registry#commons-configuration"/>

  </bean>

--------------------------------------------

* Configuration Options

** Application Configuration

  * <<<application.timestamp=EEE d MMM yyyy HH:mm:ss Z>>>

  * <<<application.url=http://myurl.mycompany.com>>>
  
    * Set the application base URL. The default is to derive it from the HTTP request

** JDBC Setup

  By default Redback uses Apache Derby for persistence of user and role
information.  This can be configured with the following options.

  * <<<jdbc.driver.name=org.apache.derby.jdbc.EmbeddedDriver>>>

  * <<<jdbc.url=jdbc:derby:${plexus.home}/database;create=true>>>

  * <<<jdbc.username=sa>>>

  * <<<jdbc.password=>>>

  []

  By default Redback uses Apache Derby for persistence of user and role information.  This can be configured with the following options.

  <<Note:>> If you are using MySQL as your database, the database will not be populated if the encoding is initially set to UTF-8. As a workaround, set the database to UTF-8 encoding after it has been populated. See {{{http://jira.codehaus.org/browse/REDBACK-267} REDBACK-267}} for more details.


** Email Settings

  * <<<email.jndiSessionName=java:comp/env/mail/Session>>>
  
  * <<<email.smtp.host=localhost>>>

  * <<<email.smtp.port=25>>>

  * <<<email.smtp.ssl.enabled=false>>>

  * <<<email.smtp.tls.enabled=false>>>
 
  * <<<email.smtp.username=>>>

  * <<<email.smtp.password=>>>

  * <<<email.from.address=${user.name}@localhost>>>
  
    * All emails sent by the system will be from the following address

  * <<<email.from.name=Unconfigured Username>>>

  * <<<email.validation.required=true>>>

    * If all email addresses (from new user registration) require an account validation email. 

  * <<<email.validation.timeout=2880>>>

    * Timeout (in minutes) for the key generated for an email validation to remain valid.

    * 2880 minutes = 48 hours

  * <<<email.validation.subject=Welcome>>>

  * <<<email.feedback.path=/feedback.action>>>

    * Get the Feedback to use for any outgoing emails.

    * Feedback path starts with a "/" it is appended to the end of the value provided in application.url.  This value can be in the format/syntax of "/feedback.action" or even "mailto:feedback@application.com"
 

** Auto Login Settings

  * <<<security.rememberme.enabled=true>>>

  * <<<security.rememberme.timeout=365>>>

    * Timeout in days

  * <<<security.signon.timeout=30>>>

    * Single Sign On
    
    * Timeout is in minutes

** Default Username Values

  * <<<redback.default.admin=admin>>>

    * name for the admin user, by default this is 'admin' and can not easily be changed after the fact at this point.  However any number of people may be assigned full administrator roles.

  * <<<redback.default.guest=guest>>> (currently guest is an hardcoded value so not possible to configure it)

    * name of the guest user


** Security Policies

  * <<<security.policy.password.encoder=>>>

  * <<<security.policy.password.previous.count=6>>>

  * <<<security.policy.password.expiration.enabled=true>>>

  * <<<security.policy.password.expiration.days=90>>>

  * <<<security.policy.password.expiration.notify.days=10>>>

  * <<<security.policy.allowed.login.attempt=10>>>

  * <<<security.policy.strict.enforcement.enabled=true>>>
  
    * turn off the perclick enforcement of various security policies, slightly more heavyweight since it will ensure that the User object on each click is up to date

  * <<<security.policy.strict.force.password.change.enabled=true>>>

    * forces the user to change their password immediately should their account be flagged for a password change.

  * security.policy.unlockable.accounts

    * can be specified multiple times to ensure that password policies never lock the specified account(s) (eg. security.policy.unlockable.accounts=guest )

** Password Rules

  * <<<security.policy.password.rule.alphanumeric.enabled=false>>>

  * <<<security.policy.password.rule.alphacount.enabled=true>>>

  * <<<security.policy.password.rule.alphacount.minimum=1>>>

  * <<<security.policy.password.rule.characterlength.enabled=true>>>

  * <<<security.policy.password.rule.characterlength.minimum=1>>>

  * <<<security.policy.password.rule.characterlength.maximum=24>>>

  * <<<security.policy.password.rule.musthave.enabled=true>>>

  * <<<security.policy.password.rule.numericalcount.enabled=true>>>

  * <<<security.policy.password.rule.numericalcount.minimum=1>>>

  * <<<security.policy.password.rule.reuse.enabled=true>>>

  * <<<security.policy.password.rule.nowhitespace.enabled=true>>>

** LDAP settings

  Ldap can be used as a readonly user manager, however the role assignment is still managed entirely within the given database store.  This should be fixed in the future sometime but likely not before ldap is switched over as the default user and role store entirely.

  * <<<ldap.user.store.enabled=false>>>

  * <<<ldap.bind.authenticator.enabled=false>>>

*** ldap options for configuration via properties file

  * <<<ldap.config.hostname=>>>

  * <<<ldap.config.port=>>>

  * <<<ldap.config.base.dn=>>>

  * <<<ldap.config.context.factory=>>>

  * <<<ldap.config.bind.dn=>>>

  * <<<ldap.config.password=>>>
 
  * <<<ldap.config.authentication.method=>>>

  * <<<ldap.config.groups.class=>>> object class for groups (default: groupOfUniqueNames)

  * <<<ldap.config.groups.base.dn= basedn>>> for groups, dn with list of groups ( dc=archiva,dc=apache,dc=org ) (if empty default will be ldap.config.base.dn)

  * <<<ldap.config.groups.role.*(ldap group)=*(roles)>>> (mapping ldap group <-> redback roles comma separated) (example: ldap.config.groups.role.archiva-admin=Archiva System Administrator, Foo)

  * <<<ldap.config.writable=true/false>>> will write datas to ldap (default false)

  * <<<ldap.config.groups.use.rolename=true/false>>> will create/use groups in ldap with default role if no group<->role mapping found (default false)

  * <<<ldap.config.user.attribute=>>> attribute name to use for user (default uid=)

** User Manager Implementation(s) to use

  * <<<user.manager.impl=cached>>> (since 1.4-M4: Archiva support more than one value comma separated)
  
    * valid values for realistic usage are 'cached' and then further configuring the cached instance to use another underlying user manager like ldap or the jdo one which is used by default.  Placing 'ldap' here will check with the ldap system for a fair amount of checks and would likely be a performance issue

** RBAC Manager Implementation(s) to use

    * <<<rbac.manager.impl=cached>>> (since 1.4-M4: Archiva support more than one value comma separated)

** REST security settings

*** Cross Site Request Forgery (CSRF) Prevention

  There are multiple checks implemented to prevent CSRF attacks from other sides that are opened in the same browser.
  If you use the REST services from non-Browser clients or very old Browser versions you may need to deactivate some
  of these checks. If you deactivate these checks your archiva site will be more vulnerable to these attacks.

  * <<<rest.csrffilter.enabled=true>>>

    * Enable/disable the filter for CSRF prevention. Possible values: true, false

  * <<<rest.baseUrl=>>>

    * Set the base URL to which the Origin/Referer header are matched against. If it's empty, the URL is determined dynamically.

  * <<<rest.csrffilter.absentorigin.deny=true>>>

    * Defines what happens, if the client request does not contain a Origin or Referer header. This may happen with
      native REST clients. Browsers normally add these headers to the request, if it is initiated from another site.
      Possible values: true, false

  * <<<rest.csrffilter.disableTokenValidation=false>>>

    * Token validation means, that each REST request must send a validation token that is returned during the first login.
      If you have REST clients that cannot send this token you may have to disable this feature. Possible values: true, false