Configuring Mura CMS's User Bridge

Configuring Mura CMS's User Bridge


The Plugin Configuration


After installing the User Bridge plugin, I modified the plugin's settings within the configuration page of the plugin itself. (After installation, I was unable to locate the settings and so have referenced the pluginsettings table in the graphic below.) I added the name of the Active Directory group that I wanted to use as the Super Admins group (WEBTEAM) as the Admin Group Mapping.

There is also a Sync Memberships setting, which is set to true. This allows Mura to synchronize the Groups created in Mura with those in Active Directory. Once a user logs in, and they are a member of a group in AD that matches the name of the Group in Mura CMS, that user is granted the privileges that that Mura CMS group has.

Plugin Folder Structure

In the plugins folder, the userbridge directory has an index.cfm and two subdirectories: lib and plugin. Within "lib" there's loginManager.cfc and loginManagerCFScript.cfc. In the plugin folder there's config.cfm, config.xml, and plugin.cfc.

The Login Process




loginManager.cfc contains a function called "login" and is referenced above. One of the variables set is the adminGroup, which pulls the value of WEBTEAM from the Plugin settings.

In order to get an idea of how loginManager.cfc works, I logged events in order to track them:

<cflog file="Mura_User_Bridge"
                    text="Admin user has attempted a log in. #$.event("username")#" >     

This allowed me to track how a user flowed through the login function.

Next we call function lookUpUser and passed in the user's credentials. userStruct.found lets us know whether the user was found by lookUpUser.

More on Function lookUpUser

Function lookUpUser passes in a username and password and runs an LDAP query using CFLDAP. Here's where the legwork I did earlier came into play. Knowing what to pass into the LDAP tag goes a long way into making this work:

<cfldap action="query" name="GetUserInfo" server="myserver" port="myport" attributes="uid,givenname,cn,sn,ou,mail,telephonenumber,homePhone,memberof" start="dc=abc,dc=def" scope="subtree" filter="(&(objectclass=user) (samaccountname=#arguments.username))" username="domain\#arguments.username#" password="#arguments.password#">

Then we populate returnStruct() with the information found in the CFLDAP Attributes. returnStruct.memberships is initially set to "", but then is populated by looping through the GetUserInfo memberOf attribute.

Now back to the login function to loop through the memberships. Since we set syncMemberships to true, we're now looping through them and adding them to rolelist variable. Here's the code:

Populating rolelist
<cfset rsGroups=application.userManager.getPublicGroups($.event('siteID')) />     
    <cfloop query="rsGroups">
        <cfif listFindNoCase(userStruct.memberships,rsGroups.groupname)>
            <cfset rolelist=listappend(rolelist,rsGroups.userID)>

This code checks for the existence of groupnames in Mura with the AD groups the user is a part of. If they are not there, they are added to rolelist.

We set the userBean's groupID to the rolelist, unless the user is a member of the WEBTEAM, and then their groupID is WEBTEAM.

Next we call the getIsNew function, and if they are new, we loop through a custom list of Active Directory groups that I want to have administrative access to Mura's Administrator:

<cfloop list="ADGroup1,ADGroup2,ADGroup3,WEBTEAM" index="local.i">
<cfif listFindNoCase(userStruct.memberships, local.i)>
<cfset local.hasAdminGroup = True />

Therefore, if Joe User is in ADGroup1, then when he logs into Mura Admin, he gets the dashboard, and he will have whatever permissions are granted to ADGroup1 with Mura's Permissions. If he is not in any of the groups, then upon successful login, he gets redirected out of the admin, and onto the home page.

Such integration with AD is a critical component of an Intranet, and I'm glad it's a part of Mura CMS.