These comments refer to Confluence VERSION 2.X ?????
http://confluence.atlassian.com/display/CONF256/HTTP+authentication+with+Seraph
Supported authentication methods
The default Seraph authenticator supports four methods of authentication, as can be seen in the flowchart:
* request parameters: os_username and os_password
* session attribute storing the logged-in user
* cookie storing username and password ('remember me' login)
* HTTP basic authentication via standard headers.
Each method is tried in the order above. A successful login at an earlier method continues without checking the later methods. Failure at one method means continuing with the later methods until all are exhausted. At this point, the user is considered an anonymous user, and treated according to the permissions of an anonymous user in Confluence.
Looking through the source code will show that Seraph supports role-based authentication, but this is only used in Confluence for the /admin/ URL restriction.
Confluence pops up a web form; user enters userid + password; Confluence searches ldap for that user object, then BINDs to ldap as that user. authZ is done via membership in ldap groups. Can co-exist with groups inside Confluence.
Something external to Confluence (web server front-ending the servlet container; plugins in that web server (eg Shibboleth), servlet container configured to do container-based authN) sets the value of the REMOTE_USER variable. This authenticator "trusts" that the external entity has successfully authenticated the browser user, and accepts the user identity presented as the REMOTE_USER value. Can map Shibboleth-delivered attributes to Confluence group names. By default, uses Confluence-resident groups for authZ; see "using ldap groups for authZ, when not using ldap authN".
This is the default mode for the product. Groups are created/managed within Confluence. Users defined within Confluence can be added to Confluence-based groups. Access to spaces + pages can be granted to Confluence-based groups and users.
After authenticating the browser user via ldap, Confluence will enforce authZ by looking at both Ldap-based groups and Confluence-based groups.
(comments from psu) We use the RemoteUserAuthenticator code from Georgetown to authenticate the user using the REMOTE_USER variable.
To enable this and override confluence's built in authenticator, open /var/confluence-2.5.4-std/confluence/WEB-INF/classes/seraph-config.xml and replace the default authenticator of
<authenticator class="com.atlassian.confluence.user.ConfluenceAuthenticator"/>
with
<authenticator class="edu.georgetown.middleware.confluence.RemoteUserAuthenticator"/>
Users and groups are stored within Confluence. Web screens/forms are available to create and manage users and groups. A SOAP-Based provisioning interface can be used byan external provisioning process to manage users and groups.
Confluence provides screens allowing an authorized individual to create and manage groups that are defined within Confluence. These groups can contain users defined within Confluence as well as users described within ldap. The standard screens do not allow a browser user to edit the membership of groups defined within ldap. The standard support does not allow a group to have another group as a member.
http://confluence.atlassian.com/display/CONFEXT/LDAP+Dynamic+Groups+Plugin (managing groups within Confluence; reflecting changes back to ldap)
This plugin will "synch" group memberships between Confluence and ldap. If a change is made to a Confluence-based group, this plugin will synch the change back to ldap.
Over the span of several releases, there have been various approaches to the problem of automatically setting this property. There was a plugin:
Automatically Adding LDAP users to the confluence-users Group http://confluence.atlassian.com/display/DOC/Automatically+Adding+LDAP+users+to+the+confluence-users+Group
but this fell out of synch with Confluence APIs at v2.5.6.
With vXXX, there is an administrator setting that allows granting the "Can Use" permission to members of a group. At Brown, we grant this permission to our ldap resident "Community.ALL" group. Our normal provisioning processes manage the membership of this group, and, thus, the ability to use Confluence.
psu developed this modification:
By default when creating a space, the default ACL only lets the local group "confluence-users" be able to view and modify the new space. Since we use LDAP for authorization and don't want to have a maintain a separate local group, some modification were made to make the default ACL use the LDAP group psu.facstaff.
psu developed this mod:
Not allowing anonymous to edit.
Only registered users are allowed to edit pages. Person must at least be logged in with FPS to make changes.
./conf-webapp/src/main/webapp/spaces/includes/createspace_permissions.vm
Comment out the following like so:
### #if ($permissionHelper.globalAnonymousAccessEnabled)
### #tag( Checkbox "label='create.space.permissions.anonymous'"
### "name='permissionSetter.anonymousCanEdit'"
### "value=permissionSetter.anonymousCanEdit"
### "theme='notable'" )
### #end
Comment out code in ./confluence/conf-webapp/src/main/webapp/template/includes/macros.vm that allows anon to do anything other than view around line 1133.
psu developed a fix for this; However, Atlassian fixed this around v2.5.3.
This page describes the APIs that Confluence exports via SOAP and XML-RPC:
http://confluence.atlassian.com/display/DOC/Remote+API+Specification
It appears that all of the required functionality is available.
psu has developed a patch for this.