Adaptive Access Control

Few weeks back I went to attend Oracle Openworld in San Francisco and while I was on the demo grounds to see what oracle has to offer in the Identity and Access Control I met one product group which is building a "Adaptive Access Control" product.

This product builds the intelligence based on your previous access controls and compare them on next logon. This can be configured to make the metrics over a predefined period of time and freeze the statistics for next access requests.

For example if you are accessing the system between 8AM and 5PM on a daily basis and one day it gets the request at 10PM then it will deny the access.

This seems a good idea to me except for the reason that how long it takes to capture the metrics and how it handles the exceptions.

Another scenario could be that you access the system from North America reason and one day it sees the request from India then it has a valid reason to suspect the request.

Open Source identity and Access management : VELO

Fortunately I got a chance to directly talk to Asaf Shakarchi (father of VELO) and I asked him why you named it VELO.

Asaf: It was taken by "velo binding". You can read about it in wiki.

My understanding: I then read about it in the Wiki and tried to link it with the identity and access control and realized the name is so true as the product is also trying to link and bind and control the identities.

I also asked him what is the function of remote performer and below is what I understood from his explanation

Remote performer is a kind of load balancer which can be used to delicate the responsibility of the VELO server. For example if the environment has many resources and you don't want to wait for the responses from the resource once you provision, you can use VELO remote performer. All the requests will be delegated to the remote performer and VELO server can perform other important tasks.



Remote performer is not a must for deploying VELO but it can give additional flexibility to distribute the load.

Strong Authentication by biopassword

I watched many sci-fi movies where guys were playing around on the keyboard and trying to hack someones system by figuring out password etc. You already know that every individual has his/her own way/speed of typing on the keyboard. Biopassword has made a product on such grounds. There product captures the keystrokes and builds a pattern in which user key in the password etc. During authentication there software checks for that pattern and denies the access if the pattern does not match. I have tested the demo on there site.

You check it out by yourself and have fun.

How Kerberos was evolved - Inside Story Part 2

In my last post I discussed few steps for the evolution of kerberos protocol implementation. In this post I am going to conclude it so read on...

Just want to recolect the problem statements where I left in last post so you get some continuity

Problems

1) Once tickets are generated at the user system and passed over the wire for service access they can be tapped over the wire. For example user got the encrypted ticket during authentication process and it was successfully decrypted, Now user will pass this ticket to mail server for mail access. At this time someone can tap the ticket and replay it later.

2) Tickets are good for ever. Once assigned no ticket session expiry.

For solving first problem Authentication Server (Ticket Granting Server [TGS]) will generate a sessionkey which will be sent to the user. TGS will also send a ticket encrypted with service password to the user. Below is the detailed structure

[SesssionKey:[*Service Ticket encrypted with service Key]]

* Structure of service ticket is [SessionKey:lifespan:issuing time:service name]

issuing time and lifespan are introduced so tickets can be valid for specific amount of time and not good for ever.

TGS will encrypt session key and ticket with user's password to solve the replay attack because password is only shared between user and Authentication Server.

Step by Step process for user authentication and service access

1) User enters the userid and KINIT program on the user machine sends that to TGS for authentication.

2) TGS server creates Ticket Granting Ticket [TGT] (this will be used to get service tickets)and send to the user by encrypting the whole content by users passwod.

3) User decrypts the TGT using the password to get the ticket. If someone spoof the packet then he will not be able to decrypt it as the password is shared between user and TGS only.

4) User wants to access his mail but user does not have mail service ticket so user contacts TGT for mail service ticket by submitting Authenticator,TGT, Name of the user and workstation address. This Authenticator with the session key sent by the TGS in the initial handshaking.

* Authenticator = {username:servie name: time stamp : lifespan}

5) TGS will get the session key of the user and decrypts the authenticator. After validating the identity it generates following and send by encrypting the whole content using the SESSION Key.

i) Ticket for the mail service. This ticket has the session key, service name, lifespan, timestamp and client address. This ticket is encrypted with the service password. (Even User can not decrypt it)
ii) Session key to be used to encrypt the conversation with mail service

6) User recieves the packet and decrypts the content using the session key (Given during first handshake with the TGS).

7) User prepares the Authenticator and encrypts it with the SESSION key (generated for the mail service communication in step 5).

8) Mail Service recieves the Authenticator and Ticket. Decryptst the ticket using it's password to get the session key. Using the session key decrypts the Authenticator. Validate the Authenticator and sends the acknowledgement to the user by encrypting the session key.

9) User receives the acknowledgement and start using the service.

How Kerberos was evolved - Inside Story Part 1

I always wanted to get something on kerberos (earlier name Charon) which can give me inside of the protocol like why,how, what etc...

In this post I am trying to explain this in some easy steps with problem and solution approach for the evolution of this protocol.

Below Image displays the first version of there discussion



Problem with the first version is that anybody can impersonate anybody easily so no security and accountability. There is no Authentication (NO PASSWORD) piece involved it is just the userid which you pass to get the service.

Below Image solves first problem by having a centralized authentication server. Every user and every service has a password which is stored in the authentication server named CHAROS.

Here is how it work

1) User Authenticates with the centralized server
2) Server authenticates the user and give him a TICKET (encrypted text which is encrypted with service password)

*encrypted text contains (Username and servicename and IP address of the user)
3) User passes this ticket to the service and service will verify user's identity to give access




Problems with this:

1) User has to authenticate every time user wants to use any service. For example user has got the TICKET for mail service but wants to print some mail then he has to again enter the password
2) Password is flowing on the network in clear text (people can capture the password on the network)


Above problem is solve by introducing another component called ticket granting service in the authentication service. It will grant the ticket which can be reused.

Another componet which is added at the system level is KINIT service which is responsible for handshaking with the authentication service. Here is how it works

1) KINIT service will take userid and password from the user and will pass the userid to the authentication service (it will NOT pass the password at all)
2) Authentication service will build the TICKET GRANTING TICKET and encrypt it with the user's password because it knows what the user password is.
3) KINIT will decrypt the token using user's password. If it is able to decrypt it successfully then user is authenticated.





Problems:

1) Once tickets are generated at the user system and passed over the wire for service access they can be tapped over the wire. For example user got the encrypted ticket during authentication process and it was successfully decrypted, Now user will pass this ticket to mail server for mail access. At this time someone can tap the ticket and replay it later.

2) Tickets are good for ever. Once assigned no ticket session expiry.

Keep reading this because I will post rest of the story in next post...

Cross IDM product integration

In my coffee time I use to discuss with my friends about the projects on which they are working and how they are solving the problems. It could be related to IDM/IAM or it could be any other technology. Few days back I met with my friend who is working with web methods to integrate different applications. While discussing about it back of my mind was thinking can we have something which can help us integrating multiple vendor products related to IDM / IAM space?

I think yes, that kind of framework can be built using the SAML and SPML specification integration framework. At the root level these specifications talks XML language over HTTP/S channel. If we can build a IDM middleware component which can understand one product language (XML Schema) and convert that to another product language then our purpose is solved.

It looks like OpenPTK is one such open source project on which Sun is working on. They recently released latest version of it. It is providing multiple interfaces to connect to Sun IAM suite (Identity and Access Control suite). But I think this is the starting as this version of OpenPTK does not support cross product integration.

Federated Access Control

Generally I hate do a copy paste of the content from other sites but I liked this one a lot (because of cute animations) so thought of sharing the same with my friends watching my blog.

Servlet Filter and SSO

Servlet Specification 2.3 came with many new features. One of such feature which is used for Single Sign On (SSO) implementation is Servlet Filter. Below image gives an outline how servlet filters can intercept request and response headers before content is reached to the destination.

Servlet Filters can intercept incoming request and check the header variables, It can also make dynamic decisions after validating the HTTP Headers.




How Servlet Filters can be used for SSO:

Agents responsible for providing SSO functionality use Servlet Filters to intercept every request before it hits the destination. Filter intercepts the session header variable in the request and checks against the Session Manager of the Access Control product. If the Session coming in the request is valid then it passes the requst to the other component of the agent for further processing like role validation etc. If the Session is not valid then User will be redirected to the login page. In the below diagram I tried to detailed out some of the J2EE agent components.

SSO vs centralized authentication

Single Sign On (SSO) provides a mechanism in which user is authenticated only once and then given access to various applications. Behind the scene it might be possible that systems are authenticating/authorizing the user with different systems. SSO works mainly with web based applications. We can not (easily) achieve SSO for logging into Unix servers or non web based applications.

Centralized authentication helps user in such cases. User will have to enter the credential multiple times but they will be same. All the applications will authenticate the user against the centralized repository (like active directory or another LDAP or common database). Since all the applications are authenticating user against one server user don;t need to remember multiple credentials. Also once user account is terminated in the centralized system user can not access any of the application user has access to.

Strong Authentication

In today's world when more and more applications are getting consolidated in enterprise portals we have to have a solution to protect secure applications with extra layer of protection. Strong authentication or multilayer authentication is the solution for this problem. Let me give a brief introduction about different ways in which we can authenticate ourselves

1) What we Know : UserId, "secure PIN", Password, Security question/answer

2) What we Have : "Secure token", "Bank ATM card"

3) What we Are : Biometrics

Normally we use userid/password combination to get into any secure site. That authentication mechanism is secure but only to certain extent.

Take an example where you are authenticating to a bank site using userid/password combination and someone on the network (Man in the Middle) captures your userid/password. He can use those credentials to get into the banking network .....(you know what I am thinking here). It seems to be very complicated on the board but people have done it and our goal is to reduce those attacks to the maximum possible extent.

If we introduce one more layer of authentication in the authentication logic by adding 2) or 3) from the above, we will make the system more secure because Man in the Middle will not have what you have and definitely he can not be You. This is called strong authentication.

There are various ways to introduce second factor, one such mechanism is One Time Password (OTP). In OTP system generated password can be used only once so even if that password is trapped over the network it can not be used again.

Refer to RFC for getting more inside of OTP. There are many products available in the market for OTP. Apache is also working to build one such system under the name of triplesec http://directory.apache.org/triplesec/

Technorati : Multifactor Authentication, Strong Authentication

Complexity of Session Timeout

One of our application team was using the centralized access control product for securing the access to the application. Users of the application team started reporting the timeout issue from the application after some time. We thought that increasing the ideal/session timeout settings should solve this problem. We increased both the values to hours just for testing that if those settings are the culprit. But making that change has not changed the situation. Our next suspect was the application code so we asked the application team to check if code is doing any session timeout after some time. They also confirmed back that is also not the case. We approached the application deployment team and requested them to make the change in the session timeout parameter from the application server. As soon as they changed the session timeout value to unlimited problem was resolved.

My question to myself was how can that application server parameter be responsible for timeout and redirect the user to login page? I read the servlet specification (version 2.3) for this issue and here is what I feel should be happening in this case.

1) User accesses the application page for the first time.

2) Since access control product is used to protect the application user is redirected to the access control login page.

3) User authenticates successfully and redirected to the application.

4) Access control product agent is using the session variable (JSESSIONID) as a key to cache the user details like session expiry, ideal time out etc.

5) User access the application again. This time JSESSIONID is passed from the browser as a cookie to the application/web server. This JSESSIONID is used as a key to look for session information in the access control product agent cache.

6) After the JSESSIONID expiry at the application server, new JSESSIONID is generated and the cookie value is overwritten.

7) User accesses the page again but this time new JSESSIONID value is passed to the application/web server. This new value is again compared in the cache. It will not be found in the cache. Agent will treat this request for a new user and redirects the user to login page.

What value for the session expiry should be set:

For ideal condition JSESSIONID value should be set as the same value for the session timeout from the access control product. If the access control product has session expiry as 1 hour and ideal time out as 30 minutes then application server session expiry should be set to 1 hour.

Technorati : session timeout

Magic Of HTTP Header Variables

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.

Technorati : http header

How Oracle ERP stores password

Most Oracle Applications 11i implementations are vulnerable to a significant security weakness in the encryption of passwords within the application where an insider may be able to circumvent all application controls by accessing any application account or obtain the APPS database account password.

The fundamental issue is that the Oracle Applications 11i application account passwords are stored in the database encrypted using the APPS database password as the encryption key rather than using a strong, one-way hash algorithm.

Oracle Applications 11i stores passwords in two tables: FND_USER and FND_ORACLE_USERID. The FND_USER table stores application user account passwords and the FND_ORACLE_USERID table stores internal Oracle Applications database account passwords. Both tables use the same encryption algorithm to protect the passwords.


FND_USER table has two columns which stores the password.

1) ENCRYPTED_FOUNDATION_PASSWORD --> stores APPS pasword encryped using userid/password as a key.
2) ENCRYPTED_FOUNDATION_PASSWORD --> stores the user password encrypted using APPS password as a key.

If you know the username/password and you have access to fnd_user table and know the java code which is used for encryption then you can get the APPS password of that system. And if you know APPS password you can get anyones application password.

Both the above mentioned columns can also store following values

1) External --> This is set if the oracle application is using the external system like "directory server" for authentication.

2) Invalid --> For oracle internal users this value will be set.

3) ZG_error (error message) --> If encryption fails due to some reason then error message will be stored in this column. User will not be able to authenticate in that case.


ORACLE APPLICATIONS LOGIN PROCESS

The general Oracle Applications login process involves the following general steps -
1. The ENCRYPTED_FOUNDATION_PASSWORD and ENCRYPTED_USER_PASSWORD are retrieved from FND_USER if the account exists and is active.
2. The APPS password is obtained from ENCRYPTED_FOUNDATION_PASSWORD by using the username and password as the decryption key.
3. The user password is decrypted from ENCRYPTED_USER_PASSWORD by using the APPS password as the decryption key.
4. The decrypted user password is compared to the entered user password.

If APPS password is changed then all the stored passwords are re-encrypted with the new APPS password. APPS password should be changed using either "Oracle Users" form or FNDCPASS utility.

Thanks to : http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_Apps_Password_Issue.pdf

Technorati : inside IDM products

Types of attack on Password

It always seems to be very simple when we type our credentials to get into banking sites to do some transaction or commercial sites for purchasing some stuff but in this post I am trying to explain some of the types of attacks on password which can make you bankrupt, I am no kidding read on:

1) Hardware Device: When we talk about hardware we think that it will take time to install and only experts will be able to use this attack but NO this hardware device is very simple to install and can be installed by a kid in 10 seconds or less. See the below image to get an idea how simple it could be. Criminals have installed this device on bank machines to get the bank credentials which has costed millions of pounds to banks. Students installed them on there teachers system to get an access to the exam papers. there could be lot of other instances where these simple plugs can be installed and exploited.

2)Software Malware - Keyboard logger: We all enjoy free stuff and now and then we tend to use free softwares available on the internet. These softwares can save couple of dollars in your pocket but may cost you a lot. Imagine a scenario in which you down-loaded some free software and that software has a malware which modifies the OS kernel to get your credentials when you login to the system. These malwares can also capture the credentials when you access different banking sites. They can store these passwords locally and send them to there servers where attackers can use your bank credentials to transfer money to there bank or play in casino. Be very careful when you use free softwares.

3) Dictionary Attack: We all use dictionary and know that most of our password comes from one or the combination of words from dictionary. Yes you got me what I am going to talk. Smart people have written softwares which can be hooked in a PC to try all the possible combinations of password on a system. One solution to this problem which many organizations/banks have already implemented are locking the account after N number of unsuccessful password attempts.

4) Social Engineering Attack: If you get a call from a person saying that he is from the security team and they got an alert that your account is having some problem and it may lead to delete all of your data from the box. They can fix that for you if you can just let them know your account password, there are chances that some of us will agree to this and simply give it. I have seen many organizations where users give there choice of password to the help-desk persons and ask them to reset there password to the one they want. Users don't realize that this can give open door for other person to access to the secure stuff they should not be looking into.

5) James Bond Attack: Research institutes are challenging that they can listen to the keystrokes and guess the users password with 90% of accuracy. This is one of the reason that very confidential rooms does not let even a single voice go out of the room.

How Caching works???

In todays web world many concurrent users access the web applications. Most of the web applications access the database (relational/hierarchical) in some way or the other to authenticate the user and validate the user rights on the web application. If web applications access the database each time user access the site then it will throw the user to go to competior because they are smart and implementing cache :-)

Web applications use caching to store the session information and authorization rights information for fast access. If web application does not manage the cache then it has to access the database to get the authorization information each time user access some link. This task is time as well as resource consuming.

When a object is retrieved for the first time from the database, instead of discarding the information it is storred in a buffer called cache. There are lot of complications storing the retrieved information in the cache:

1) Since caching is meant for faster retrieval if we keep adding newly retrieved contents from the database it will grow to unmanageable size. Smart people remove the unnecessary contents from the cache based on different algorithims. Some of them are mentioned below

a) Least Recently Used
b) Least Frequently Used

2) Implementing cache using algorithim which makes the fast retrieval/search possible.

3) Consider a scenario in which user has rights to access 10 links on a site initially and those rights are cached. Later on those access rights are modified (added more rights or removed some extra rights) from the admin console. If the cache is not updated on time user will not be able to access what S/he has right to access. To overcome this problem chaching should be updated at the same time when rights are modified.

4) Consider another scenario in which there are two servers behind the load balancer and cached objects are local to the servers (i.e cache is not shared between both the servers). If one of the server goes for a toss what will happen for the cached objects. To overcome this scenario chache manager needs to send notification of the newly added/removed cached object to other server's in the cluster.

5) Implementing max time for which a cached object be alive in the cache. After that max time is reached the object should be removed from the cache and recached based on next request from the user.

6) Caching parametes should be configurable so administrators can change them based on requirements.

Caching frameworks

Several object-caching frameworks (both open source and commercial implementations) provide distributed caching in servlet containers and application servers. A list of some of the currently available frameworks follows:

Open Source:
Java Caching System (JCS)
OSCache
Java Object Cache (JOCache)
Java Caching Service, an open source implementation of the JCache API (SourceForge.net) SwarmCache
JBossCache
IronEye Cache

Commercial:
SpiritCache (from SpiritSoft)
Coherence (Tangosol)
ObjectCache (ObjectStore)
Object Caching Service for Java (Oracle)

Technorati : cache internal

How reverse proxy works ???

You must have heard the term reverse proxy couple of times but wondered what the hack is this. I am going to give some idea about it in this post but before going to reverse proxy i would like to give an idea how forward proxy works.

Forward Proxy: A forward proxy acts as a gateway for a client's browser, sending HTTP requests on the client's behalf to the Internet. The proxy protects your inside network by hiding the actual client's IP address and using its own instead. When an outside HTTP server receives therequest, it sees the requestor's address as originating from the proxy server, not from theactual client. In the organizations you configure this in your browser setttings and most of the things happens behind the scene.

Reverse Proxy: Reverse proxy works when a request is sent to the organization web server from outside. It sits in front of the web server.
It acts as a gateway to an HTTP server or HTTP server farm by acting as the final IP
address for requests from the outside. The firewall works tightly with the Reverse Proxy to help
ensure that only the Reverse Proxy can access the HTTP servers hidden behind it. From the
outside client's point of view, the Reverse Proxy is the actual HTTP server.

Benefits of Reverse Proxy

1. Clients now have a single point of access to your HTTP servers.


2. You have a single point of control over who can access and to which HTTP servers you allow access.


3. Easy replacement of backend servers or host name changes.


4. Ability to assimilate various applications running on different Operating Systems behind a single facade.

Downside of Reverse Proxy

1. If reverse proxy fails and there is no failover suppored then whole network access goes for a toss.


2. If an attacker does compromise Reverse Proxy, the attacker may gain more insight into your
   HTTP server architecture; or if the HTTP servers it is hiding are inside the firewall, the attacker might be able to compromise your internal network.


3. A lot of translations have to occur for the Reverse Proxy and the
   firewall to do its translations, so requests may be fulfilled a little more slowly.

Many web servers plug-ins are available which support the reverse proxy functionality. For example Apache module mod_proxy supports both forward and reverse proxy settings based on requirements.

How to get plain text password in Active Directory???

I have seen many products synchronizing password/ sending password synch events to IDM products when user changes the password in Active Directory. Due to security reasons Windows does not allow users to get the plain text password once stored in the directory but Microsoft has given a way in case we have to get the plain text password for above reasons and also to enforce a specific password policy which can not be configured out of the box configurations.

There can be chain of password filter DLL's installed which will be called one after the other in the sequence defined in the registry (I will discuss this configuration in a bit)

Password Filters

Password filters provide a way for you to implement password policy and change notification.

When a password change request is made, the Local Security Authority (LSA) calls the password filters registered on the system. Each password filter is called twice: first to validate the new password and then, after all filters have validated the new password, to notify the filters that the change has been made. The following illustration shows this process.

Important Functions

InitializeChangeNotify
Indicates that a password filter DLL is initialized.
PasswordChangeNotify
Indicates that a password has been changed.
PasswordFilter
Validates a new password based on password policy

To install and register a password filter DLL
Copy the DLL to the Windows installation directory on the domain controller or local computer.
To register the password filter, update the following system registry key:
HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Control Lsa
If the Notification Packages subkey exists, add the name of your DLL to the existing value data. Do not overwrite the existing values, and do not include the .dll extension.
If the Notification Packages subkey does not exist, add it, and then specify the name of the DLL for the value data. Do not include the .dll extension.
The Notification Packages subkey can add multiple packages.
Find the password complexity setting.
In Control Panel, click Performance and Maintenance, click Administrative Tools, double-click Local Security Policy, double-click Account Policies, and then double-click Password Policy.
To enforce both the default Windows password filter and the custom password filter, ensure that the Passwords must meet complexity requirements policy setting is enabled. Otherwise, disable the Passwords must meet complexity requirements policy setting.

Curtsey: I took some of the content in the article from Microsoft site directly.

List of SSO Products

Here are some of the industry wide used SSO products.

• Single Sign-On (Computer Associates)


• SecureLogin (Novell)


• AccessMaster Single Sign-On (Evidian)


• AccessMatrix Universal Sign-On (i-sprint)


• ActivIdentity SecureLogin (ActivIdentity)


• Entrust/SignOn (Entrust Technologies)


• MetaPass SSO (MetaPass)


• OneSign (Imprivata)


• OpenSSO (Sun)


• Passwerks (ASG Technologies)


• SecureLogin (Protocom)


• SP Sign-On (Unisys)


• SSO Plus (PassGo)


• Tivoli Global Sign-On (Tivoli)


• V-Go(Passlogix)

Technorati : SSO products

Is probing login.jsp from loadbalancer good option???

Loadbalancing is good for applications for failover conditions. Loadbalancers needs to know the status of the server for redirecting the clients. Many a times people thinks of pointing to login page for load balancer. This seems to be simple but think about the complication of a login page before pointing from load balancer.

Before describing the responsibilities of login page i would like to give an example of load balanced application.

There are two servers behind the load balancer and if a user is logged into one server(Server 1) and directly goes to another server (Server 2). Server 2 should not redirect the user to login page again as backend is same for both the servers.

Now lets see what login page responsibilites are
1) Check if the user is authenticated or not.
2) If the user is authenticated then redirect the user to requested page.
3) Check what access control user has to access the application.
4) Cache the user access rights if user is authenticated.

These are some of the examples and for performing every operation Login page has to call lots of vendor specific API's which are costly and some times they have memory leaks.

Think about a scenario when load balancer is configured to probe each server every 5-10 seconds.

Think again ????

I hope you might have already guessed that Login page is not the right approach at all.

Then what is the solution???

It's always better to build a very light weight application or simple page which is hosted on the server which tells if the server is up or not.

But this will just tell if the server is up or not, what about the repository server which server contacts???

You question is absolutely correct. But again instead of configuring Login page which is costly as discussed above it's better to build a custom page which just checks if the backend repository is up or not.

Hope this helps to some of my friends reading this article.

Technorati : Load Balancer and login page

How HTTP Keep Alive works?

HTTP Keep Alive
Http Keep-Alive seems to be massively misunderstood. Here's a short description of how it works, under both 1.0 and 1.1, with some added information about how Java handles it.

Http operates on what is called a request-response paradigm. This means that a _client_ generates a request for information, and passes it to the server, which answers it. In the original implementation of HTTP, each request created a new socket connection to the server, sent the request, then read from that connection to get the response.

This approach had one big advantage - it was simple. Simple to describe, simple to understand, and simple to code. It also had one big disadvantage - it was slow. So, keep-alive connections were invented for HTTP.

HTTP/1.0
Under HTTP 1.0, there is no official specification for how keepalive operates. It was, in essence, tacked on to an existing protocol. If the browser supports keep-alive, it adds an additional header to the request:

Connection: Keep-Alive

Then, when the server receives this request and generates a response, it also adds a header to the response:

Connection: Keep-Alive

Following this, the connection is NOT dropped, but is instead kept open. When the client sends another request, it uses the same connection. This will continue until either the client or the server decides that the conversation is over, and one of them drops the connection.

HTTP/1.1
Under HTTP 1.1, the official keepalive method is different. All connections are kept alive, unless stated otherwise with the following header:

Connection: close

The Connection: Keep-Alive header no longer has any meaning because of this.

Additionally, an optional Keep-Alive: header is described, but is so underspecified as to be meaningless. Avoid it.


Curtsey: http://www.io.com/~maus/HttpKeepAlive.html