The same type of application can be used by employees of a business through the cloud. i.e the user is accessing SharePoint materials on a computer that is outside of the business location. The same methods will be used as in the previous section to make this happen. With the claims based identity in place it will be a smooth process for all involved.
There are some complex issues that do take place though but the user doesn’t see them For example when the user asks for the token the Kerberos ticket is what is used inside of an enterprise. When they are outside of it the user may need to have a user name and password authenticated. The fact that all of the users here are employees of the business means they already have an account set up for them inside of the AD DS. They will be able to log into the application easily. However, there are times when a business wants to allow those that are customers to be able to log into it as well. With claims based identity this idea will now be possible. The developer can have the information for external users as well as internal users together in the AD DS so that they can be accessed through ADFS v2. The difference will be that the information for the external users will be stored in the AD LDS (Active Directory Lightweight Directory Services). Through the use of such technology there is a directory in place that is very simple for the ADFS v2 to use. Now, you may be asking yourself that if the user with the internet is still going to need a username and password then how are things better through the use of the claims based identity methods?
The biggest benefit is that there is no longer a need for a password to be assigned to each application that someone uses. They will have only one for each STS that is used. As a result the applications out there don’t need to have storage for tons of password information. The smaller amount of storage space can be used by the STS themselves. The requests for tokens are given from CardSpace which means a user doesn’t have to enter a URL to get to the STS. There are plenty of hackers out there that engaging in phishing to get passwords from cloud users. Now it is going to be even harder for them to be able to gain access to that type of information. The method they use to gain them is through entering a fake URL in place of what looks like a real one from the company. That will no longer be part of the process.
Sometimes as opposed to an organization using their own identity provider in other instances it will be better to use an external organization for it. For example if you use Windows Live ID as a way to access a STS on the cloud. You don’t need to have your own identity provider in order to create an application that will accept tokens from these types of external providers.
The process begins with the user accessing the application and then choosing an identity. The token for that identity is going to be provided by an STS through an external provider. After the token has been issued the system will submit it as usual and the claims within it can be accessed. Please note that one of the external providers in this given example is Microsoft. Yet with claims based identity there isn’t any particular provider that has to be used. When you use an STS it can also act as the identity provider. What has to occur though is convincing the application to trust the claims that are in the tokens they are able to allocate.
More Here
Courtesy:http://www.sharepointsecurity.com/sharepoint/claims-based-authentication/claims-usage-on-the-cloud/