I have configured Local STS with my web application (which is hosted in IIS 7 and has the host name as www.abc.com) and it can receive the claims from the STS and it can login. Now I have added another host name (www.xyz.com) to my web application. If user a login to a page in the application using www.abc.com/page1 and it redirects to local STS and it authenticates the user and adds the security token. Now if the user visits www.xyz.com/page2 it also redirects to the STS for authentication.
If a user either logged in www.abc.com or www.xyz.com they need to access the other domain page with out login. Is it possible? How do we achieve this?
In broad strokes, if you have two different relying parties, each needs to route the user to the IDP. If the IDP is configured for single sign on, the user will only notice the routing to the IDP the first time. On the second routing, (assuming same browser session and that the routing is within the lifetime supported by the IDP) the user will be authenticated without seeing a page at the IDP and being required to present credentials.
So, part of your answer hinges around what you mean by login: if you mean "experience a challenge and enter credentials" by log in, you should be able to enable this by simply ensuring that the IDP is configured for single sign on.
On the other hand, if by login you mean the redirect to the IDP, then you need to make sure the application is able to share state across the different page names. Note that usual management of state is via cookies, and note that a cookie for abc.com will not be returned to a web page named xyz.com. There are a number of clever ways to resolve this, although i am not aware of any simple application configuration solutions. One example is to have some part of both the abc.com page and the xyz.com page accessed by the url shared.com. State cookies can then be set by the shared.com transaction when logging into abc.com and read by the shared.com transaction when subsequently accessing xyz.com.
I've never had to implement such a cross domain cookie solution and have only had off-hand conversations with colleagues about it: we've always found the silent redirect of single sign on to meet our requirements. Careful research into the privacy impact of such a solution and the likelihood that such cookies might be blocked should be considered before development.