5.2.1 Identity and Access Management Controls
From the point of view of users, leveraging resources to the cloud implies a loss of control over them.
The trust boundary (the point where the level of trust of programs and data changes) was traditionally limited to user premises. Establishing personal cloudlets means that the trust boundary will probably move beyond the control of the users. When it comes to the matter of private or personal information this can become a serious inhibitor for cloudlet adoption.
In order to strengthen risk assurance, the OPENi Cloudlet platform must enable their users to manage access control over their personal cloudets. This means that higher-level software controls have to be implemented. These controls manifest as:
Digital identities: A set of data that uniquely describes a person or a thing (sometimes referred to as subject or entity) and contains information about the subject's relationships to other entities. In most theoretical and all practical models of digital identity, a given identity object consists of a finite set of properties. Despite the fact that there are many authentication systems and digital identifiers that try to address these problems, there is still a need for a unified and verified identification system in cyberspace. There are many different schemes and formats for digital identifiers. The most widely used is Uniform Resource Identifier (URI) and its internationalized counterpart Internationalized Resource Identifier (IRI). OpenID and Light-Weight Identity (LID) are two web authentication protocols that use standard HTTP URIs (often called URLs), for example.
Authentication: An entity provides evidence that it holds a specific digital identity such as an identifier and the corresponding credentials. In other words, it consists of verifying the identity of a user or system (e.g. LDAP). The U.S. Government's National Information Assurance Glossary defines strong authentication as layered authentication approach relying on two or more authenticators to establish the identity of an originator or receiver of information. Authenticators are commonly based on at least one of the following four factors:
o Something you know: password, PIN number.
o Something you have: smart card, security token.
o Something you are: fingerprint, retina, voice.
o Where you are: inside or outside a company trust boundary, firewall, etc.
Authorization: A particular entity is authorized to perform a given set of activities, typically inherited from authentication when logging on to an application or service. Authorization consists on determining the privileges a user or system is entitled to. There are many ways to grant access privileges to users (claim-based access control, role-based access control, etc).
The typical permissions established on a system are:
o Read: Access file contents and list directory contents.
o Write: Create, edit, delete and rename files and directories.
o Execute: Run a program. In Unix systems, the 'execute' permission doubles as a 'traverse directory' permission when granted for a directory.
Delegation: If a user temporarily hand over his authorizations to another user then this process is called delegation. At authentication/identity level it consists in some sort of impersonation. It requires the delegated account password or explicit authorizations granted
by the system administrator. At authorization/access control level, the most common way of ensuring computer security is using access control mechanisms provided by operating systems such as UNIX, Linux, Windows, Mac OS, etc (e.g. “sudo” in Linux). Role-based access control implies risk of “underdelegation”, i.e. the delegator does not delegate all the necessary permissions to perform a delegated job.
Auditing: Accountability or auditing uses such system components as audit trails, records and logs to associate a subject with its actions. In information or communications security, information audit means a chronological record of system activities to enable the reconstruction and examination of the sequence of events and/or changes in an event.
Subjects and objects should both be considered as software entities. Audit trails and logs are important for detecting security violations and recreating security incidents. In the context of cloud-based services, auditing imply a detailed user activity monitoring to detect and prevent attacks against confidentiality and integrity.
Accounting: Accounting refers to the tracking of network resource consumption by users for the purpose of capacity and trend analysis, cost allocation, billing, etc.
AAA: Refers to the combination of authentication, authorization and accounting to deliver a security architecture over distributed systems.
Access Control: Access control includes authorization, authentication, access approval and audit. It considers both subjects and objects as software entities. Access control models are:
o Attribute-based access control (ABAC): A policy specifies which claims need to be satisfied in order to grant access to an object. For instance the claim could be "user must be older than 18 years old". Users can be anonymous as authentication and identification are not strictly required. Although, means for anonymously proving claims are required, e.g. using anonymous credentials or XACML (extensible access control markup language).
o Discretionary access control (DAC): The object owner is who decides who is allowed to access the object and what privileges do they have. File and data ownership, access rights and permissions are concepts inherent to DAC.
o Mandatory access control (MAC): Consists on allowing access to a resource if and only if rules exist allowing a given user to access the resource. MAC is non-discretionary. Such rules are difficult to manage, but their use is usually justified when used to protect highly sensitive information. Some examples are:
Label-based Access Control or Rule-based Access Control: access is granted by matching an object's sensitivity label a subject's sensitivity label
Lattice-based Access Control (LBAC): A lattice model is a mathematical structure that defines greatest lower-bound and least upper-bound values for a pair of elements, such as a subject and an object. Involves multiple objects and subjects
o Role-based access control (RBAC): Access policies are determined by the system (outside of the user's control), not by the owner. RBAC is non-discretionary. A role in RBAC can be viewed as a set of permissions. There are usually three steps: Role assignment (subject selects a role), role authorization (verify that subject is authorized to use such role) and action authorization (action is authorized for the presented subject's role).
Identity Federation: A federation is an association of organizations that come together to exchange information about their users and resources to enable collaborations and transactions. A federated identity is the result of linking all the information stored across multiple identity management systems into one electronic identity and set of attributes [Mad05]. Identity federation is the best practice for dealing with loosely coupled trust relationships with third parties. Identity federation is what enables interactions of systems and applications separated by an organization trust boundary. In turn, identity federation is generally enabled by Single Sign-On.
Single Sign-On (SSO): A user signing in a system using Single Sign-On access control property gains access to a set of multiple related systems without being prompted to log in again at each of them. A user's single authentication ticket, or token, is trusted across multiple systems and organizations. Single Sign-On is a subset of federated identity
management, as it relates only to authentication and is understood on the level of technical interoperability. Single Sign-On allow applications to externalize authentication features, e.g.
Authentication-as-a-Service or Identity-as-a-Service.
One of the main challenges of access management over clouds is the lack of central governance and identity information architecture. This distributed environment complicates orchestrated interactions over sensitive data. By implementing Identity and Access Management the OPENi Cloudlet platform solves access for distributed and changing user populations with persistence, consistence and efficiency.
In order to ease integration with many different Cloud-based services and the API framework, the Cloudlet platform should support and implement well-known Identity and Access Management standards (e.g. SAML) and practices such as federation.
A proper implementation of Identities and Access Management controls is also one important mean to comply with many regulations (described in Legal Issues section). For example, in order to meet compliance requirements many organizations apply practices and methodologies described in industrial frameworks like ISO 27002 and ITIL. Concerning access management, requirements include
“segregation of duties” and assignment of limited privileges for staff members to perform such duties.
5.2.2 Towards an Identity and Access Management Architecture and Practice for the Cloudlet Platform
In the last sections it has been stated that Identity and Access Management is the most convenient way to enhance privacy and access control over the Cloudlet platform. Identity an Access management consists on a collection of standard processes, best practices and technology components. Hence, is comprehensible that Identity and Access Management affects many aspects of the Cloudlet platform inner architecture.
At the core of the Cloudlet platform architecture there should be a directory service acting as a repository for identities, credentials and user attributes. The directory interacts with components in charge of providing authentication, user management, provisioning and federation services supporting standard practices and processes within the Cloudlet platform. In UNIX based systems this directory could be provided via LAPD while in Windows based systems the most common technology is Active Directory.
Many different layers and components are involved to deliver the following functional processes over Cloudlet platform architecture:
Figure 7: Example of Identity and Access Management functional architecture.
[Mat09]
Where:
User Management: governance of identity life cycles
Authentication Management: determination that an identity is what it claims to be
Authorization Management: permission assignation to identities
Access Management: making use of permission to manage access to IT resources
Data Management and Provisioning: propagation of identity and data for authorization
Monitoring and Auditing: reporting compliance of users regarding access to IT resources
Identities are a special kind of data that model specific entities entitled to access determined resources over the OPENi Cloudlet platform. In this case, the lifecycle must be adapted to meet the special requirements of identities. The following operational activities are directly linked to the identity lifecycle shown below:
Figure 8: Identity lifecycle.
[Mat09]
In turn, they are supported by the functional processes described before.
Provisioning and Deprovisioning: Provisioning refer to the creation and activation of identities. In turn, deprovisioning refer to the destruction of identity information as well. This last concept is important in order to prevent unauthorized access to Cloudlet resources by
“ghost” users.
Credential and Attribute Management: Attributes and credentials can be seen as another kind of data. Hence, they have their own lifecycles which involve phases of creation, issue, management and revocation.
Entitlement Management: They are also referred as authorization policies. They consist of provisioning and deprovisioning of privileges.
Compliance Management: Users' rights and privileges have to be monitorized in order to avoid unauthorized access to resources.
Identity Federation Management: Federation consists of managing trust relationship with external entities.
Centralization of Authentication and Authorization: It promotes a loosely coupled architecture where applications are agnostic to authentication and privacy policies.
There are three necessary steps that should be followed in order to embed successfully identities in the OPENi Cloudlet platform architecture.
1. Establishing an authoritative source for the identity 2. Identifying the necessary user profile attributes
3. Planning and implementing an Identity Provider that supporting federation via Single Sign-On Perhaps, the most important aspect in the context of OPENi is the Identity Federation Management feature, since data will have to be shared and processed by many different service providers. Single Sign-On will help to enhance user experience: users will not be required to sign in multiple times, nor will they have to remember cloud-service-specific user authentication information. The definition, description, and management of mandatory, non-mandatory, and key attributes are necessary steps to prepare the Cloudlet platform for federation. In any case, it’s strongly recommended to use widespread protocols, e.g. SAML 2.0 (de facto industry standard), WS Federation, Liberty Alliance.