Accounts: Configuration

Accounts: Configuration

Step ${str(active + 1)}: ${steps[active].label}

Objective for setting Authentication Options

Decide, whether to use HTTP authentication (Trac default) or a HTML login form provided by AccountManagerPlugin.

After initial login Trac sessions are authenticated per request based on browser cookies. Therefor a number of options provide control over some critical browser cookie properties.

Provider-agnostic Authentication Options

Adapt to careless username typing, where casing does not matter, like on Windows. Potentially troublesome, because case matters for Trac permission assignment lookup anyway.

Potentially troublesome for users with dynamic IP adress, but disregarded for persistent sessions.

Required, if the Trac instance is only accessible through HTTPS.

Determines how long the browser will cache authentication information, and therefore, after how much inactivity a user will have to log in again. Default (0 s) makes cookie expire at browsing sessions end.

Authentication Front-end

You can still manage some password stores with AccountManagerPlugin, if you configure them in the next step.

AccountManagerPlugin provides a custom version of the LoginModule accompanied by a form-based HTML login page.

If you enable this feature, you'll want to review and adjust some more options related to session authentication. Note, that AccountManagerPlugin's LoginModule changes the default lifetime of authentication cookies to 30 days.

AccountManagerPlugin Authentication Options

If enabled, links to

  • Lost password/Password reset
  • Registration for new users

that normally reside in Trac's meta-navigation bar, will appear inside the login form. CSS styling allows further customization of the login prompt.

This is, user checks a "Remember Me" checkbox in the AccountManagerPlugin login form and, next time he visits the site within 30 days, he'll be remembered and authenticated automatically.

Driving a refresh process to decrease vulnerability of long-lasting sessions. Zero means never.

This enables AccountManagerPlugin's authentication data distribution to Trac instances with matching cookie path. Set this to a common base path of several Trac instances to share the cookie, providing a cheap Single-Sign-On experience.

Step ${str(active + 1)}: ${steps[active].label} Password store icon

Objective for configuring a Password Store

AccountManagerPlugin manages user credentials in a modular back-end providing access to at least one password store.

Initial Authentication Back-end selection

The SessionStore implements password storage in Trac db table 'session_attributes'. Its the default choice mainly for avoiding additional dependencies like directory and file permissions.

While great to resolve some concurrent access issues too, this password store has shortcomings as well. Notably it does not support seamless hash type migration, and its no candidate for shared use by multiple Trac instances or even by applications beyond Trac.

Details (Preview)
$init_store_hint.db

Please apply these default options first. You'll be able to change values afterwards.

AccountManagerPlugin includes native support for common Apache file formats 'htpasswd' and 'htdigest' as well as support for reading svnserve's password file format.

You may use the same file for several Trac environments. Note that setting appropriate directory and file permissions is crucial for these stores, but not covered by this configuration wizard.

Details (Preview)
$init_store_hint.htdigest

Please apply these default options first. You'll be able to change values afterwards.

Details (Preview)
$init_store_hint.htpasswd

Please apply these default options first. You'll be able to change values afterwards.

Details (Preview)
$init_store_hint.svn_file

Please apply these default options first. You'll be able to change values afterwards.

AccountManagerPlugin enables use of standard HTTP-Auth by its HttpAuthStore component. Both Basic and Digest authentication challenges are supported.

In addition to being read-only this password store does not even support listing users for obvious reasons.

Details (Preview)
$init_store_hint.http

Please apply these default options first. You'll be able to change values afterwards.

AccountManagerPlugin's modular password store concept encourages creation of more ways to provide user credential beyond the natively supported stores. While specific setup assistance for these 3rd-party authentication providers is not implemented, you may fill-in approprate configuration details for an already installed component below.

Configuration

Type the custom configuration options as provided by that components documentation and apply it.

Password Store Configuration

All enabled stores are listed below, but most won't work at all without additional configuration.
Currently configured: ${', '.join(password_store)}

This is an experts-only type of store configuration.

Required disabled component(s): ${', '.join(disabled_store)}

Select one or more stores and configure related options. Concurrent use of multiple password stores is supported too.

Password stores are queried in turn, so order matters.

$option.doc

Use it after changing hash type or to migrate to a new primary password store.

The update will run only once. Restarting the procedure for all accounts allows to propagate subsequent changes.

Step ${str(active + 1)}: ${steps[active].label} Password refresh icon

Objective for Password Policy rules

While AccountManagerPlugin does not enforce password rules in general, there are some other ways to alter password handling.

It relies on a working email sender for Trac, supporting both TracAnnouncer and TracNotification.

These passwords are used as alternative passwords on request.

Step ${str(active + 1)}: ${steps[active].label} Account approval icon

Objective for Account Registration and Verification rules

You may require administrative approval of new accounts for the user registration process. The ability to immediately ban existing accounts is another, related but independed feature.

Checks to use for validating Registration requests

All checks provided by AccountManagerPlugin are enabled per default, but some are configurable on their own.
Currently configured: ${', '.join(register_check)}

Checks like BotTrapCheck won't work at all without additional configuration.

Required disabled component(s): ${', '.join(disabled_check)}

Select one or more checks and configure related options. Concurrent use of multiple registration checks is encouraged.

Checks are applied in turn, so order matters. Note that some checks are used to validate admin user actions too.

${safe_wiki_to_html(context, section.doc)}

$option.doc

Other Account Policy options

For admin notification on registration time it relies on a working email sender for Trac, supporting both TracAnnouncer and TracNotification.

For sending a verificaton token to the user it relies on a working email sender for Trac, supporting both TracAnnouncer and TracNotification.

Step ${str(active + 1)}: ${steps[active].label} Account guard icon

Objective for Account Protection rules

Passwords are often not constructed as carefully as they should be. And even a strong passphrase could be sift out, if an attacker is able to test millions of variants in hours, if not seconds. Firewalls and full-featured web-servers already offer sophisticated protection, if one can afford them, handle their installation, configuration and maintenance.

The AccountGuard component is another option. It is an add-on to AccountManagerPlugin's own LoginModule and provides account protection by discouraging brute-force login attempts.

AccountManagerPlugin's LoginModule is disabled.

Lock user account after the specified number of failed attempts. Value zero means no limit.

Zero means unlimited lock time here.

Extend user account lock duration incrementally. It uses logarithmic calculation with the factor as exponent, accepting decimal numbers >= 1.

Lock time will grow for any value > 1, if the failure happens before lock expiration. I.e. value '2' means

  • double lock time after 2nd failure,
  • four times the initial lock time after 3rd,
  • eight times as long after 4th failure, etc.

At any time after lock expiration a login failure will just trigger a lock and set a new lock timeout, but not extend the total lock duration.

This is relevant only with a progression factor > 1.

Step ${str(active + 1)}: ${steps[active].label}

Objective for additional preparation

Enable yourself to proceed beyond this initial setup.

Initial Admin Account

Add Admin Account:

The user will get TRAC_ADMIN assigned, that inherits all available permissions. One such account is required to configure Trac via the admin web-UI. Create and manage more limitted admin accounts as well as actual user accounts on your own later via the Accounts admin panel.

In detail: AccountManagerPlugin requires ACCTMGR_USER_ADMIN for regular user administration, ACCTMGR_CONFIG_ADMIN for viewing these pages and changing the configuration later. Both are inherited by ACCTMGR_ADMIN permission. To assign permissions you'll need PERMISSION_GRANT inherited by PERMISSION_ADMIN too.

Only lowercase usernames allowed

Please take care, that the username is known by the HTTP authentication provider.

Please take care for a valid username, because no configured password store supports creating a new account.

Check-up

Please resolve all issues marked as critical.

By now you did almost finish AccountManagerPlugin configuration, but any changes are temporary yet. Please test and adjust the configuration as required, or cancel to revert all changes. Apply settings to trac.ini only if you really want to preserve them permanently.

Details (Preview)
[$section]
${option[0]} = ${option[1]}
${option[0]} = ${option[1]}