Credential Mapping/Management, WS-Trust: Some use cases

The basic idea of Credential Mapping service is to provide necessary data to the service's client which will help client to identify with a specific security domain. Based on the security policy requirements of security domain, this authentication and identification data can take various forms like id/password, token (cert, kerberos ticket, etc.). This concept has been implemented in kerberos Ticket based authentication system, Global sign on (GSO), Credential Mapping Providers, Security Token Service and enterprise reduced sign on. In this article I will try to discuss why such a service is important as a separate independent service within an enterprise or for an end-user.
As discussed above, the credential mapping or token generation service (here after referred as security token service or STS), has been an important part of Authentication systems, Single Sign on integration, Legacy Application integration, and Federated Sign On. Due to the wide variety of the application that can actually use such a service, it would make sense to develop an infrastructure that provides solely this service. The other infrastructural components can integrate with STS using various interfaces (like WS-Trust, Kerberos TG Service, and so on). I will try to explain some additional use-cases / reasons why this service is important as a enterprise level service instead of being part of individual solution.

• Federated Sign On: I assume that based on the IBM and PingID design descriptions, there is an understanding in the FSSO space that the STS is one of the ways to go. At the same time I have been thinking that STS is an important component that if separated, can help build a more secure federation system. The federation single sign on is key to other enterprises and services and thus comes with a very important responsibility of protecting it. So apart from the standard ways to protect, one of the idea that would make sense would be to ensure that the Federated SSO infrastructure can be broken in to separate components and managed separately to reduce the chance of external and internal misuse. In that case, the STS would be a good representative component that can be managed separately from the rest of the Federated SSO infrastructure.
• Desktop Single Sign On: Well with the idea of user-centric sign on/identity management (aka. infocards) taking hold along with good deal of enterprise reduced sign on products already in place, the concept of desktop based single sign on solutions is well entrenched in the market. While the infocards is basically built on the idea of the WS-Trust from the bottom up and thus would require a STS service, the enterprise reduced sign on have not yet looked at this aspect of the market (or atleast I do not know of any such product). At the moment most enterprise reduced sign on products are built around the basic idea of password based sign on with a back end credential manager that manage the identity's password. These product in combination with password synchronization tools are giving a good ROI as identity management solution. This segment of IAM has been missing from the Federation Sign on discussions (like Liberty and SAML) and is very apparent in the profile descriptions which do not consider desktop based Identity provider as a possibility (though interpretation of such a solution is possible). I think as these two parts of IAM solution set need to come together. We should see the move of Enterprise Reduced sign on(Enterprise RSO) products to accept the concept of STS and the Federated SSO standards to acknowledge / define the desktop based signon profiles much better. This would mean that if Enterprise RSO need to grow it must try to break its solution in to desktop based application recognition technologies and token/password retrieval functionality with later being part of Enterprise/Personal STS infrastructure.
• Personal Identity Providers: The idea of personal identity providers have not been a something that I have seen discussions about. This basically is built on the requirement that 80-90% of the web sites that persons access do not need personal information for security purpose but to provide more personalized service. In order to provide "persona" information to these websites, external Identity provider is an overkill. It would be worthwhile to develop a personal STS system (some thing similar to self signed certificates) that would be fully controlled by the user and will not depend on existance of public identity providers. I feel this is one of the basic reasons why the PKI never took off since there was no desire of the industry to provide an out of box experience to the users which would hep them get acclimatized to self signed certificate system and then gradually move to public certificate providers for premium services. This means that the STS system has to be built into every user terminal and tied to the user's session on that workstation. Another important facility provided by these personal identity provider systems is to have usable STS system even during Identity Providers downtime (due to either attack or being non-reachable due to network not being available or some usecases around providing identity to network centric identity systems) being a secured cache of claims. An important point to keep in mind is that personal identity provider should not be built in to a user centric solution like infocard because that makes them an easy target for the hackers. This service has to be externalized and standardized so that various implementation can compete with each other based on the user's desire of security and personalization (so for example there can be smart card based solution along side software based solutions).

One of the basic premise of this idea of separate STS is the deployment of a service that will become single point of attack for getting passwords and/or tokens. But I think, based on the acceptability of the single sign on technologies and proliferation of password databases, password synchronization technology, the STS service is very much acceptable as an Application/Database layer implementation (instead of living in DMZ) with in an enterprise.