May11
I previously discussed ways to manage user session state in DHTML-only UIs. A very similar problem arises with security contexts: Traditional web technologies like JSP and ASP.NET can link the identity of the user that is established at login to an authentication token that is either sent as cookie or encoded in the URL, just like the session id. If you integrate your session handling with a session-enabled technology as outlined in my earlier post, you can also attach to the security context in a similar fashion.
Setting up authentication is not very difficult and works similar in .NET and Java You can integrate with different authentication methods such as LDAP/Active Server or a database. First, the application needs to be told to use authentication. Here is a very simple security context from a ASP.NET Web.config file that uses form-based authentication and denies access to non-authenticated users:
<authentication mode="Forms">
<forms loginUrl="Login.aspx"
protection="All"
timeout="30"
name=".ASPXAUTH"
path="/"
requireSSL="false"
slidingExpiration="true"
defaultUrl="Default.aspx"
cookieless="UseDeviceProfile"
enableCrossAppRedirects="false"/>
</authentication>
<authorization>
<deny users="?"/>
</authorization>
And here is the same for the web.xml of a Java war file (note that the login form’s action must be named j_security_check, the username field j_username and the password field j_password):
<security-constraint>
<web-resource-collection>
<web-resource-name>A Protected Page</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>Role1</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/error.jsp</form-error-page>
</form-login-config>
</login-config>
There are a few more steps involved; for more details, you can start here (.NET) and here (Java).
One advantage of this solution is that you get many security features without touching your application code – for example:
- Access to protected resources is automatically restricted. In the above examples, unauthenticated users will be redirected to the login page if they request a resource that is protected.
- You can fine-tune the access to each resouce based on security roles.
- Your protected code is automatically provided with the user identity.
On the other hand, your security context will only work within the underlying technology and depending on your server configuration, it may not even work between applications on the same server. Another common problem with authentication tokens is that once they are issued, they often cannot be invalidated explicitly – they need to expire. That means even if the user logged out correctly, the authentication token may still be valid for some time. If this risk is not acceptable, you may have to take additional steps to verify authorization like checking additional parameters using the user session, which can be invalidated explicitly, or even implementing your own security cookie solution.
Of course, you don’t have to use those server-side mechanisms – you can create your own tokens that are passed as parameters or cookies. It requires a little bit more coding but can work across technologies. Simply add a login method at the server side that authenticates the user and returns an encrypted, hard-to-guess token, which either maps back to user identification data stored at the server (you could use the WebDaptive Session Service) or contains the necessary identity information and expiration time in an encrypted format. The UI would then send this token back with every request that requires the security context. Each method then can evaluate it as needed. And, of course, you will have to make sure that procedures are in place for invalidating and expiring the token.
Now you may ask – why so complicated? Why not simply have the UI store the user id after a successful login and send it to each method? Here’s why: User ids are usually easy to guess and often even known to many people. Once you have a user id that you want to impersonate, it would not be very hard to craft valid HTTP requests that have the other user’s id in them and send those to the server instead. The server has no way of knowing that it wasn’t the other user who sent the request. In this fashion, you easily could gain access to data and operations that you shouldn’t be able to. Of course, you can try the same thing with both approaches outlined above but they make it significantly more difficult to obtain a valid authentication token that is not based on your own login data because they are very hard to guess and – even if you could find one – work for only for a short time.
- Anke
