Web Services, SSL, Windows Authentication, ColdFusion MX+

So you're working toward creating a SOA (Service-Oriented Architecture) in your organization and you've picked ColdFusion to create various web services at in support of it at a given tier (i.e. internal/external). It's a beautiful thing as ColdFusion makes it easy to create them.

is entry is not going to start with the basics on creating a web service but will address the possible challenges associated with implementing one with CF in regard to SSL and Windows Authentication. Now that you have created a web service and tested it you may wish to encrypt its contents with SSL and, if running on IIS, integrate Windows Authentication to force the user/calling application to pass login credentials to a given domain.

Where to start? Assuming you are doing all this on a development machine with no registered certificates 8-), we need to start with the creation of a Certificate for the implementation of SSL and then registering it within CFs keystore. J2EE requires that certificates be registered within their service as there are standards that they address in validating certificates. One note here is that one should use an open/universal, non-Microsoft based certificate generation tool as there is an issue with Java's implementation of digesting/validating Microsoft generated certificates for storage. The tool of choice is IBM's Keyman. This tool, with a bit of practice, will have you generating keys and certificates that you can register in IIS.

To work with the tool you must first generate a request in IIS to pass to Keyman. To generate a request go to the properties of you web site in IIS and select the directory security tab. From there click on the server certificate button. You will then be prompted several times, be sure to select "create a new certificate" and change attributes such as name when necessary. Don't forget to make a note as to where the request text file was generated. Next open Keyman select new Token. On development machines I use default settings. Once the token has been created you must create a key. Go to Actions in the menu and select generate key, accept the default selections. Now that the key has been generated, go to actions once more and select create certificate. Select sign a PKCS#10 request and browse to where you saved you cert. request from IIS or select load from clipboard if you happened to copy the request files text. Next save the generated certificate. Lastly, open IIS and click on server certificate again. Select Process the pending request and install the certificate. Browse to the certificate and install. You will now be able to access the site over https.

Now to turn on domain authentication go to Directory Security tab again in IIS and select edit button. Select Basic and just the default domain and realm if necessary. I usually leave them blank and specify login parameters with ColdFusion. So we are secure on the server now and we must register the generated certificate in a keystore for ColdFusion to be able to access the files within the site.

You can use the keytools command line application that installs with CF to support this or if you would like, download the GUI app. (see link below). It can save you a bit of time. A good reference for keytool command and registering certificates within a keystore can be found here and here. This should get you up to speed and when I get more time I will provide screenshots.

I have a copy of KeyTool GUI 1.7 which is under GNU Public License and free to distribute and DOWNLOAD. Point this at your ColdFusion keystore and you can import (Look here if not running as J2EE D:\CFusionMX7\runtime\jre\lib\security).

Comments (Comment Moderation is enabled. Your comment will not appear until approved.)
I found your article really helpful in getting some of the kinks worked out when setting up a CF web service.

The one issue I have yet to resolve is how to get the web service registered in the CF administrator without having to provide username and password credentials. If I register the WS with them, it uses them as the default if a consumer does not provide them. This defeats the security aspect of requiring the consumer to provide their credentials.

Hopefully there is a workaround to this issue.
# Posted By Phil | 12/6/06 11:28 AM
Phil, not necessarily. The reason I say that is you are only allowing your developers to access the web service via CF code and the administrator which is locked down of course.

Also, registering the web service is not required, it is done automatically when the service is first invoked as well, so I would tell all developers to code with the applications domain account credentials whenever they invoke the web service in code. This may require a code review, but this is not a security issue.

(look at it like the username and password required for a datasource) the web service stores it in the same fashion. Good luck.
# Posted By Jeff Bouley | 12/6/06 7:35 PM
After some more testing I now see what you are saying.

We have a requirement to log who is accessing the service. Do you know of a way to capture the id of the person making the web service call?
# Posted By Phil | 12/7/06 9:59 AM
Phil, have the web service store the login info. via a database call (Insert). You will have to pass this information when you make the call to the function as an argument. You will take a bit of a performance hit with this due to the insert into a log table, but that would be the best way to go.
# Posted By Jeff Bouley | 12/7/06 10:20 AM
Thank your for posting this.
# Posted By Dentists Downey | 9/24/09 4:58 AM

Copyright Strikefish, Inc., 2005. All rights reserved.