SharePoint Connector Security Review

This page describes how security is used within the SharePoint connector as well as corner cases with the security design.

Overview

Both SharePoint and Confluence use security to ensure that confidential information is not available to non-priviledged individuals. This is done through authentication and authorization.

Authentication - Establishing that a person is who they say they are. This is typically done through a login (username and password). Depending on the setup, this may involve transmitting passwords to perform the authentication.

Authorization - Allowing access to only those resources the individual is permitted to use or see. Authorization assumes that Authenication has already occurred.

Security Trimming - The act of trimming out items that an individual is not permitted to see. This can apply to links to wiki pages that are not accessible for the current user, SharePoint lists, etc.

Within SharePoint you can lock down some sites or lists such that only certain users have access to them. Within Confluence you can lock down some spaces or pages such that only certain users have access to them.

Confluence Plugin

The Confluence plugin obtains access to SharePoint through an administrative account defined on the SharePoint Admin page within Confluence. This account uses web services to retrieve SharePoint list and document library information to display to the user within a Confluence wiki page. This account is typically authorized to access more SharePoint information than a typical user.

When retrieving list and document library information, the current Confluence user is provided to SharePoint. This user must exist as an authorized user within the target SharePoint site and also must have read access to the requested list/library. If not, no list/library content is shown.

All links within SharePoint list/library items that are shown within a Confluence wiki page reference SharePoint directly. Therefore the security around how these links behave (i.e., opening a Word document in edit mode) is the same as if these links are shown within a SharePoint page.

SharePoint Web Parts

The SharePoint web parts obtain access to Confluence either through an administrative account (non-SSO) or through a SSO account as defined on the Confluence Administrative Settings page within SharePoint. The account uses web services to retrieve Confluence page hierarchy and contents to display to the user within a web part. The administrative account is typically authorized to access more Confluence pages than a typical user.

When retrieving page content or hierarchy, the current SharePoint user is provivded to Confluence. The current user is defined as the SharePoint user (without any domain name) when not using Single Sign-on (SSO), or this is the mapped SSO user when using SSO. This user must exist as an authorized user within the target Confluence space. For the Confluence Page web part the user must also have view access to the requested Confluence page. If not, the page contents are not shown. For the Confluence Pages Tree View web part, only those pages the user can view are shown (the rest are security trimmed).

SharePoint Search

If you are using MOSS, the SharePoint Connector can be configured to have SharePoint crawl Confluence content using an administrative account. The administrative account is typically authorized to access more Confluence pages than a typical user, therefore the index likely has data that should not be accessible to everyone.

Because web site crawls cannot retrieve Access Control List (ACL) data the security trimming must be done when a user performs a query. Thus, when a search is performed by a user, a security trimmer is activated which verifies that the user has access to view each URL (i.e., Confluence Page) that would be shown as a search result. The current user is defined as the SharePoint username (without the domain) if Single Sign-on (SSO) is not being used. If SSO is being used, the current user is the mapped SSO user for the current SharePoint user. Only those URLs that the current user has acces to within Confluence are shown. This is important because summary text is shown in the search result that could display confidential information.

Securely Transmitting Passwords

Confluence and SharePoint are two loosely coupled systems and using them together involves passwords being transmitted over the network in certain circumstances. Care should be taken to ensure that these passwords cannot be compromised.

If you are not using secure sockets, you should understand when passwords are sent over the wire. When reviewing the list below, consider the network involved. For example, a client browser may hit a SharePoint or Confluence server by going over the Internet where communications can be compromised. However, you may require all access to be through a VPN in which case you probably only need to be concerned about hackers that have gained access to your internal network. Server to server communications is likely kept within your internal network so you probably only need to be concerned about hackers with internal access as well.

Confluence credentials when using Microsoft SSO

On Authentication Configuration there is an option to use Microsoft SSO to maintain single sign-on between SharePoint and Confluence. This involves storing the Confluence credentials within a secure database that SharePoint has access to. Then SharePoint will use these credentials to gain access to Confluence. With the Microsoft SSO option, the following occurs:

• On every request to a SharePoint page that contains either of the Confluence web parts the current Confluence username and password goes from the SharePoint server to the client browser then from the client browser to the Confluence server.
  • This is done to establish a session with Confluence.
  • Note that the username and password are not stored within the page source of the browser.
• In addition, on every page request to a SharePoint page that contains either of the Confluence web parts the current Confluence username and password goes from the SharePoint server to the Confluence server.
• When testing the Confluence configuration from the Confluence administrative page within SharePoint, the Confluence username and password go from the SharePoint server to the Confluence server.
• When a user saves their Confluence credentials in Microsoft SSO (they are prompted the first time they see a web Confluence web part in SharePoint), the Confluence username and password go from the client browser to the SharePoint server.
• When performing a search within SharePoint that has Confluence search results (before they are security trimmed out), the current user's Confluence username and password go from the SharePoint server to the Confluence server.

Confluence credentials when not using Microsoft SSO

Without the Microsoft SSO option, the following occurs:

• On every request to a SharePoint page that contains either of the Confluence web parts the Confluence administrative username and password goes from the SharePoint server to Confluence server.
• When saving the Confluence administrative username and password in the Confluence administrative page within SharePoint, the Confluence adminisrative username and password go from the client browser to the SharePoint server.
• When testing the Confluence configuration from the Confluence administrative page within SharePoint the Confluence administrative username and password go from the SharePoint server to the Confluence server. If the settings were not yet saved, the username and password also go from the client browser to the SharePoint server.
• When performing a search within SharePoint that has Confluence search results (before they are security trimmed out), the Confluence administrative username and password go from the SharePoint server to the Confluence server.

Confluence credentials if SharePoint is indexing Confluence content

If SharePoint is indexing Confluence content for integrated search, the following occurs when SharePoint is crawling Confluence:

• A Confluence administrative (crawl) account username and password are sent from the SharePoint server to the Confluence server.

SharePoint credentials if SharePoint is using Basic authentication

All communication from Confluence to SharePoint currently assumes NTLM or Basic authentication for SharePoint. NTLM like SSL is fairly secure (both involve encryption), but Basic authentication sends credentials as clear text over the wire. The following applies to NTLM as well as Basic authentication, but should be understood carefully if using Basic authentication.

• On every page request to a Confluence page that contains the sp-list macro, the SharePoint administrative username and password are sent from the Confluence server to the SharePoint server.
• When testing the SharePoint administrative page within Confluence, the SharePoint administrative username and password sent from the Confluence server to the SharePoint server.

SharePoint credentials regardless of the type of SharePoint authentication

Regardless of the type of authentication SharePoint is using (NTLM/Basic), the following occurs:

• When saving or testing the SharePoint administrative username and password in the SharePoint administrative page within Confluence, the SharePoint administrative username and password go from the client browser to the Confluence server.