User Centric Access Control in Cloud Using Identity Management Karunanithi. D, Shiyamala Devi V. P, Sambath. M

Transcription

1 User Centric Access Control in Cloud Using Identity Management Karunanithi. D, Shiyamala Devi V. P, Sambath. M Abstract Having numerous login for many service providers brought an pathetic situation among many organizations in order to avoid verifying identity of each individual every time when they login the challenge to overcome the multiple accounts is by providing Identity as a Service (IaaS).The overall objective of security, private and trust challenges arise from the technological underpinnings of cloud computing is a principle to guide decisions and achieve rational outcomes to confirm that users of cloud environments are given total protections, to strengthen and stabilize a world leading cloud ecosystem. Hence, our concern is that currently a number of challenges and risks in respect of security, privacy and trust exist that may damage the fulfilment of these policy and so we upgrade in various implementations of cloud computing through identity management which reduces the burden associated with user accounts and privileges across multiple target resources, improves the Qos for users through measures such as self service password reset,real time synchronisation of changes from authoritative identity data sources across multiple target resources. Index Terms Cloud Computing, Identity Management, OpenIDSecurity, Privacy and Trust. I. INTRODUCTION Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction [1]. The literature identifies four different broad service models for cloud computing: 1.Software as a Service (SaaS), where applications are hosted and delivered online via a web browser offering traditional desktop functionality, eg, Google Docs, Gmail and MySAP [2][Fig.1]. 2. Platform as a Service (PaaS), where the cloud provides the software platform for systems (as opposed to just software), the best current example being the Google App Engine [2]. 3. Infrastructure as a Service (IaaS), where a set of virtualized computing re sources, such as storage and computing capacity, are hosted in the cloud; customers deploy and run their own software stacks to obtain services. Current examples are Amazon Elastic Compute Cloud (EC2), Simple Storage Service (S3) and Simple DB [3]. 4. Hardware as a Service (HaaS), where the cloud provides access to dedicated firmware via the Internet, eg, XEN and VMWare [4]. Fig. 1 Customer View vs. Provider View II. EVOLUTION OF CLOUD A. Private clouds, services are provided exclusively to trusted users via a single-tenant operating environment. Essentially, an organizations data centre delivers cloud computing services to clients who may or may not be in the premises [2]. B. Public clouds are the opposite: services are offered to individuals and organizations who want to retain elasticity and accountability without absorbing the full costs of in-house infrastructures. Public cloud users are by default treated as untrustworthy [2]. C. Inter Clouds, Combining both private and public cloud service offerings [2] [Fig.2]. Fig 2. Types of Clouds 136

2 I. ARCHITECTURE OF CLOUD COMPUTING 5. Respond to the pressure from the growing numbers of Web-based business applications that need more integration for activities such as single sign-on [8]. Fig 3. Cloud Reference Architechture The cloud computing architecture of a cloud solution is the structure of the system, which comprises on-premise and cloud resources, resources, services, middleware, and software components, geo-location, the externally visible properties of these, and the relationship between them. The term also refers to documentation of a system s cloud computing architecture. Documenting facilities communication between stakeholders, documents early decisions about high level design components and patterns between project [5]. A. Reference Architecture: Basis for documentation, stakeholder and team communication, payment, contract and cost models [5]. B. Technical Architecture: Structuring according to XaaStack, adopting cloud platform paradigms, structuring cloud services and cloud components, showing relationships and external endpoints, middleware and communication, management and security [6][Fig.3]. C. Deployment Operation Architecture: Geo-location check, operation and monitoring [7]. III. IDENTITY MANAGEMENT Identity Management (IdM) is a convergence of technologies and business processes. There is no single approach to identity management because the strategy must reflect specific requirements within the business and technology context of each organization. This convergence has drivers from both the business and technology perspective to: 1. Enable a higher level of e-business by accelerating movement to a consistent set of identity management standards. 2. Reduce the complexity of integrating business applications. 3. Manage the flow of users entering, using, and leaving the organization. 4. Support global approaches/schemas for certain categories of operational tasks. IV. ARCHITECTURE OF IDENTITY MANAGEMENT Open AM takes a unique architectural approach to addressing the Identity Management challenge. The following benefits: Faster Time to Market Allows companies to rapidly respond to changing business and regulatory needs. Scalability Scales from hundreds to millions of users. Portability Allows integration across technologies such as Java,.NET, PHP, Groovy as well as across operating systems and repositories. Simplified integration resulting from adherence to standards and service architecture. Lower implementation and total cost of ownership [3]. At the heart of the OpenIAM architecture is an Enterprise Service Bus (ESB). It is through the ESB that the 20+ IDM services are exposed. The ESB which allows for protocol translation allows these services to be consumed by a wide variety of technologies. Such flexibility allows an ESB based architecture to scale as an enterprise grows: Service mediation - independent, re-usable services are separated from protocol definitions and network requirements. Data Transformation - data may be exchanged across different formats and transport protocols. Routing - route, filter, aggregate and enrich messages depending on content. Following common IDM use cases, users are usually created from an authoritative source. Common examples of authoritative sources include Human Resources systems, Registration pages, or Identity Administration tools such as those found in the OpenIAM IDM system. Once an employee has been created in the Authoritative Data Source, they can be synchronized with the Identity system and the systems are involved in synchronization. These may include Active Directory, LDAP and other repositories. Based on the organizations rules, the synchronization and provisioning processes may leverage job roles to automatically provision the user into systems that a person needs for their specific job. For example, if an employee joins the firm as a sales person, they may be provisioned into systems that have been identified as being necessary for a sales person. These may include: LAN, and CRM. Automating these routine tasks achieves a number of objectives. First it achieves the 137

3 concept of a zero-day start where employees can be productive on the day they join the firm. Next, since these tasks are defined in a workflow, we can monitor their execution and maintain an audit trail. The audit information can be used to monitor security as well as compliance needs. Once an employee or user has been granted access, they can then access the appropriate applications. These applications may be web- based and non-web-based applications. These applications can be configured to make use of the other identity services found in OpenIAM. This approach allows corporations to centrally enforce security policies in a consistent manner across a heterogeneous set of systems and devices. Once the user has been provisioned, they may use the self service application to carry out a number of common tasks including: Changing your password Updating your profile Directory lookup The identity manager removes the user from the systems that they no longer need and adds the user to systems that they do need access to. Similarly, if a user leaves the company, all access would be promptly terminated. All of these changes are logged in the audit sub-system. The audit service may be configured to capture a broad set of events ranging from the provisioning of an employee, accessing of corporate resources, authentication, and to the changing of an object in a custom application through the use of API. The level of detail that is captured in each event is configurable through tools in the centralized web based administration console. Once audit events have been captured, the information can be presented through a series of reports and graphs [11]. A. Identity Middleware Enterprise Service Bus (ESB): The ESB is a central component in the OpenIAM SOA technology stack. An ESB works by acting as a transit system for carrying data between applications within or outside your intranet. The ESB defines a series of stops, or "endpoints", through which applications can send or receive data onto or from the system. The heart of the system, the messaging bus, routes messages between endpoints. These endpoints provide a simple and consistent interface to vastly disparate technologies such as HTTP(S), JMS, SMTP, JDBC, TCP or file [Fig.4] Services: The services layer represents an exhaustive set of services that serve as the foundation of the identity system. These services provide features such as Authentication, Authorization, Password Management, Provisioning, and Policy. These services have been designed for scalability and extensibility. For example, the Authentication service has a pluggable architecture that allows you to introduce new methods of authentication. The service end-points are through the ESB and can be easily consumed by applications regardless of technology [10]. Fig 4. IDM Architecture Business Process Engine: The Business process tier consists of a standards based business process engine that executes processes that have been created using the graphical process modeling tool. The modeling tool runs within the Eclipse IDE and can be deployed onto the process server from Eclipse. Processes may be triggered in a variety of ways. This includes identity events such as a request approval, removal of access, audit events, etc. These processes can interact with the underlying identity services, provisioning connectors, and other services that may exist within the enterprise. For example, a CRM system may publish data to a pre-defined address. The OpenIAM process engine can be configured to listen to that address and take action based on the s coming through. The process engine has been pre-configured to the work with the ESB. OpenIAM provides a number of process templates that address common use cases and allow the process designer to rapidly adopt this process to meet a customer's unique needs [11]. Scripting: Every customer is different and a certain amount of business logic needs to be customized to meet an organization's unique needs. To simplify this task, OpenIAM provides integration for a scripting language. By default, the scripting technology is Groovy Script - a java-like scripting language that integrates well into the OpenIAM framework as well other technologies found within the enterprise. Using the scripting tools, its possible to rapidly customize rules and other tasks for a customer's needs with a simple text editor and not have to venture down the path of having to set up complex development environments and packaging tools [12]. B. Audit and Compliance The audit and compliance solution consists of the following three components. 1. Event Collectors: Data collectors are responsible for capturing audit events based on the collector s configuration. These collectors capture events and publish them to the ESB. On the ESB, these events may be further manipulated using the rules or process engine [9]. 2. Event Receiver: 138

4 Data published to the ESB by a Data Collector is received by an Event Receiver that will log the event to a relational database [9]. 3. Reporting: The reporting engine provides a sophisticated set of tools to create reports and graphs. These reports may be delivered in real time, published to user-based access control rights, scheduled for delivery or rolled up into a dashboard. The diagram below provides a high level conceptual architecture of the Identity Management system and how it can fit into the enterprise. The following section describes how the components of the architecture interact with each other. V. OVERCOMING CHALLENGES IN IM SYSTEM Cameron s Seven Laws of identity are a good starting point for building our analysis criteria. The laws discuss common issues regarding today s IM and has spurred some good exchanges of ideas between Cameron Law 1: User Control and Consent The system must put users in control of what digital identities are used and released, protect users against deception, and verify the identity of any party who asks for user information. This law is essential for today s IM. In the introduction, we gave our definition of user control and consent; users must know what they consent to and be able to view what they had consented. Law 2: Minimal Disclosure. Since security breach can happen, the IM system should limit the disclosure of identity information for a constraint use. The domain centric IM research strongly supports this view. For example, the use of anonymous access is an attempt to prevent the correlation of IDs this law becomes less relevant if users are in control of their identity data. However, anonymity can be also useful in some cases. Law 3: Justifiable Parties. An IM system must only disclose identity information to parties having a necessary and justifiable place in a given identity relationship. Cameron s position is vague on this law. He does not want to get involved in the fabric of trust. Instead, he simply suggests that users should determine whom they can trust, and the IM system should provide the necessary information for the users to make these decisions (e.g., Info Card alerts users and gives the RP information when users access an RP site for the first time). We consider this law as allowing users to decide whom they should trust. Law 4: Directed Identity. An IM system must support both omni-directional (public) identity to facilitate the discovery and unidirectional (private) identity to prevent unnecessary release of correlation identity information. In the real world, people need to know with whom they are dealing with, which should not be different on the Internet. Since RPs has different levels of security, supporting multiple IDs is essentials in a modern IM system, which is the same for the identity discovery. Law 5: Pluralism of Operators and Technologies The IM system should be able to work with multiple IdPs. Obviously, for scalability, the IM framework must continue to support multiple IdPs, but it does not mean that a user must have more than one IdP. This paper has shown that the IM framework design simpler and provides a stronger security. Law 6: Human Integration The IM system must define the human user to be a component of the distributed system integrated through unambiguous human/machine communication mechanisms. User centric IM and, in particular, PIM strongly support this view. User participation is central to the PIM framework design, and this design principle is reflected in the user control and consent of an IM system. Law 7: Consistent Experience across Contexts The IM system must provide users with a simple and consistent experience while enabling separation of contexts through multiple operators and technologies. By definition, SSO provides consistent user experience across multiple contexts. Users authenticate to an IdP and are able to access resources on different service providers [6]. VI. IMPLEMENTAIONS USER CENTRIC ACCESS CONTROL The traditional model of application-centric access control, where each application keeps track of its collection of users and manages them, is not feasible in cloud based architectures. This is more so, because the user space maybe shared across applications that can lead to data replication, making mapping of users and their privileges a herculean task. Also, it requires the user to remember multiple accounts/passwords and maintain them. Cloud requires a user centric access control where every user request to any service provider is bundled with the user identity and entitlement information. User identity will have identifiers or attributes that identity and define the user. The identity is tied to a domain, but is portable. User centric approach leaves the user with the ultimate control of their digital identities. User centric approach also implies that the system maintains a context of information for every user, in order to find how best to react to in a given situation to a given user request. It should support pseudonyms and multiple and discrete identities to protect user privacy. This can be achieved easily by using one of the open standards like OpenID or SAML [10]. A. Scalability: Cloud requires the ability to scale to hundreds of millions of transactions for millions of identities and thousands of connections with short/rapid deployment cycles [5]. B. Interoperability: The mass expects the cloud to provide a IDM solution that can interoperate with all existing IT systems and existing solutions as such or with minimum changes. Seamless interoperation with different kinds of authentication mechanism such as the Microsoft Windows authentication, SSO, LDAP, SAML, OPENID and OAUTH, Open Social, FaceBookConnect, etc., is what is expected of cloud. The 139

5 syntactical barriers have to be bridged. It requires an authentication layer of abstraction to which any model of authentication can be plugged in and off dynamically [8]. C. Compliance: Greater harmonization of relevant legal and regulatory frameworks to be better suited to help provide for a high level of privacy, security and trust in cloud computing environments [1]. D. Accountability: Improvement of rules enabling cloud users (especially consumers) to exercise their rights as well as improvement of models of Service Level Agreements (SLAs) as the principle vehicle to provide accountability in meeting security, privacy and trust obligations [4]. 5. Transparency: Improving to way in which levels of security, privacy or trust afforded to cloud customers and end-users can be discerned, measured and managed, including research into security best practices, automated means for citizens to exercise rights and establishment of incident response guidelines [5]. VII. CONCLUSION Cloud computing with various applications being performed has several logins are used widely in enterprise hence, By implementing Identity Management established unique login credentials for all its users and gave IT the ability to manage users in one central location. IM provide with productivity enhancing tools for all users. Using a secure user name and password user access their One Login Portal where all web applications are just one click away. Inturn, IT can efficiently manage access to the organisation portfolio of cloud application. The following features influenced the Organisation decision to use one login 1.Authentication 2.Password management 3.Security Policies VIII. FUTURE WORK Our future works leads to process of implanting the federated cum personnel identity management leading to steps as follows 1. Delivers integrated security management solution 2. Simplifies administration through a unified Identity Management solution 3. Provides rapid deployment of consistently secure applications based on a single security model in the Cloud 4.Improves governance and simplifies compliance management 5. Delivers common security management best practices and industry leadership. ACKNOWLEDGMENT My hearty thanks to my guru Dr. Paul Rodrigues. My heartfelt thanks to my family for their endless support and our sincere thanks to University for their encouragements and last but not least my friends who always with me at all times. REFERENCES [1] Amazon Web Services, Overview of Security Processes, August As of November 2010: epaper.pdf. [2] Armbrust, Michael et al., Above the Clouds: A Berkeley View of Cloud Computing, University of California at Berkeley, Technical Report No. UCB/EECS , 10 February As of 25 November 2010: Pubs/ TechRpts/2009/EECS pdf. [3] Article 29 Data Protection Working Party & Working Party on Police and Justice, The Future of Privacy: Joint contribution to the Consultation of the European Commission on the legal framework for the fundamental right to protection of personal data, WP168, As of 25 November wp168_en.pdf. [4] Amazon, resources, Google App Engine articles, The Open Group, The Open Group Architecture Framework (TOGAF), Definition of the term Architectural Principle, arch/chap29.html. [5] Armbrust, Michael et al., Above the Clouds: A Berkeley View of Cloud Computing, University of California at Berkeley, Technical Report No. UCB/EECS , 10 February As of 25 November 2010: ttp:// Pubs/TechRpts/2009/CS pdf. [6] 7 Laws of Identity The Case for Privacy-Embedded Laws Of Identity in the Digital Age. [7] Sun Microsystems, Inc. Sun ONE Identity Management. tity_mgnt.pdf (26 Jan 2003). [8] Identity Management Strategy Overview Post Sun Acquisition Update Cullen Landrum. [9] Identity Management in SharePoint 2010 Rick Taylor, Senior Technical Architect, Proficient. [10] Birman, Ken, Gregory Chockler & Robbert van Renesse, Toward a Cloud Computing Research Agenda, ACM SIGACT News, 2009/40(2). [11] Securing the Cloud through Comprehensive Identity Management Solution Millie Mak Senior IT Specialist. [12] SETLabs Briefings VOL 7, NO 7, 2009, Cloud Computing Identity Management, By Anu Gopalakrishnan. AUTHOR S PROFILE Karunanithi. D M.Tech in Computer Science and published papers in 10 International and 2 National Conferences. I had been designated as a reviewer of the papers in International Conference. Won second prize in Project Competition Techie Track conducted by Infosys, Chennai.Having Membership in ACM Professional Chapter V. P. Shiyamala Devi Msc, M.C.A., M.Phil., Ph.D (Pursuing) had published papers in International Conference. Sambath. M.E had published four papers in International Conference and Journals. 140