30 March 2009
Prior experience with the ColdFusion Administrator will be helpful.
Update: Since this article was written (in 2009, for ColdFusion 8), please note an important and beneficial change in ColdFusion regarding this feature. As of ColdFusion 9, the User Manager feature is now available in the Standard edition of ColdFusion, not just Enterprise as was the case in ColdFusion 8.
ColdFusion 8 Enterprise offers a powerful new feature that you may have missed: multiple user access for the ColdFusion Administrator. As opposed to the traditional "one ring to rule them all" single Admin password, this new feature supports separate user names (and corresponding passwords). More important, for each user name you can selectively grant access to different Administrator features, including the new Server Monitor, the Administrator API, and more.
This same multiple user functionality also extends to Remote Development Services (RDS) access, which works with code editors like Dreamweaver, HomeSite+, ColdFusion Studio, and Eclipse with the Adobe ColdFusion Extensions for Eclipse. If RDS is enabled in ColdFusion, authenticated users can access the server using special features within these editors to obtain information from the server. For example, they can determine what data sources exist, query them, build code based on them, and more. RDS also enables access from within the editors to files on the server (even remotely) over HTTP, as an alternative to FTP. Nonetheless, many have long lamented that there has been only one RDS password definable per server, to be shared by all developers. That one password gave full access to all data sources and files on the entire server.
With ColdFusion 8 Enterprise (and the Developer edition), though, these limitations are now lifted. You can, of course, continue to use just one admin and/or one RDS password (or none at all, though that's definitely inappropriate for a production server or any public server). If, however, you're responsible for a ColdFusion server accessed by many people who need Administrator (or Monitor or Admin API) privileges, or you have many developers who need to use RDS, the new multiple user support can be a valuable enhancement. (ColdFusion 8 Standard, it should be noted, continues to offer only a single Administrator and/or RDS password.)
Those who have used ColdFusion for many years may recognize that this is actually a return of functionality that once existed. ColdFusion 4 and 5 offered similar functionality, but that previous implementation relied upon an embedded security product called Netegrity SiteMinder, which was not included as of ColdFusion MX 6. The new multiple user functionality in ColdFusion 8 Enterprise (and the Developer edition) is instead built upon underlying Java security.
This article introduces the new multiple user feature for both the Administrator and RDS. After introducing each topic and showing how to configure it, an example is provided to illustrate its use.
To enable support for multiple users, you first need to change ColdFusion's default operation of having a single Administrator password (or no password, if you have enabled that option.) To make this change, access the Administrator page within the Security section of the ColdFusion Administrator, and then select the Separate User Name And Password Authentication (Allows Multiple Users) option (see Figure 1).
When you click Submit Changes, the setting will take effect immediately (no restart is required).
The single password (if it had been enabled) will remain in effect, but it is important to note that you will now need to use the user name "admin" to login to the Administrator (using the same password entered during installation, or as changed in the Root Administrator Password field on this page).
There is a security concern to consider: as you add new users, keep in mind that the original password remains in effect for the "admin" user name. You can change that password on this screen, even after enabling multiple users. If you want to change the default user name to something other than "admin", however, there is no interface option for doing that. It can be changed by editing a configuration file. For more information, see this Adobe TechNote.
To create new user name/password pairs, select Security > User Manager from the left navigation pane to open the User Manager. Figure 2 shows the page in its initial state, before any user name/password pairs have been added (you won't see the default Admin user name, but it does exist). If there were existing defined users, they would be listed here. You could click a user name to edit it, and use the page shown in Figure 3 to make changes.
Click Add User, and on the page that appears enter a new unique user name and password (see Figure 3). You can also use this page to grant access to the Administrator, Administrator API, and RDS.
When enabling multiple user access to the Administrator, you can choose to enable access to the Administrator and Admin API, or just the Admin API (you cannot enable just the Administrator and not the API.) You can also specify the user's allowed roles—in other words, what pages in the Administrator (or corresponding features in the Admin API) that the user is allowed to access. Select one or more roles from the Prohibited Roles list (use Control-click to select additional individual roles, or Shift-click to select multiple contiguous roles) and click the button labeled "<<"to move those roles to the Allowed Roles list.
Important note: Be sure to define at least some role for a new user. The default is to have no allowed roles. If you don't choose any roles for a new user, the new user would be able to access only the User Manager page itself, and even then they would only be able to change their own password. (The default "admin" user name would still have full access to all roles, so you can log in with that name to make any needed corrections to a new user's roles.)
The list of roles is presented in alphabetical order, with phrases corresponding to sections and pages within the Administrator. While there's a role corresponding to nearly every page, there are some instances where an entire section is represented (such as "Event Gateway" or "Enterprise Manager"), and others where some but not all pages in a section are available as roles (such as the "Server Settings" and "Security" sections).
The bottom of the add/edit user page shown in Figure 3 is used to select an available sandbox to be associated with the user. This sandbox feature is related primarily to creating multiple RDS users, discussed later in this article. Note, however, that if you want to enable use of the Administrator API, you must not restrict access to the CFIDE/adminapi directory in a sandbox.
If you change the pages to which a user is allowed access while that user is logged in to the Administrator, the changes take effect only after the user logs out, and then logs in again.
As a final step, you'll need to click Add User on the add/edit user page to create the new user.
While the multiple user feature is useful for granting different users access to different parts of the Administrator (or Admin API), there is no provision to limit what they may see on their permitted pages. For instance, you can give a user access to the page for creating/editing data sources, but there is no mechanism to control what data sources that user can see (or edit or create)–they can access all data sources. Further, there's no connection between the sandbox feature (discussed later, for RDS) and this. Even if a sandbox can access only one data source, and this user is assigned to the sandbox, they will still see all data sources.
Some may consider this a limitation in the usefulness of this multiple user feature. In many environments, however, the feature is still useful for spreading the workload of Administrator configuration among multiple users, such as in a corporate intranet environment where multiple developers may be trusted with being able to see/define/edit all data sources, and so on.
Furthermore, when each user has their own user name and password for accessing the Administrator, if they leave or are reassigned from their position, their user name can be removed and they will be denied further access. In contrast, when using a single password, you would need to change the password and communicate it to all the users sharing it, which is an inconvenience to the other users and increases the risk of exposing the changed password to unauthorized users.
Consider the following real-world example of adding a new administrator user with access to the Server Monitor. Figure 4 shows such a user (named Admin2) would be added using the User Manager, with Server Monitoring added to the Allowed Roles list.
After creating this user, if you were to log out and login using that user name (admin2, in the example above), the Administrator will let you see only the pages to launch the Server Monitor and to change your password (see Figure 5).
Since the Server Monitor involves launching a new Flex-based interface, it should be noted that users who are not granted the Server Monitoring are denied access not only to the page shown in Figure 5 but also the Server Monitor itself, which is started when Launch Server Monitor is clicked or can be opened using a browser bookmark. If a restricted user attempts to log in to the Server Monitor, they will be denied.
Important note: If you give a new user access to the Server Monitor, they will be able to access information for all running applications, and the multiple user feature does not facilitate any restrictions to this access. For instance, the Server Monitor enables one to see the values of all application variables in all applications, and all session variables for all users. Since some applications store passwords or other sensitive information in session variables, it would be imprudent to grant Server Monitor access to users who cannot be trusted with such information.
While the discussion to this point has focused on creating multiple users for accessing the Administrator, the new feature also extends to creating multiple users for accessing the server via RDS, such as from Dreamweaver or HomeSite+, as well as from Eclipse when using the Adobe ColdFusion Extensions for Eclipse (for more information on this, read the livedocs).
RDS is an HTTP messaging protocol defined by Adobe—well, Allaire originally—that is implemented in supported editors and on the server. If RDS is enabled for a ColdFusion server, authenticated developers can configure their supported editor to access the server to obtain information such as what data sources exist. They can then query these data sources and have the editors build code based on them. In Dreamweaver and Eclipse, they can also see what ColdFusion components (CFCs) exist on the server (or are accessible in their sandbox, if that feature is enabled), and more. RDS also permits access from the editors to files on the server, even over the web, as an alternative to using FTP.
Traditionally, there has been only a single RDS password set during ColdFusion installation which was used by all developers (if RDS was enabled on the server). The lack of user-specific security has kept many organizations from using RDS at all, whether in a shared development environment or in production (though there are other arguments against using RDS in production; for more information see ColdFusion Studio and RDS with Production Servers and this more recent security whitepaper .) As with the administrator password, one problem with a single RDS password is that if a developer leaves the project, then a new password must be chosen and all the remaining developers must be update their editors with the new password.
Now ColdFusion 8 Enterprise shops can define a different user name for each developer using RDS. In addition, you can control what assets the RDS developer can access on the server, including specific code directories, data sources, components, and more. Of course, if you're using the RDS feature only to access your own server, then you wouldn't have a need to set such restrictions. For teams that work on a shared server, however, this is a useful capability.
Similar to the page for enabling multiple user names for Administrator access, there is a page in the ColdFusion Administrator for enabling multiple user names for RDS. Access it by selecting RDS from the Security section of the ColdFusion Administrator (see Figure 6) and select Separate User Name And Password Authentication (Allows Multiple Users).
As before, when you click Submit Changes, the setting will take effect immediately (no restart is required.) The single password (if it had been enabled) will remain in effect, but you will now need to use the value of "admin" for the user name when specifying RDS authentication information in supported editors (using the same single RDS password enabled during installation or as changed in the RDS Single Password field on this page). Again, for more information on changing this default user name, see the TechNote.
To create new user name/password pairs you use the same process used to create multiple Administrator users. Start by selecting User Manager in the Security section of the Administrator (see Figure 2). The only difference is the optional use of the sandbox feature.
A sandbox is a designated area of your site (a directory that contains CFML files) to which you apply security restrictions. You can now not only enable multiple RDS users but also control what those RDS users can access on the server from their supported editor. Indeed, you may see this new feature referred to as RDS sandboxing. As shown in Figure 3, while adding a new user you can choose to select a sandbox (if any exist) to associate with a specific RDS user.
Sandbox security is a feature that has existed since ColdFusion 4 Enterprise. It was initially focused on controlling the actions that applications were permitted to do, including what code directory they could access (from within CFML code), what data sources they could access (with CFQUERY or CFSTOREDPROC), and more.
With the new multiple RDS user feature, these same sandboxes (or new ones) can be assigned to a given RDS user to restrict what code directory the developer can access from within a supported editor, as well as what data sources they can access (in the table query features of the editors), and more.
Since creating sandboxes themselves is not a new feature, this article won't demonstrate that process in detail. You can find additional information on creating sandboxes in the CFML documentation (Administration and Configuration) and the Administrator online help. I also wrote a detailed two-part series on sandbox security for the Adobe Developer Center in 2002, which covered the interface as it existed in ColdFusion MX 6. The sandbox feature has not changed since then.
To better understand how sandboxes work in practice, consider the following example in which a sandbox is configured to limit access to a certain directory and data source. That sandbox is then assigned to a user, and that user can then access the directory and data source from within an editor that supports RDS.
For this example, assume that the developer should access code only in the C:\inetpub\wwwroot\cfdocs directory and should only see the example data sources installed with ColdFusion 8 (I'm choosing an example that anyone can use as a demonstration, as long as they installed the example applications upon installation of ColdFusion.)
To define a sandbox, open the Sandbox Security in the Security section of the Administrator. In this page's Add Security Sandbox area, type or browse to a directory to which the user should be restricted (in this case C:\inetpub\wwwroot\cfdocs), and click Add, as shown in Figure 7.
Once you have added that sandbox, it will be listed in the Defined Directory Permissions list on the same page along with some other directories that ColdFusion will select by default (see Figure 8).
Caution: When selecting a directory for the sandbox, keep in mind that this sandbox and any settings (such as what data sources are accessible) will also apply to code running within that directory. It might be easy to forget this when you are playing with setting up sandboxes for demonstration with RDS. For example, you may choose only one data source to test how things would look for an RDS user. If the code within that named sandbox directory needs access to other data sources, it would now return an error. Be careful.
To configure sandbox permissions, select the sandbox you just created by clicking on the directory name (as shown in Figure 8), or select the green icon that appears to its left under the Actions column. On the page that appears there are several tabs that you can use to control what is restricted in that sandbox. The first tab is the list of data sources. Note that, unlike the administrator roles page, on this tab all data sources are enabled by default as shown in Figure 9 (my list includes data sources on my server that you may not have).
To limit the sandbox to permit access only to some data sources, select the <<ALL DATASOURCES>> option and click the button labeled ">>" to move all of them to the disabled data sources list. You can then select individual data sources to be enabled by selecting one or more and then clicking the button labeled "<<". In Figure 10, I've enabled access to the cfartgallery and cfdocexamples data sources, which are installed with ColdFusion 8.
The remaining tabs (CF Tags, CF Functions, Files/Dirs, and Server/Ports) control features that apply to sandboxes for their original purpose of controlling CFML applications. The Files/Dirs tab, however, could be used to further refine control over the use of this sandbox with RDS, such as to permit access to other directories. This level of control is not needed for this example, so click you can just click Finish.
You're almost done. To have the sandbox take effect, you need to enable sandbox security for the server (if it has not been enabled already). Select Enable ColdFusion Security at the top of the Security > Sandbox Security page (see Figure 8) and then click Submit Changes. A message will indicate that you must restart the server for this change to take effect.
When you enable this option, ColdFusion changes the underlying jvm.config file to enable the Java security manager, which will take effect upon restart. (Users running a multiserver configuration of ColdFusion, often called "multiple instances", should note that ColdFusion does NOT change the jvm.config in this case. You must change it manually. For more information, see this Adobe TechNote.
The final step is to create or edit a user in the User Manager page, as discussed earlier in this article, and associate the new sandbox with that user. This step (see Figure 4) is straightforward and not illustrated here. (Note, however, that it's currently not possible to associate a sandbox with the default Admin user, since that username is not ever shown on the User Manager page in Figure 2.)
When you launch an editor that supports RDS (for example, Dreamweaver, HomeSite+, ColdFusion Studio, or Eclipse with the Adobe ColdFusion Extensions for Eclipse), you can configure it to use your newly created user name/password combination. If you had already configured the editor to connect successfully using RDS before enabling multiple RDS users, you would have previously entered only the one RDS password defined for the server. Now, you would change that configuration to use the new user name and password combination.
Providing instructions for configuring all the editors that support RDS is beyond the scope of this article. You can find more information in the online help for Dreamweaver, HomeSite+, and ColdFusion Studio, as well as in the ColdFusion 8 documentation for the ColdFusion Extensions for Eclipse (for more information read the livedocs). Note that the ColdFusion Extensions for Eclipse differ from the CFEclipse project.
If you're using Eclipse (and have installed the ColdFusion Extensions for Eclipse), you enter RDS authentication information by choosing Window > Preferences and then Adobe > RDS Configuration, or Window > Preferences and then ColdFusion > RDS Configuration, depending on the version of Eclipse and the Extensions.
After selecting or creating a new RDS server to use, enter your user name and password and click Test Connection. If that test fails, check the user name/password values you entered and ensure that the user was enabled for RDS access in the User Manager page as discussed earlier in this article. Also check that the hostname and port are set to the same values you would use to open the ColdFusion Administrator. Finally, verify that RDS is enabled on the ColdFusion server. See the Solving challenges with multiple RDS users section of this article for more details.
If everything is properly configured you should be able to access the restricted files and data sources in the RDS Fileview and RDS Dataview views shown at the bottom of the screen (see Figures 12 and 13). To open these views, choose Window > Show View > Other > ColdFusion or Window > Show View > Other > RDS, depending on the version.
If you don't see the directories you would expect per the sandbox configuration, note that you may need to right-click on the servername (in the RDS Fileview pane) and choose Refresh Active RDS Server. Figure 13 shows the RDS Dataview, displaying just the two data sources selected in the sandbox. Right-click on a datasource, table, or column name to see different options available for working with them
There is also an available Services Browser feature in the ColdFusion Extensions for Eclipse, which you can use to view CFCs installed on the ColdFusion server (or web services for which you manually entered URLs). With sandboxing enabled, the Services Browser is limited to displaying only those CFCs that would be accessible by code in the provided sandbox, which include CFCs in the sandbox as well as those in the web root and other mapped directories. Finally, note that there is also a Log Viewer feature. You can see both of these features among the tabs at the bottom of Figure 13, and you can add them using the Window > Show View command discussed earlier in this section.
Dreamweaver also offers RDS-enabled features, which you can configure by choosing Site > Manage Sites and setting up a Testing Server to point to your ColdFusion server (whether local to you or remote), choosing ColdFusion for the server model (as shown in Figure 14, which illustrates using the Advanced tab for site configuration). When you open the Databases tab of the Application panel group and enter the RDS user name and password as prompted in that tab, you will see the list of sandbox-enabled data sources, also reflected in Figure 14.
Similarly, to see the restricted list of file names in the Files panel group, while configuring your site with Sites > Manage Sites, configure the Remote Info section and select RDS for the Access type. Enter the information for your server (the same hostname and port that you would use for accessing the ColdFusion Administrator, and the RDS user name and Password.) After you click OK, the restricted directories will be shown in the Remote view of the Files panel group and Files tab (also depicted to the left in Figure 15, as the Site configuration change had been previously made).
Finally, the Components tab (in the Application panel group) would also be restricted to showing only the CFCs accessible to code in the indicated sandbox (in the sandbox directory, web root, and mapped paths).
A demonstration of using HomeSite+ is not included here, but again, its online help does show how to enable and use RDS-based features.
Let's address a few common problems people face. If you've previously succeeded in using an RDS connection to your server from your editor, and you find that you still see all data sources or all directories, recall that you need to enable Sandbox Security and restart ColdFusion (as well as authenticate with a user name/password that is set to a restricted sandbox.)
Also, as with the multiple user feature for the Administrator, if you change the sandbox to which a user is allowed access while that user is logged in via RDS, the changes take effect only after the user refreshes their RDS connection (by right-clicking the list of files or data sources in Dreamweaver or HomeSite+ and clicking Refresh, or by doing so in Eclipse and clicking Refresh Active RDS Server.)
If you're having difficulty configuring or using RDS at all in the supported editors, or want to know more about it, besides the online help for each editor, I also have a recorded user group presentation on the topic.
You also may find that you can't connect from your editor to your server because RDS has been disabled entirely on your server. That's an option at installation, and the warning offered dissuades many people from enabling it. Indeed, it should not be enabled on production or any publicly accessible servers, unless you're very careful to lock down access to it (which again is beyond the scope of this article, but I do cover it some in my user group presentation). If you want to enable RDS on a server where it has been disabled at installation, you need to modify an XML file and then restart the server. For more information, see this TechNote.
I hope that this introduction to the new ColdFusion 8 Enterprise (and Developer edition) multiple user feature will help you better manage your ColdFusion administration tasks and provide secure access to servers from RDS-enabled editors.
You can use the links below to find more information on these topics.