This page last changed on Sep 14, 2006 by david.soul@atlassian.com.

Looking for help with your user management configuration? See Requesting External User Management Support.

Components of user management

  1. Authentication - determining what user identity is making a request to Confluence
  2. User management - storing and retrieving core information about users
  3. Group membership - storing and retrieving groups, and group membership
  4. Profile information - providing metadata associated with users.

It's important to understand that these are separate components of the user management system. The term LDAP integration is not really meaningful, because you could use LDAP repository for any or all of the above tasks.

For example, in OSUser authentication can be performed against different repository to that used for group membership queries. In AtlassianUser/Polis, authentication and group membership can be retrieved from LDAP, but profile information is still stored in the Confluence database.

Authentication

Seraph

Almost all authentication in Confluence (and JIRA) is performed through Seraph, Atlasian's open source web authentication framework. The goal of seraph is to provide a simple, extensible authentication system that we can use on any application server.

Seraph is implemented as a servlet filter. Its sole job is, given a web request, to associate that request with a particular user (or no user if the request is anonymous). It supports several methods of authentication, including HTTP Basic Authentication, form-based authentication, and looking up credentials already stored in the user's session.

Seraph performs no user management itself. It merely checks the credentials of the incoming request, and delegates any user-management functions (looking up a user, checking a user's password is correct) to Confluence's user-management subsystem.

If you were looking to integrate Confluence with a Single Sign-On (SSO) infrastructure, you would do so by writing a custom Seraph authenticator (and in fact, many customers have done so).

XML-RPC and SOAP Authentication

Authentication for requests performed by the remote API do not go through Seraph, so they can't take advantage of Seraph authenticators. XML-RPC and SOAP authentication requests are checked directly against the user-management framework, and tokens are assigned directly by the remote API subsystem.

Password Authentication and User Management

By default, password authentication is delegated from Seraph to the user management system. This is not necessary, however. Single Sign-On systems may have no password authentication at all, and get all the necessary credentials from the SSO provider.

Confluence user management frameworks

The rest of this document covers the user management frameworks used by Confluence: AtlassianUser and OSUser.

AtlassianUser

AtlassianUser is a new user and group management framework developed by Atlassian, and is the core framework used in Confluence since version 2.1. AtlassianUser was developed with the following goals in mind:

  • Support LDAP as a fully functional repository for authentication, group management and profile information (profile information not yet implemented).
  • Compatibility with both JIRA and Confluence (JIRA support not yet implemented).
  • Be simple to configure (partially complete, needs better migration and UI integration).

We plan to release AtlassianUser as an open source project some time in the future (probably under the name Polis), but right now the system is still under heavy development inside Atlassian.

AtlassianUser provides user, group and profile management services to Confluence. It does so by delegating tasks to configurable repositories. Multiple repositories can be configured, so for example Confluence can draw user information from both the database _and _ an LDAP server.

Default configuration

By default, Confluence's AtlassianUser configuration delegates all user, group, profile and password authentication to OSUser. This is done to minimise the impact of the migration from OSUser to AtlassianUser. At some time in the future, we will migrate all user management to AtlassianUser's native providers, and the OSUser delegation will only be needed by customers who are still relying on the OSUser/JIRA bridge, or the old-style OSUser LDAP support.

Configuration of AtlassianUser is done through the atlassian-user.xml file (in Confluence 2.2+) or atlassianUserContext.xml (in Confluence 2.1).

Database (Hibernate) Support

AtlassianUser can store user, group and profile data directly in Confluence's database. This will be the default behaviour for Confluence once we have completed the migration from OSUser.

LDAP support

AtlassianUser currently supports password authentication, user management and group management with an LDAP server. There are instructions on how to configure AtlassianUser LDAP integration.

At this point, only read-only access to LDAP is planned. Java's JNDI-LDAP interface does not support updating an LDAP repository, and the administration tools that come with LDAP servers such as Microsoft Active Directory are generally comprehensive and already available in enterprise IT departments.

JIRA integration?

AtlassianUser will not support delegating Confluence user management to JIRA. Instead, our goal is to implement AtlassianUser as the JIRA user management framework as well. Once this is done, both Confluence and JIRA can use the same LDAP server for their authentication and group management.

OSUser

OpenSymphony User was Confluence's core user management framework up until it was replaced by AtlassianUser in version 2.1. OSUser is still heavily used within Confluence through AtlassianUser's OSUser repositories, and for the time being remains the default user, group and profile repository for Confluence.

OSUser is also built around the model of pluggable providers, but its LDAP support is limited.

OSUser Database (Hibernate) Providers

In its default configuration, Confluence's OSUser providers store a list of users and groups together with profile information in tables in the Confluence database:

  • os_user (authentication)
  • os_group (group membership)
  • os_user_group (group membership)
  • os_propertyentry (profile information)

The hashed password in the os_user table is used to authenticate the user unless LDAP support is enabled. The os_user_group table is queries for group membership information.

OSUser configuration is controlled through the osuser.xml file.

LDAP support

OSUser only supports authentication against an LDAP server. That is, you can check user passwords against LDAP, but all other user information must be shadowed in the Confluence database. There are instructions on how to configure OSUser LDAP authentication.

If you need support for LDAP user information or group membership as well, AtlassianUser should be used instead (see above).

Delegating user management to JIRA

Confluence can use OSUser to retrieve information for authentication, group membership and profile information from JIRA.

If you look at the discussion of OSUser's implementation above, you can see how this can works pretty easily. A data source to JIRA database is configured in Confluence which lets Confluence read directly from JIRA's os_* tables. For example, when a user is created in JIRA, the username and password goes in the os_user table in the JIRA database. Confluence looks at the same table in the JIRA database to authenticate the user.

Access to the JIRA database is read-only. For this reason, Confluence maintains a subset of the user's profile information (things like last login time and user preferences that Confluence needs to be able to modify) locally in the Confluence database.

There are instructions on how to configure OSUser delegation to JIRA.

Nice summary!

Posted by bob.swift@lakeviewtech.com at May 29, 2006 08:52
Document generated by Confluence on Mar 22, 2007 20:55