Library tutorials & articles
Authentication for Web Services
Our Process Flow
Now let's take a look at the details of how we implemented the authentication method that we just outlined. The code necessary to create the databases, populate the tables with some sample data, as well as the code for the Login method and the aspx file used to test it are in a .ZIP file accessed through the "Download Source Code" link above. The flow through the process is as follows
Figure 1 - Authentication Process Flow
- The initial call to the web service is made through the Login method. The company code, user id and password are provided as parameters. For security reasons, this call will take place over SSL.
- The web service uses the Login method of the CLogin object to validate the credentials. The parameters to the method are the same as the initial call to Login. The result will be either a 33-character token or a blank string.
- The Login method invokes the stored procedure called prcValidateUser on the Token server. The result will be a recordset (or more accurately, a Data Reader) containing either a 33-character token or a blank string.
- The stored procedure prcValidateUser using the information in the Company table to identify the server on which the database can be found and the name of the database itself. This information in turn is used to build the statement that gets executed on the remote server.
- Through the stored procedure called prcValidateUser that is in each company's database, we validate the credentials that have been provided.
- If a match has been found, then a token gets generated and returned up the chain. As mentioned in the previous section, we use a check digit as part of the process. The value of the token, along with the company and user associated with it gets stored in the Tokens table.
At this point, we have the security token that we need to make the rest of the functions work. You will see it put to use in future articles. As for the next segment, we will discuss the technique that we use to support the authorization portion of the server. As always, any suggestions or improvements are greatly appreciaed. Keep those cards and letters coming. :)
Related articles
Related discussion
-
Java RAD Training...
by fordendk (0 replies)
-
I'm a newbie! How these things affect us?
by ephraimgasel (0 replies)
-
Error Capture
by Slicksim (4 replies)
-
MOS Protocol - Anyone used it?
by alexnavarro38 (5 replies)
-
AJAX: SimpleWebServices is not defined
by Freon22 (2 replies)
Related podcasts
-
Introduction to Atlas
Get your feet wet with an introduction to Atlas. Atlas is the new part of the .NET framework specifically for web clients. Features include AJAX and web services support, new validation controls, behaviors, and an object orientation layer sitting on top of JavaScript.
Events coming up
-
Dec
8
December Silicon Valley Ruby Meetup
Moffett Field, United States
In a World of Middleware, Who Needs Monolithic Applications? by Jon Crosby With Rack emerging as the standard for composing web applications and services, most recently with Rails adoption, an architectural shift is taking place. Learn how to create next generation web services by reusing existing Rack middleware and supplementing with your own components and micro-frameworks like Sinatra. Bio : Jon likes music, the Open Web, Ruby, Erlang, Haskell, Objective-C, JavaScript and coffee.
I have enjoyed reading the article so far and I have a quick question. Isn't the interception of the security token almost as useful to a hacker as the interception of the original credentials? If so (even marginally) then why is it neccessary to go to such lengths to hide the login name and password, but not the token? Couldn't a hacker keep the token alive by using it regularly, therefore avoiding any expiration? Would it be possible to explore these issues, in the scope of the article?
Thanks,
Seamus
This thread is for discussions of Authentication for Web Services.