Last week I attended one vendor presentation in which presentor was talking about how there product can be installed on the application servers to bypass the login mechanism. In this approach application login page needs some modification. I understood what he was talking about and thought to share this with my friends reading my blog.
Product must be using the magic of HTTP header variables and here are few steps which can be used to make it working
1) As soon as user logs into the centralized access control product it will set a browser coookie for the user.
2) User clicks on the application URL, product agent is sitting at the application/web server.
3) Browser will pass the cookie to the product (Assuming all the applications are running in single cookie domain).
4) Agent will intercept the cookie token and will verify the validity (session timeout/idealtimeout etc) with the centralized server.
5) After validation agent will set the predefined HTTP header variable's in the request and forward the request to the application/web server
6) Application will check if the required header variables are present in the HTTP request or not.
7) If the required header variables are found in the request and internally authorized by the application authorization module requested page will be served to the user. Custom header variables can contain information like username, employ number, job code etc which can be used to decide the authorization rights.
8) If the required HTTP header variables are not found in the request user will be redirected to application login page.
There are many HTTP header variables which are part of the HTTP standards but custom HTTP header variables can be defined based on the requirements. One thing to note in the above scenario is that every time a new page is requested by the user same HTTP header variables needs to be passed to the application as the life of the HTTP header variables is limited to single request.
No comments:
Post a Comment