Flux CMS DevBlog

I just committed an authentication module, which authenticates against a Confluence server via the SOAP interface instead of just the internal database. This allows us to enable access to a Flux CMS installation for everyone at Liip without having to actually create all those 20+ accounts (and everyone can use the same password on Jira, Confluence and those CMS installations)

The module still uses the internal database, if the authentication via Confluence fails. Therefore you can have additional users in the local database, which do not have a confluence account. Additionally, the module creates a local CMS user account, if someone with a Confluence account first logs in and saves all the needed CMS information there, so that Confluence is really only used for authentication, later needed additional CMS information is still maintained and saved locally.

To use this module, just check out the latest 1.5-dev or HEAD version of the CMS and change/add the following to your config.xml

<permm type="permm">
  <authModule>
    <type>confluence</type>
      <wsdlurl>http://your.wiki.com/rpc/soap-axis/confluenceservice-v1?wsdl</wsdlurl>
      <allowedGroup>internal-developers</allowedGroup>
      <!-- all the other options from the standard authModule -->

The allowedGroup option tells the plugin in which group a Confluence account has to be for getting access to the CMS

This plugin can also serve as a template, if you want to authenticate against a similar service but still use the default one as a fallback

Addition: The SOAP extension has to be enabled for this to work.

Update: In at least Confluence 2.4, the allowedGroup check does not work for non-admin confluence users, therefore I added a new option to config.xml

<allowedSpace>INTERN</allowedSpace>

This option checks, if the current user can see that particular space. As you can give rights on a per space base, this is basically the same as the allowedGroup option, just configured differently on the confluence side.