| home / programming / coldfusion / 2 |   [previous] |
|
|
|
Although several competing standards for handling security within the web services framework are under development, as of this writing there is no accepted standard. That said, there are existing technologies you can use to secure access to your web services. ColdFusion supports web service security in two ways, at the web server level and using ColdFusion's built-in security framework.
At the web-server level, you can protect a web service using HTTP Basic Authentication. This is done by restricting access to the directory containing the CFC you want to expose as a web service. For more information on using HTTP Basic Authentication, see Chapter 8, as well as the documentation for your particular web server.
For web services that restrict access based on HTTP Basic Authentication, you can provide a username and password to pass along with the call to the web service in the cfinvoke tag or by registering the web service in the ColdFusion Administrator:
<cfinvoke webservice="http://www.example.com/addressLookup.wsdl"returnvariable="myAddress"username="username"password="password"><cfinvokeargument name="userID" value="pmoney"></cfinvoke>
The username and password values are Base64-encoded and passed as username:password in the authorization header to the target server.
You can control access to your web services at a much more granular
level using ColdFusion MX's built-in security framework. This works for web
services the same way as it does for CFCs, by controlling access based on assigned
roles at the invocation level. Example 24-12 shows the code for a secure CFC
accessible as a web service. The web service can only be invoked by clients
with a role of Administrator.
Example 24-12: A web service restricted to clients with a role of Administrator
<cfcomponent><cffunction name="returnStr" access="remote" returntype="string"roles="Administrator" output="false"><cfreturn "You have gained access"></cffunction></cfcomponent>
The framework for authenticating clients is the same one we discussed back in Chapter 8. Using an Application.cfm file, we can leverage ColdFusion MX's security framework and HTTP Basic Authentication to provide a means to authenticate clients before allowing them to access a web service. Example 24-13 shows one way to do this.
Example 24-13: Authenticating clients before they access a web service
<cfapplication name="MyWebService"><cflogin idletimeout="600"><cfif not isdefined("cflogin")><cfheader statuscode="401"><cfheader name="WWW-Authenticate" value="Basic realm=""MyWebService""">You are noy authorized to access the web service.<cfabort><cfelse><cfquery name="validateUser" datasource="programmingcf">SELECT Roles, Salt, PasswordFROM UsersWHERE Username = <cfqueryparam value="#cflogin.name#"cfsqltype="CF_SQL_VARCHAR"maxlength="255"></cfquery><cfif (validateUser.recordCount eq 1) and(validateUser.password is hash(validateUser.salt & cflogin.password))><cfset userRoles = valueList(validateUser.roles)><cfloginuser name="#cflogin.name#" password="#cflogin.Password#"roles="#userRoles#"><cfelse><cfheader statuscode="401"><cfheader name="WWW-Authenticate"value="Basic realm=""MyWebService""">You are noy authorized to access the web service.<cfabort></cfif></cfif></cflogin>
When a client calls a ColdFusion-based web service, a check is made to see if there is an Application.cfm file that should be run first--just as there is when a CFML file is called from the browser. This lets you use the same mechanisms you are already familiar with to build a security framework for your CFC-based web services. When our Application.cfm file is called, a number of things happen.
First, a check is made to see if the cflogin structure exists. If not, an HTTP 401 status code is sent back to the client, telling them they are not authorized to access the web service. If the cflogin structure does exist, we know that the call to the web service also included an authorization header containing (hopefully) a username and password. Those values are automatically available inside the cflogin structure as cflogin.name and cflogin.password. A query is made to see if the username exists in the Users table of our example database. If so, the salt value associated with cflogin.name (from the database query) is concatenated with the password provided by cflogin.password. The resulting string is hashed and then compared to the hashed value stored in the database. If a record is found for the username, and the salted, hashed password matches the value stored in the database, we consider this a valid login. The cflogin tag is then used to log the user in and assign the role from the database. In this example, when we lookup the username pmoney, we find she is assigned the roles Administrator, User.
The code for invoking the secured web service is shown in Example 24-14. Note that it's necessary to create a subdirectory off the /programmingcf directory called /ch24 instead of the /24 format we've used before. This is because directory names that begin with numbers cause ColdFusion to throw an error when dealing with web services.
Example 24-14: Invoking the secured web service
<cfinvoke method="returnStr"returnvariable="retVal"webservice="http://localhost/ProgrammingCF/ch24/secure/secure_ws.cfc?wsdl"username="pmoney"password="cat"></cfinvoke><cfoutput>#retVal#</cfoutput>
If you run this code, you should see a message in your browser that reads "You have gained access". If you wait 30 minutes (the time specified in the idletimeout attribute of the cflogin tag), and change the username or password to a different value, you should be able to generate an authentication error if you attempt to call the web service as an unauthorized user.
2. One web site I can't give enough praise to is XMethods (http://www.xmethods.net). Besides acting as a private UDDI registry, the site has several fantastic resources, including a WSDL analyzer (http://www.xmethods.net/ve2/Tools.po) that allows you to enter the URL for a WSDL file for analysis. The analyzer validates the WSDL file and outputs a series of HTML pages that detail the operations and information on input and output parameters.
3. When a web service specifies a complex type as an output parameter, ColdFusion receives it as a special type of object that can be assigned to a variable and referenced using dot notation, like a structure. However, the returned object is not a true ColdFusion structure.
4. This was true in ColdFusion MX 6.0. However, in ColdFusion MX 6.1, the Macromedia engineering team made changes to ColdFusion that invalidate this rule.
| home / programming / coldfusion / 2 | [previous] |
The Network for Technology Professionals
Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers
|
Video: How System Center Helps Reduce IT Costs IBM Cloud Computing for Developers Virtual Event, April 6-8 |
Microsoft Video: OCS and Exchange: Platform Futures MORE WEBCASTS, PODCASTS, AND VIDEOS |
Created: March 27, 2003
Revised: Sept 1, 2003
URL: http://webreference.com/programming/coldfusion/2
