Scenario – a developer wants to restrict unauthorized access to a we service in his application.
WARNING: This method is easy but not bulletproof !!!!
The level of security desired is modest and the developer does NOT want to use SSL, WS-* extensions or any other certificate based infrastructure.
A customer emailed be this week with this very question.
They were using the ASP.NET Membership Application Service and Forms based authentication in their application and discovered that the user’s authenticated state in the application was not accessible from his web services.
The problem ?
Web Services (ASMX) and Web Pages (ASPX) can both have session state but they do not SHARE session state.
Here are two quick ways to authenticate calls to Web Service Methods. (There are, of course, many ways.)
You can pass the UserName and Password to the web service method and manually authenticate.
[ Remember, without SSL the username and password are passed over the web in “clear text” and are theoretically exposed to “man in the middle” interceptions. ]
The web service method would look like this….
And be called like this……
Though this works, it is inelegant because it causes the actual credentials to be passed for each web service method call.
Here is a method that I prefer.
I start by adding a table to my ASPNETDB database, though really you could put it anywhere.
Next, I add a LoggedIn event handler to the LoginView control in my site’s MasterPage.
When the user logs in this code does three things.
1.) Gets a new GUID
2.) Stores that GUID in the ServiceTokens table
3.) Stores the same GUID in a session variable.
Now we re-factor our Web Service method to accept a single parameter (a GUID as a sting) instead of a UserName / Password pair.
When the method gets called we take the GUID/Token and see if that GUID exists in the ServiceTokens table.
If the web method does not receive a GUID, or if the GUID received does not exist in the ServiceTokens table, the user is declared as “Not Authenticated”.
How YOUR application handles method calls that fail to provide a valid token will be up to you and will depend on the specifics of your application. IN the case of this demo, we just return an “unauthenticated” message.
Now, in our page code we can call our Web Service Method by retrieving the GUID that we previously stored in a session variable and passing it to the web service method.
Notice that if the user is not authenticated or the GUID in the session object is empty, the user gets redirected to the LogIn.aspx page.
In practice this means that our user interface won’t let an unauthenticated user make a web service method call but the web service method itself could be called directly from outside our application and that’s why we require a valid GUID that is created when a user successfully logs in.
There is one gotcha that we need to address.
Every time a user logs in, a GUID gets added to the ServiceTokens table but those tokens never get removed.
The more the application gets used, the higher the likelihood that a brute force attack could stumble on a valid token and those tokens are valid forever (never deleted from the database.).
To solve this problem we’ll need to delete the tokens from the ServiceTokens table when the user is done with them.
If the user logs out this is easy to do.
We can modify the LogedInTemplate of the LoginView control in our master page to hook an event handler for when the user logs out.
Then we can implement that “OnLoggedOut” event handler as so…..
Note that the UserServiceToken is removed from the Session Object and the ServiceTokens table in the database.
This is fine if the user actually logs out, but what if the user does NOT log out?
We still want to clean up the GUIDs even if the user never logs out.
[ NOTE : the following method only works if session management is “InProc” if we are using alternate session management then we would need a different Session_End strategy. ]
When the session expires, we can clean up the GUIDs as well.
In the Global.asax.cs file ….
Note that there is some subtle logic here.
When the session expires, the LogInView control will still show the user as logged in but when we actually TEST the authentication state of the user in our code-behind ….
The result will be false and the user will be asked to re-authenticate by entering their username and password in order to call the web service method.
This makes our web service method unlikely to be successfully invoked by an unauthorized user because in order to do so, a bad guy would need to either need to intercept a valid set of credentials or guess a GUID that exists in the ServiceTokens table and use it while a valid user is logged on.
Hope someone finds this useful
[ Click HERE to download an ASP.NET 4 sample. ]