So far we have learned how to get users into our Confluence installation. This is very useful but what if your company has its own LDAP server or is already using some other Atlassian products, such as JIRA or Crowd?
Within Confluence we can configure one or more external user directories. A user directory is a place where you store information about users and groups, including some other user information. This information can be the person's full name, e-mail address, or department. When an external user directory is configured, Confluence will also use the directory to authenticate a user.
Confluence has support for the following external directories:
You can add as many external directories as you need. Note that you can change the order of the directories, determining which directory will search first.
When you have more than one directory configured, the order of those directories is important and affects a couple of things within Confluence.
For example:
arthur.dent
exists in both directoriesarthur.dent
is a member of group G1 in the employees directory and group G2 in the customers directoryarthur.dent
only has permissions based on group G1, not G2For example:
arthur.dent
exists in both directoriesarthur.dent
via Confluence's Administration ConsoleWhen using external directories, there are a couple of limitations you should be aware of.
The first limitation you should be aware of depends on the read/write configuration of your external directory. If Confluence can't write to your external directory, or you don't want it to, you have to disable the built-in user management.
To disable management of users and groups within Confluence:
If the built-in user management is disabled, users won't be able to:
Also, administrators won't be able to:
All these features are now delegated to the administration of your external user management and they have to be performed there.
It's not possible to edit, disable, or remove the directory your user belongs to. This precaution is to prevent administrators from locking themselves out of the Confluence, by changing the directory configuration in a way that prevents them from logging in or removing their administration permissions.
In some cases, reordering the directories will change the directory that you're currently using, if your user exists in both directories. This behavior can be used to make changes to existing directories.
Connecting to an LDAP directory server is useful if your users and groups are stored in a corporate directory. When configuring the LDAP directory in Confluence, you can choose to make it Read Only, Read Only with Local Groups, or Read/Write. In the last case, any changes you make to your users and groups in Confluence will reflect in your LDAP directory.
To connect Confluence to an LDAP directory, perform the following steps:
The following are the different settings required for setting up an external user directory:
Setting |
Description |
---|---|
Name |
Enter a descriptive name that will help you identify the LDAP server. For example, |
Directory Type |
Select the type of LDAP server you will connect to. The value you select here will determine the default values for many options on the screen. |
Hostname |
The hostname of your directory server. |
Port |
The port on which your directory server is listening. For example, 389 (default LDAP port), 10398, or 636 (LDAP over SSL). |
Use SSL |
Check this checkbox if the connection to your LDAP server is an SSL connection. |
Username |
The distinguished name of the user that the application will use when connecting to the directory server. For example:
|
Password |
The password of the user specified. |
The Read Only, with Local Groups option is a very powerful configuration and is in many cases the best setup. Users and groups can still be managed in your company's centralized user management system. But you as an administrator still have the option to create new groups and change memberships of those groups, giving you the control you need in Confluence without cluttering your LDAP server. ines
Atlassian Crowd is an application security framework that can handle the authentication and authorization for your web-based applications, which is not just restricted to Confluence or JIRA. With Crowd, it's possible to integrate multiple user directories into one directory and add support for single sign-on and centralized identity management.
Crowd is a very useful option if you have multiple web-based applications and multiple user directories you want to configure, especially if you want to add SSO to those applications as well.
Use the following steps to connect to Crowd:
If you are also running JIRA within your organization, it is possible to use JIRA as user management for Confluence. The advantage of this approach is that your user management system is not in multiple locations, but just in JIRA.
The method of connecting Confluence to JIRA changed in JIRA 4.3 and later. I will assume you will be using JIRA 4.3 or later for this exercise; if you are running an older version of JIRA, you will find more information online at https://confluence.atlassian.com/x/hg6zDQ.
To connect Confluence to JIRA 4.3 or later, perform the following steps:
192.168.10.42
.
Settings |
Description |
---|---|
Name |
A descriptive name of your JIRA server. For example:
|
Server URL |
The web address of your JIRA server. Examples:
|
Application Name |
The name to authenticate Confluence with JIRA. This is the application name you created when setting up JIRA for Confluence. |
Application Password |
The password for the configured application name. This must be the same as the password you have registered in JIRA for Confluence. |
18.117.77.158