1. Introduction
FEDERATED IDENTITY MANAGEMENT – “Identity” consists of a “set” of information based on context, allied with a definite entity (End User or System). Identity Management should include: Identity Provisioning, De-Provisioning, Identity Information Security, Identity Linking, Identity Mapping, Identity Federation, Identity Attributes Federation, Single Sign On, Authentication and Authorization.
Cloud Computing – Download Free EBooks and Whitepapers
For organizations, unauthorized access to information resources is a foremost concern. Authentication, Authorization and Auditing are the 3 popular “A”s in the context of growing demand of regulatory and compliance requirements.
Authentication (Who are you?): Authentication, solid form of identification; it is the process of validating the identity of an end user or system.
Authorization (What privileges do you have?): Privileges, the end user or system is permitted to after identity establishment. In other words, authorization is the process of implementing and enforcing policies.
Auditing (How the other “A”s are doing?): Auditing is performed to verify efficiency and compliance of IAM controls as per established access policies. It is used to detect security breaches and to specify corrective measures.
With the adoption of cloud services, the organization’s trust boundary has become dynamic. It has moved beyond the control of IT. Identity & Access Management is a critical requirement considering data sensitivity and privacy of information have become increasingly an area of concern in cloud.
Here comes Federated Identity Management as an aid. It allows identity credentials and their associated data to stay on premise or at trusted place while connecting organizations together by distributing copies of selected identity information or claims and allows proficient management, governance and movement in a Cloud world.
In information technology, federated identity has two general meanings:
1. Assembled identity, of a person’s user information, stored across various identity management systems.
2. A user’s authentication process across multiple IT systems or even organizations.
In our case, users of different cloud service providers can use a federated identification for identity establishment in cloud computing. Let’s consider Identity Management across “On Premise” and “On Cloud”.
2. On Premise Identity Management
In an archetypal organization, applications are deployed inside the organization’s outskirts and “trust boundary” is more often than not static and is monitored and controlled by the organization itself.
Standardized Access control policies and robust identity management tools help in secure and efficient connectivity for Employees, Partners or customers in day to day activities like:
· To access Employee HR Portal
· To access Intranet Portal from off-premise
· To access knowledge management resources or to contribute in KM.
· E-Transactions
The conventional approach to solve this problem has been Single Sign on (SSO), the centralization of access control information into one server. Use of LDAP, Kerberos and Active Directory is very popular.
2.1. Kerberos
Figure 1. Kerberos
Kerberos is a computer network authentication protocol, which allows nodes communicating over a non-secure network to prove their identity to one another in a secure manner [1].
1) The client authenticates itself to the Authentication Server and receives a ticket (All tickets are time-stamped).
2) It then contacts the Ticket Granting Server, and using the ticket it demonstrates its identity and asks for a service.
3) If the client is eligible for the service, then the Ticket Granting Server sends another ticket to the client.
4) The client then contacts the Service Server, and using this ticket it proves that it has been approved to receive the service.
Limitations of Kerberos Protocol:
· Single point of failure: When the Kerberos server is down, none can log in.
· Strict time requirements: The clocks of the involved hosts must be synchronized within configured limits. The tickets have a time availability period and if the host clock is not synchronized with the Kerberos server clock, the authentication will fail.
· The administration protocol is not standardized and differs between server implementations.
· Compromise of authentication infrastructure will allow an attacker to pose as any user.
2.2. Active Directory:
Figure 2. Active Directory
Active Directory uses a number of standardized protocols to provide a variety of network services, including:
· Lightweight Directory Access Protocol LDAP, the industry standard directory access protocol, compatible with many management and query applications. Active Directory supports LDAPv3 and LDAPv2.
· Optional Kerberos-based authentication
· DNS-based naming and other network information
Features:
· Central location for network administration and security
· Information security and single sign-on for user access to networked resources
· The ability to scale up or down easily
· Standardizing access to application data
· Synchronization of directory updates across servers
The Kerberos security protocol (and therefore the AD domains and forests built on it) was designed to work in a fairly secure environment, such as a corporate intranet. Within organization, directory services such as Microsoft’s Active Directory or products using the Lightweight Directory Access Protocol have allowed companies to recognize their users through a single identity.
“But” What if,
· Users and Resources are in two Different Organizations: Traditional SSO is impractical for extranets or Web services because partners may not agree on a single SSO vendor, and it is not possible / feasible to have a unified database.
· For Cloud based application: In Cloud Computing, For example, when an organization uses hosted, software as a service (SaaS) CRM solution e.g., salesforce.com or Application developed on force.com or Application deployed on Amazon EC2(Public Cloud), users are employees who access the application have enterprise identities. With external service providers, access is often managed by a separate account, which is not often associated with their organization’s identity management system and thereby represents a considerable security dilemma.
What about providing adequate security for these identities?
3. “On Cloud” Federated Identity Management
With federated identity, identity information can be ported across diverse security domains using “claims” and “assertion” from a digitally signed identity provider. Claims-based authentication (Multi-factor) is the foundation of federated identity. It is about presenting an application with the potentially “wide” range of identity information it needs, from an identity provider it trusts, regardless of whether the application is inside or outside the enterprise (Cloud in our case)[2].
With Cloud adoption, the organization’s trust boundary will become dynamic and will move beyond the control of an organization. The network, system, and application boundary of an organization will extend into the Cloud Service Provider domain. Loss of control will continue to challenge the established trusted governance and control model.
That is where we require Federated Identity, it allows companies to keep their own directories and securely exchange information from them.
Identity federation conquers the concern of “securely” managing identities, enabling the organization to share employee identity information with the Cloud Service Provider (CSP) or any other resource over the Internet. This allows the organization to boost their control over “who” has access to “what” information and resources, regardless of where those resources reside (e.g., on salesforce.com’s servers, AWS). Federated identity management improves security by controlling access on an operation base and providing a detailed audit trail.
Federated identity management enables:
· Easier access to consume cloud resources
· Superior end-user experience through SSO and just-in-time account provisioning
· Reduced cost and time to incorporate authentication and authorization
· Elimination of non-scalable proprietary SSO applications
Federation enables the communication of systems and applications separated by an organization’s trust boundary, e.g., a sales person interacting with Salesforce.com from a corporate network. Federated Identity Management leverages lessons from the U.S. federal system and application integration. Local applications or organizations maintain their own repositories which respond to queries from both local and remote applications with security assertions containing user attributes and roles. When encountering external users, the local applications query other federated repositories to authenticate and authorize these non-local users [3].
Identity Federation can be accomplished any number of ways with the use of formal internet standards such as SAML, Information Cards, and OpenID etc [4]. Identity Federation has following solution areas:
1. Single Sign On
2. Application based Web Services Security
3. Identity Lifecycle
Some of the cloud use cases that require IAM support from the CSP include:
· Employees of an organization accessing a SaaS service using identity federation (e.g., sales and support staff members accessing Salesforce.)
· To access the CSP management console to provision resources and access for users using a corporate identity
· Developers creating accounts for partner users in a RightScale
· End users accessing storage service in the within and outside a domain using access policy management features
· An application residing in a cloud service provider (e.g., Amazon EC2) accessing storage (e.g., Amazon S3) from cloud service.
4. Face-Off
|
Kerberos / Active Directory |
Claim based Authentication |
|
In AD, every authenticated user has one or more Kerberos tickets that contain identity information. |
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. |
|
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 |
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. |
|
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. |
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. |
|
AD Kerberos ticket is encrypted with either the ticket-granting server key (for a ticket-granting ticket—TGT) or the user key (for a session ticket). |
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. |
|
The scope of an AD Kerberos ticket is essentially within the enterprise. |
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. |
5. How Federated Identity Works?
Private Cloud Scenario
User inside the enterprise attempts to access a claims-aware 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.
Figure 3. Identity in Private Cloud [3]
All you need to implement this scenario is a federation service, such as
1. Active Directory Federation Services (ADFS) 2.0, IBM Tivoli Federated Identity Manager, or Ping Identity’s PingFederate
2. Claims-aware Application
1.The application needs identity information for the user.
2. The application triggers or initiates either a web service call or an HTTP redirect through the browser to ask for a token from an STS.
3. The STS responds to the request, returning the token to the application.
Public Cloud Scenario (SaaS)
Accessing a SaaS provider, in which an enterprise uses a service such as Salesforce or a hosted email provider without maintaining separate passwords at every provider.
Public Cloud Scenario (IaaS)
In Public Cloud users in the identity provider’s enterprise need to seamlessly access application deployed in the Public Cloud.
Figure 4. Federated Identity in Public Cloud
The single largest difference between this scenario and the previous one is that the Cloud Service Provider may have its own STS, and the application service trusts it alone. The federated trust agreements that the Cloud Service Provider establishes with its customers are supported by the STS, rather than the application service. This Cloud Service Provider 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 [3].
6. IDaaS
Federated identity management makes feasible the vision of “identity as a service (IDaaS)” where authentication and authorization functions are available to any application.
Figure 5. IDaaS
The identity store in the cloud is kept in sync with the corporate directory through a provider-proprietary scheme. Organization can work with the CSP to delegate authentication to the cloud identity service provider.
Pros
· Abstraction from complexity of integrating with various CSPs supporting different federation standards.
· Salesforce.com and Google support delegated authentication using SAML. If they support two different versions of SAML then Identity Broker that support both SAML standards (multiprotocol federation gateways) can hide this integration complexity from organizations adopting cloud services.
Cons
· Dependency on 3rd party for an identity management service
· Less visibility and Control into the service, implementation and architecture details.
o Availability and Authentication performance of cloud applications hinges on the identity management service provider
7. Standards
Identity Federation can be accomplished any number of ways with the use of formal internet standards as discussed below [5]:
Figure 6. Standards
7.1. SAML
· Most mature, detailed, and widely adopted specifications family for browser-based federated sign-on for cloud users
· Enables delegation (SSO)
· Multifactor authentication
· Support strong authentication and web SSO, avoid duplication of identity, and share only selected attributes to protect user privacy
· Platform neutrality. SAML abstracts the security framework away from platform architectures and particular vendor implementations.
· Business-to-business and employee-facing use cases
· Shibboleth
o Led by Internet2 to provide peer-to-peer collaboration using a federated identity infrastructure based on SAML.
o Huge adoption rate in university and research communities
· Liberty Alliance
o An organization of vendors and enterprises that is largely perceived as having formed in response to Microsoft’s Passport efforts.
o Identity federation framework (ID-FF) and identity Web services framework (ID-WSF). Their ID-FF work, which originally resulted in two versions of the ID-FF specification, has now been incorporated into SAML 2.0.
o Provides testing services for SAML 2.0 as well as their own protocols.
7.2. SPML
· Emerging
· Xml-based framework being developed by oasis for exchanging user, resource, and service provisioning information among cooperating organizations.
7.3. XACML
· XACML is an oasis-ratified, general-purpose, xml-based access control language for policy management and access decisions.
· Xml schema for a general policy language, processing environment model to manage the policies and to conclude the access decisions.
· A standard way to express authorization policies across a diverse set of cloud services and externalize authorization and enforcement from the application
7.4. OAUTH
· OAUTH is an emerging authentication standard that allows consumers to share their private resources (e.g., photos, videos, contact lists, bank accounts) stored on one csp with another csp without having to disclose the authentication information
· Supported via an API by service providers including GOOGLE, TWITTER, FACEBOOK, and PLAXO
7.5. OPENID
· OPENID is an open, decentralized standard for user authentication and access control, allowing users to log on to many services with the same digital identity—i.e., a single sign-on user experience with services supporting OPENID.
· Not adopted due to trust issues
7.6. WS-*
· Driven by a collaborative effort between Microsoft, IBM, VeriSign, RSA Security, Ping Identity and others.
· Composable suite of specifications for enabling secure Web services.
· WS-Trust, WS-Federation, and WS-Policy is an evolving set of mechanisms for layering authentication, authorization and policy across both single and multiple security domains.
8. Conclusions
This paper reviewed the concept of Federated Identity Management in the particular context of Cloud Computing. The paper has re-examined most important approaches to traditional IdM systems. The paper has also discussed the specific case of Identity management in various Cloud Deployment scenarios like public and private cloud.
As final remarks, we can notice that despite the diversity in implementation of Federated Identity, IDaaS will become the most important service in near future which abstracts away all diverse details of Identity management in Cloud Scenario.
References
[1] Kerberos (protocol), Wikipedia http://en.wikipedia.org/wiki/Kerberos_%28protocol%29
[2] Federated Identity, Wikipedia http://en.wikipedia.org/wiki/Federated_identity
[3] Sean Deuby, Ease Cloud Security Concerns with Federated Identity, http://www.windowsitpro.com/article/active-directory/Answer-Cloud-Security-Concerns-Federated-Identity-.aspx
[4] David F. Carr, What’s Federated Identity Management? http://www.eweek.com/c/a/Channel/Whats-Federated-Identity-Management/
[5] Cloud Security and Privacy, An Enterprise perspective on Risk and Compliance, O’REILLY
Related articles
- Federated Identity Management in Cloud Computing (clean-clouds.com)
