SSO and Web Hosting companies/Telco

Over last few months, something that I have been thinking why have the hosting companies not started providing sign-on services. It is a chance for both the hosting companies to provide this important service and at the same time allow the chosen vendor to prove how well its product works. But then after some deliberation this is what came out

1. Where is the Apache/tomcat of SSO? Well if look at most of the companies that provide very low cost hosting service(and hence have very high volume), are able to keep them low by using free software and so till an open-source stable system is available, the guys are not going to bother about this. But at the same time, the SSO vendor can do some kind of strategic partnership with a big hosting company and use their solution as a reference implementation. This is something similar to what IBM has done when it provided DB2 to sourceforge.net(I am not sure about this?) and you find it in a lot of places
2. How confident are we?: In order for that to happen, the vendor itself has to be confident about its product. Even after almost 2-3 years since some of the products came to market, some of the products have their limits when it comes to deployment capacity and stability. At the same time to be fair implementing a SSO is a complex challenge in itself and so far complete suites are not available that target hosting companies (i.e. a combination of products that will help migrating existing hosting to SSO platform).
3. Is it worth it?: So how would a company go about hosting such a service. I guess most of companies have apache servers serving multiple domains. The SSO product would be installed on this and configured to protect specific set of domain. Then there would be directory/database that would have to be managed with so many identities and passwords. So far the identity has been distributed across different application being hosted. Now this needs to be consolidated and brought into single place. Will the existing products be able to handle the onslaught? May be.. may be not...having 15-20K is one thing and 1Million is a totally different beast. I have seen products that can take onslaughts of that order, but what is that going to add to user experience(and what kind of hardware upgrade be required) or a different architecture of distributed, indexed database may need to be developed so that smaller servers and databases can be used to attack the beast(may be vendors need to learn something from google on that ). Last but not the least a simple integration process should be available before the hosted applications can be migrated. In order to allow existing application to continue, the products should send the id and password specific to the back-end application for authentication. This automatically means the whole issue of identity and password mapping and synchronization comes in. Where will the new identities be created or where will password changes and reset be managed or which password reset system will be used(at the application user registration console or SSO registration console) and how will that be added to applications' database(this is the job for superman aka "stable metadirectory with very simple user interface for configuration" !!). Now as we go along, what are the approaches available for backend application integration. Most of the time it can be the simple header variable based integration. Given that the products need to grow inorder to make such deployments simpler, it may not be right time for implementation. The lessons learned from the Credit card processing services available for hosted application should form a very good model to decide on how the hosted applications will be comfortable with the entire process.
4. Where do we stop?: Now what about group information, user attributes? So basically should SSO manage some or all the information. I think user identity may be first step, but ultimately all the user information may have to be migrated to SSO with generation of the credential that is sent to back end specific to the application. We have SAML in combination with 2 method(login and logout) based integrated authentication modules to thank for that(where are they?). Besides that since the information to be sent to backend have to be specific to application, the product should have a good way of managing this information on per-application basis(I have not seen very good attempts on that side).
5. What about FIM(Federated Identity Management)?: I think that is a long way into the future. Let the corporate jump on to the band wagon and solve the trust, liability issues before hosting company should jump on this. May be the market will evolve like certificate market where a set of third-party will be trusted agent which will issue proxies(as hosted application, certificates, web service or god knows what) that will be trusted by both most of the parties and these third-parties will consolidate or trust each other over long run. Or the market will never grow beyond the one to one OR consortium based trust. But if third party companies can really take it to next level it will be good for every body.

So, these are my thoughts on the subject. Let us see how things really work out.