Authentication in Cloud Application: Claims-Based Identity Model

Authentication in Cloud Application: Claims-Based Identity Model Upen H Nathwani 1*, Irvin Dua 1, Ved Vyas Diwedi 2 Abstracts: Basically cloud service provider (CSP) give facility to access Software as a service (SaaS) applications hosted in public cloud to end users of particular organization, but to gain access to multiple application hosted in cloud environment will increase the risk of eavesdropping by entering sensitive data like username and password multiple times for each hosted application. Also cloud user need to remember the username and password. Now, somehow if we forget our credential, we have to remember specific details like security questions. This paper is describing how to insure against the risk of supporting a business model where there is a strong likelihood of a third party risk by proposing federation model with the use of claims based identity where we are providing one user credential, i.e., username and password and that will be sufficient to access all cloud oriented application. INTRODUCTION Claims-based identity is a familiar way for applications to acquire the identity information they need about users inside their organization, in other organizations, and on the internet. It also provides a reliable approach for applications running on-premises or in the cloud. [1, 6, 7] The key strength of claims-based identity is that it abstracts the individual elements of identity and access control into two parts; a single, general notion of claims and the concept of an issuer or an authority. [1, 7] A claim is a statement that one subject, such as a person or organization, makes about itself or another subject. For example the statement can be about a name, group, buying preference, ethnicity, privilege, association or capability. The subject making the claim or claims is the provider. Claims are packaged into one or more tokens that are then issued by an issuer, commonly known as a security token service (STS). [2, 6, 8] Basics of Claim based Authentication & its Components Fundamental things involved in claim based authentication are mainly Identity, Tokens, Claims, Identity Provider or Security Token Service; RP (Relying Party). Let discusses them one by one. What is an Identity? Identity is a group of information that can uniquely identify anything. Most of the other things also have identity like your own PC, Vehicle, etc. But here, we are talking about person. So in this digital era, a digital identity is a group of information to identify a person using unique attributes. [3, 10] Token and Claims When this digital identify is passed over wire, it is passed as a stream of bytes and that is known as token. Token contains some set of information about the user in the Claim format. A token can contain multiple claims and 1Computer Engineering P. G. Studies, Gujarat Technological University, Ahmedabad, Gujarat, India. E-mail: upen.nathwani@gmail.com *Corresponding author 2ECE Department, Noble Group of Institutions, Junagadh Affiliated to Gujarat Technological University, Gujarat, India. every claim contains some specific information. The token is digitally signed so that it can be verified at the receiver end. We can show this in Figure 1. [1, 3] Sometimes token can be XML based Security Assertion Markup Language (SAML) format. But now, the application uses a rather simpler token call as Simple web Token (SWT). So the benefit is that here, we do not pass user credential but we can also pass some other information of the user to the application. Identity Provider and STS Identity provider is the key in this technology, this actually authenticates the user and creates the token with claims, as per the requirement and digitally signs it before sending. Identity provider is also known as Security token service. Figure 2 shows how do the STS work. [1] RP (Relying Party) Relying party are the software component that use these Identity Providers for authentication. They just need to understand and verify the token and get all the data from the token itself which is required. But before all this, RP needs to build a trust relationship and tell the Identity provider what all data is needed for a user. So that next time it receives a token, it can verify the issuer and get the required data. Issuing Authority There are various types of issuing authorities, from domain controllers that issue Kerberos tickets, to certification authorities that issue X.509 certificates. This issuing authority is a Web application or Web service that knows how to issue security tokens. It must have enough knowledge to be able to issue the proper claims given the target relying party and the user making the request, and might be responsible for interacting with user stores to look up claims and authenticate the users themselves. [1] Problems with Current Authentication Mechanism We make several user accounts at several portals/websites in cloud environments. Every time we need to access the corresponding website resides at cloud, we need to remember the username and password and if somehow we forget the password, then we need to remember some 1

Figure 1: Claims Format [10] Figure 2: Security token service system Figure 3: Current authentication systems specific details like security question, etc. to get the access of the account again. And every time we might not remember all these details. Also, it is never advisable to write your user credentials physically. One more issue is, most of the applications use some authentication mechanism, mainly Classic User Name and Password. As most of the developers are not really security experts; they leave loopholes during application development which are easy to break. Hence it is a major security risk. Most of the developers have some or the other day worked on the Single Sign On feature. It's not always been a simple task. It leads to a lot of challenges and many issues after the application is deployed on UAT (User Acceptance Test)/Production. As a user, we create new user credentials (username and password) to many applications on the internet like Face book, Yahoo, Gmail, etc. and some in-house sites like Figure 4: Functional Role of Identity Provider some college portal, etc. or some enterprise application. So to create new credentials every time and to remember all these credentials and see that all are secure enough is very tedious. If there are any errors, you might lose some credentials and could end up in a big loss. The Current Authentication Scenario When we develop cloud enabled application which has an authentication web page, we need to understand how it works. Figure 3 shows the current scenario for authentication process. When user logs in, credential/ Identity is assigned to that session and that Identity is maintained throughout the session until the user logs out or it expires. ARCHITECTURE FOR IDENTITY PROVIDER COMPONENT Figure 4 shows to access the available cloud applications, user just need to have one user credential, i.e., username 2

Figure 5: Identity in private cloud [12] Figure 6: Claims based identity in public cloud Figure 7: Overall claims based identity working model and password and that is enough to access all your portals/websites. This can be an ideal situation. Here are some authentication/identity providers which are used by various applications whenever a user tries to access some application. The cloud application checks whether the user is authenticated or not, if not, it forwards the user to the Identity provider which actually authenticates the user, gives a token to the user and forwards the user to the application. The cloud application verifies the token and the user is allowed to access the application. But this is not so easy in a web scenario. There are few confront 1) who are the Identity Providers? 2) What is the data needed for the relying party, i.e., what data can be transferred from Identity provider and in which form 3) if there are multiple Identity providers. How does the application trust them? Nowadays there are various Identity providers like, facebook, WindowsLive Id, Google and many others. And even we can develop our own Identity provider for on premise applications. This can be used on Cloud as well. Now if we are developing a cloud application and my application uses some Identity provider to authenticate a user, then the application must understand the token of that Identity provider and also there must be trust relation between the application and Identity providers, so that the application can rely on the token sent by that Identity provider. HOW CLAIMS IDENTITY WORKS? Private Cloud Scenario User inside the enterprise attempts to access a claimsaware application that s deployed in Private Cloud. This situation is common nowadays as more applications are becoming claims aware and the private cloud is becoming popular in large organizations. This scenario is explained in Figure 5. Public Cloud Scenario (SaaS) Accessing a SaaS provider, in which an enterprise uses a service such as Sales force or a hosted email provider without maintaining separate passwords at every provider. 3

Table 1: Comparison between Kerberos/AD & Claims based Authentication Kerberos / Active Directory In AD, every authenticated user has one or more Kerberos tickets that contain identity information. A Kerberos ticket contains a payload, called the access token that asserts what security groups the user is a member of. The resource (e.g., a file server) trusts this assertion because the ticket is cryptographically confirmed to be from a valid identity source In AD, a Kerberos ticket has time restrictions regarding when it can be used. This prevents replay attacks, in which packets are captured then played back to a server at a later time in an attempt to compromise it. AD Kerberos ticket is encrypted with either the ticketgranting server key (for a ticket-granting ticket TGT) or the user key (for a session ticket). The scope of an AD Kerberos ticket is essentially within the enterprise. Public Cloud Scenario (IaaS) In Public Cloud users in the identity provider s enterprise need to seamlessly access application deployed in the Public Cloud. The only one largest difference between private cloud scenario and public cloud scenario is that the CSP may have its own STS, and the application service trusts it alone. The federated trust agreements that the CSP establishes with its customers are supported by the STS, rather than the application service. This CSP configuration is more scalable than one without an STS because the resource load of potentially thousands of trusts is focused on the STS instead of the application service and won t affect the application service s resources. It s also more secure, because the application service doesn t trust any external claims-only the claims generated by its own STS in Public Cloud. IMPLEMENTATION ARCHITECTURE Figure 7 shows the scenario of building claims-aware WCF (windows communication foundation) services using WIF (windows identity framework). Mainly there are three participants in a claims-aware web service scenario: the webs service itself, the end user, and the Security Token Service (STS). [9] Windows Communication Foundation (WCF) is a framework for building service-oriented applications. Using WCF, we can send data as asynchronous messages from one service endpoint to another. A service endpoint can be part of a continuously available service hosted by web server, or it can be a service hosted in an application. An endpoint can be a client of a service that requests data from a service endpoint. The messages can be as simple as a single character or word sent as XML, or as complex as a stream of binary data. [9, 11] Windows Identity Foundation (WIF) is a Microsoft technology that provides framework for building claims/identity-aware applications. WIF contains APIs for building ASP. NET or WCF based security token services as Claim based Authentication A basic construct of claims-based authentication is the token, formatted in Security Assertion Markup Language (SAML). SAML token is similar to a Kerberos ticket. The payload of this assertion contains a potentially broader set of identity information, called claims, than a Kerberos ticket holds. A claim can be anything you define it to be: name, email, phone number, age, privilege level, meal preference, etc. An SAML assertion conditions can restrict when the assertion is valid, who can use the assertion, how many times it can be used, and whether the assertion can be delegated. An SAML assertion is signed and can have various degrees of encryption from the identity provider that created it, from individual components to the entire assertion. SAML token has no restrictions of this kind at all. This means that a claims-aware application can authenticate users equally comfortably inside or outside the corporate firewall. well as tools for building claims-aware and federation capable applications. [10, 11] SOFTWARE AND HARDWARE REQUIREMENT SPECIFICATION Software Specification Operating System: Windows 7 Software: ASP.NET, C#.NET, WCF IDE: VS 2012 Hardware Specification Processor: Pentium-IV Speed: 1.1GHz RAM: 1GB Hard Disk: 40 GB General: Keyboard, Monitor, Mouse COMPARISON Table 1shows Comparison between Kerberos/AD & claims based authentication. CONCLUSION Here, we conclude that by using claim based architecture for achieving strong authentication, we can reduce phishing success, password fatigue and time spent to retype password for a single user, and it is also helpful to reduce IT cost for help desk. It does provide security on all level entry/exit of access without the inconvenience of reprompting users and Centralized reporting for compliance adherence. Claims-based identity enables cloud applications to know certain things about the user, without having to interrogate the user to determine those facts. The facts come with the claim. It can greatly simplify the authentication process for the user because he or she doesn't have to sign in multiple times to multiple applications. A single sign in creates the token which is then used to authenticate against multiple applications, or web sites. 4

REFERENCES AND NOTES 1. http://msdn.microsoft.com/en-us/library/hh873308.aspx. 2. http://www.infoq.com/news/2009/10/guide-claim-based- Identity. 3. http://msdn.microsoft.com/en-us/library/ee517291.aspx. 4. http://it.toolbox.com/blogs/business-technologist/identitymanagement-in-cloud-computing-41054. 5. Cloud Security and Privacy, An Enterprise perspective on Risk and Compliance, O REILLY. 6. http://msdn.microsoft.com/en-us/library/ff359101.aspx. 7. http://www.windowsecurity.com/articles/claims-based- Identity-What-does-Mean-You-Part1.html. 8. David F. Carr, What s Federated Identity Management? http://www.eweek.com/c/a/channel/whats-federated- Identity-Management/. 9. http: //msdn.microsoft.com/ en-us/ library/ ms731082. aspx. 10. Sean Deuby, Ease Cloud Security Concerns with Federated Identity, http://www.windowsitpro.com/article/activedirectory/answer -Cloud -Security- Concerns- Federated- Identity-.aspx. 11. http: //msdn.microsoft.com /en-us /library /ee 748475. aspx. Cite this article as: Upen H Nathwani, Irvin Dua, Ved Vyas Diwedi. Authentication in Cloud Application: Claims-Based Identity Model. Inventi Rapid: Cloud Computing, 2013(1): 1-5, 2012. 5