IDENTITY, ENTITLEMENT, & ACCESS MANAGEMENT
For most organizations, implementing a traditional application means implementing a server, possibly in a DMZ, and in most cases tied into a Directory Service (DS) (such as Microsoft’s Active Directory, Novell’s eDirectory or Open LDAP) for user authentication. In some cases it means implementing an application or using a web-delivered service using its own stand-alone authentication system, much to the annoyance of the users who then have to remember sets of credentials (or worse, reuse credentials from other, perhaps more trusted, domains).
DS or "Directory Service" is used through this section as an abbreviation for a generic corporate directory service, used for username and password login.
In contrast, a well implemented cloud service or application-identity should be consumed from a variety of external sources together along with the associated attributes (remembering that an identity applies not only to Users, but also Devices, Code, Organizations and Agents which all have identity and attributes). Leveraging all the multiple identities and attributes involved in a transaction enables the cloud system to make better holistic risk-based decisions (defined by the entitlement process and implemented by the authorization & access management components) about granular access to the system, processes, and data within the cloud system / application.
Code includes all forms of code, up to including applications and self-protecting data.
"Entitlement" is the process of mapping privileges (e.g., access to an application or its data) to identities and the related attributes.
This process of using multiple sources of Identity and their related attributes is critical when a cloud application is likely to be Internet-facing, and is also likely to be one of the main hurdles for organizations wanting to use “true” cloud services and instead opt to implement virtualization technologies in their own DMZ connected to their own internal DS.
This de-perimeterized approach to identity, entitlement, and access management provides a more flexible and secure approach but also can be implemented equally well inside the corporate boundary (or perimeter).
De-perimterization is a term coined by the Jericho Forum® (www.jerichoforum.org)
The following sections cover the key aspects of Identity, Entitlement, and Access Management in a cloud environment:
(I) Introduction to Identity in a cloud environment
(II) Identity architecture for the Cloud
(III) Identity Federation
(IV) Provisioning and governance of Identity and Attributes
(V) Authorization and Access Management
(VI) Architectures for interfacing to Identity and Attribute providers
(VII) Level of trust with Identity and Attributes
(VIII) Provisioning of accounts on cloud systems
(IX) Application Design for Identity
(X) Identity and Data Protection
12.1 Terminology Used in this Document
Identity : The means by which an Entity can consistently and comprehensively be identified as unique.
Identifier : The means by which an Identity can cryptographically asserted, usually using public-key technology.
Entity : Discrete types that will have Identity; these are to Users, Devices, Code, Organizations and Agents.
Entitlement : The process of mapping privileges (e.g., access to an application or its data) to Identities and the related Attributes.
Reduced Sign-on (RSO) : The use of an account and/or credential synchronization tool to minimize the number of credentials (usually username and password) a user has to remember; most of these solutions result in some form of security compromise.
Single Sign On (SSO) : The ability to pass Identity and Attributes to a cloud service, securely, using secure standards such as SAML and OAuth.
Federation : The connection of one Identity repository to another.
Persona : Identity plus the particular Attributes that provide context to the environment the Entity is operating within. A Persona may be an aggregation of an individual Identity together with an Organizational Identity and Organization Attributes (e.g. a corporate Persona, Fred Smith as CEO of ACME Corp., or a Personal Computer belonging to ACME Corp.).
Attributes : Facets of an Identity
12.2 Introduction to Identity in a Cloud Environment
An identity eco-system faces scaling problems (think of the move from a small village where everyone knows everyone else, to a large town or city). As the industry expands identity systems from single computers into global enterprises and then into cloud deployment models, the ability to identify all the entities involved in a transaction become significantly more difficult.
However, with cloud, the use of Identity for all Entities in the transaction value-chain, and the move to risk-based decisions, cannot only mitigate the risk but also potentially improve security.
The following key points need to be considered when implementing a cloud based solution that needs to use identity information:
(a) The strength with which an Identity can be asserted will feed into the risk calculation when interacting with that Identity (examples include Anonymous; self-assert; validated by a known reputable organization with a strong assertion of organizational Identity).
(b) The Attributes of a Persona, like Identity, will have a strength with which an Attribute can be asserted that feed into the risk calculation when interacting with that Persona. Assertion strength ranges from self-asserted to validated by a known reputable organization (with a strong assertion of organizational Identity).
(c) Identity and Attributes will need to be consumed from multiple sources, thus cloud solutions / architectures will need the ability to consume multiple disparate sources of Identity and Attributes.
(d) There will be instances when a transient Identity is sufficient (enough information about an Entity to deem them unique).
(e) There will be instances where pseudo-anonymity is desirable (such as voting).
12.3 Identity Architecture for the Cloud
The move from a traditional architecture of a perimeterized organization with traditional server based applications in internal computer centers affords little flexibility to an organization. The move to cloud-based architectures allows greater flexibility, whether deployed internally within the organizational boundaries (a private cloud) or external public clouds (SaaS, PaaS or IaaS).
The table on the following page shows how identity needs to vary between traditional implementation and cloud implementation, dependent on the type of cloud architecture implemented.
Whereas in a traditional “IAM” architecture, often all the components are stand-alone as part of a single server, a cloud architecture is potentially more complex taking Identity and Attributes from a number of sources and making authorization / access management decisions via a set of Entitlement Rules defined by the Entitlement Process.
IAM-Identity and Access Management
In Figure 1, Identity and Attributes are sourced from (potentially) multiple sources and feed into an authorization/access management layer that translates the entitlement rules into access.
Access Management should (depending on the business / security requirements, and the type of cloud model, IaaS, PaaS or SaaS being deployed) govern access to the;
(i) Network layer : Without meeting the entitlement rules it may not even be possible to “see” (i.e. Ping or route) to the cloud system. The entitlement rules may also direct access to particular interfaces.
(ii) System layer : The entitlement rules may define the protocols that are permitted to access and modify systems, such as terminal server vs. web.
(iii) Application layer : The entitlement rules may map Identity and/or Attributes to functionality provided by a specific application, such a being presented with a reduced set of menus or options.
(iv) Process layer : The entitlement rules can be used to define the processes (or functions) that can be run within an application. Entitlement may also define that enhanced functions (such as transferring money out of the eco-system) need additional verification (which may be obtained directly or derived in the background).
(v) Data layer : The entitlement rules may limit access to areas of the data and file structure or even individual files or fields within files (e.g., in a database). At a more advanced level, entitlement could be used to auto-redact documents, such that two users accessing identical documents would view different content (e.g., constructing a specific dynamic view of a database table).
The entitlement process starts with the customer to turn business requirements and security requirements into a set of entitlement rules. This process will define the identities and Attributes required to be able to evaluate the rules. These rules in turn drive the authorization/ access system.
12.4 Identity Federation
Conceptually speaking, federation is the interconnection of disparate Directories Services. Some organizations opt for a federation gateway, (a “Bridge” or “Federation Hub”) in order to externalize their federation implementation, where the federation and the rules by which Identity is managed within that “bridge” is governed by a set of rules, usually a legal contract, thus allowing other partners in this bridge a defined level of trust in identities not directly issued by themselves.
Technologically speaking, federation is the use of SAML to offer portability to disparate and independent security domains with some organizations extending their DS environment via a gateway product that will handle SAML assertions. Other organizations will consume native SAML assertions from an identity service.
In both these types of federation architectures, it is essential to understand the provenance of the Identity and Attributes that are being asserted.
Federation standards are used widely for SaaS deployment models for both identity federation and access control. There are no similar standards for PaaS or IaaS deployment models.
Cloud Consumers leveraging IaaS deployment models should take into consideration how they manage the lifecycle of identities (shared accounts, named accounts, privileged accounts etc.).
Enterprises that leverage the Privileged Identity Management (PIM) tools for Super User Management (SUPM) and Shared Account Password Management(SAPM) should investigate extending these tools to support cloud deployments. Enterprise or Cloud Consumers must have a well-defined policy for HPA (Highly Privileged Access).
12.5 Provisioning and Governance of Identity and Attributes
When talking about provisioning, typically we think about user provisioning, but to make rich, risk-based decisions, the cloud system / application needs Identity and Attributes from all entities involved in the transaction and potentially other Attributes from other systems / processes.
Some examples of Identity and Attributes are as follows (not an exhaustive list):
(A) User Assertions: User Identifier (The public part of a Public/Private key pair)
(B) User Name (User Name should be just another Attribute of Identity)
(C) Credential strength/trust
(D) Location Assertions; IP-Address, Geo-location, GPS, Cellular Service Location
(E) Organization Identity (Identifier – crypto) and Organization Assertions
(F) Device Identity (Identifier – crypto) and Device Assertions; Functionality Required, Functionality Offered, Sandbox capability, Secure container, Cleanliness of device
(G) Code Identity (Identifier – crypto) and Code Assertions
(H) Training record / compliance, etc.
The master source of Identity and the Attributes of an Identity (which may be from a different source) need to be identified in the design of the entitlement process.
As a rule, the cloud service or application itself should avoid being the master source for Identity (exceptions may be a cloud based HR service, or a cloud Identity-as-a-Service offering). However, during the transition to cloud services (not best practice) the cloud service / application may need to hold identities or operate a mixed-mode model.
All Attributes should be linked to an Identity, as without the associated Identifier and level of trust with that Identifier the Attributes have no provenance. While this may at first sight be counterintuitive, the strength in the entitlement process lies in defining those Attributes necessary to make the rules work the way the business requires them to and then identifying the authoritative source (or as close as possible) to provide those Attributes (with the related Entity Identifier). Examples would include:
(1) Security threat level : Organizational, Government, or Outsourced provider Identity
(2) Approvals or prior decisions made by other Entities: Entity Identity
(3) QoS or throttling policies related to a protected target resource; System Identity
12.6 The Entitlement Process
The entitlement process starts with the customer to turn business requirements and security requirements into a set of rules that will govern authorization and access to the various aspects of the cloud system. This process will then define the identities and Attributes that are required to properly evaluate the entitled rules. The entitlement process and the derived rules should not only drive the authorization and access management of a cloud system, they can also specify a degree of negotiation/entitlement at all layers of the cloud infrastructure, e.g., to allow protocols and interfaces at the network and/or system layer.The entitlement process should be embedded into any business requirements document and also the technical requirements document; it should also feature as an integral part of the cloud vendor’s provisioning / “customer on-boarding” process.
The entitlement process does not stop once the cloud service is up and running, but the entitlement rules and the subsequent rules that drive authorization and access must be the subject of regular review. The entitlement process must then be audited by the business “system-owner” against the business requirement. Any audit must include the threat and risk assessment and any regulatory requirements.
Current solutions include automated approaches to turn high-level security policies into (low-level) technical access rules, including:
(a) Model-driven security, a tool-supported process of modeling security requirements at a high level of abstraction and using other information sources available about the system (produced by other stakeholders)
(b) Clustering technical access rules into similar groups to reduce the complexity
(c) Visual attempts to make technical policies easier to understand
The entitlement process should define those Entities, Identities, and Attributes that are required to make meaningful authorization and access decisions. It should also define those Attributes that are fixed within the process, or those that have a temporal (change over time) aspect to them, and therefore either the time interval at which they must be revalidated, or the trigger within the process, will force revalidation.
Where Identity and Attributes that need to be sourced from outside the business’s control are defined in the entitlement process, the Organizational Identity (Identifier) of that provider (Entity) must be on-boarded as well, and thus (at some point in time) off-boarded.
Typically the entitlement rules are interpreted in one of three places:
1. Using a central/external Policy Enforcement point / Policy Server / Policy-as-a-Service
2. Embedded as part of the Cloud application
3. Using an Identity-aaS (IDaaS)
12.7 Authorization and Access Management
Authorization and Access Management is the process by which the entitlement rules are translated (via the Authorization layer) into Access Management rules.In most cloud based systems, the Authorization layer is likely to be a “Policy Decision Point” (PDP) or the point that evaluates and issues authorization decisions, and the Access Management layer, the “Policy Enforcement Point” (PEP), the point that enforces the PDP's decision.
The PDP and PEP will be part of an authorization eco-system that uses XACML (eXtensible Access Control Markup Language) as a declarative access control policy language implemented in XML.
A PEP could be as simple as an IF (conditional) statement in the cloud application or as advanced as an agent running on an application server or a filter in an XML-gateway that intercepts access requests, gathers necessary data (Attributes) to be able to evaluate the Entitlement Rules, and then makes and implements these decisions.
This is not to mandate the use of XACML, PDP’s, and PEP’s in a cloud environment, as the functionality could potentially be implemented in other ways (probably in a closed or proprietary eco-system).
PDP’s can be implemented outside of the cloud environment, possibly within the customer’s environment. This can potentially have a number of advantages such as interfacing to an internal DS and/or the ability to integrate logs about the decision made directly into an internal logging system.
12.8 Architectures for Interfacing to Identity and Attribute Providers
There are three basic architectures for interfacing to Identity and Attribute providers:1. A “hub-and-spoke” model where Identity and Attributes are centrally managed (coordinated) by the hub, which then interacts with the cloud service(s) or cloud application(s)
2. The free-form model where the cloud service and/or application can be configured to accept Identities and Attributes from multiple sources
3. The hybrid solution, where the components are distributed, potentially using other cloud services.
Each model has its merits, and the choice will be based on the number of factors, including:
(i) Where the customers for the service have their identity
(ii) The capability of the cloud service chosen
(iii) The capability of the enterprise to provide assertion-based Identity and Attributes.
12.8.1 Hub and Spoke Model
The “hub and spoke” approach typically allows the cloud service to interface directly with the organization for its Identity and Attribute information, ideally in the form of standards-based assertion protocols, such as OAuth & SAML.
The organization’s internal systems are responsible for keeping track of users, other entities and the Attributes. This is most like a traditional IAM system, and thus probably the easiest to transition to for cloud solutions being implemented by organizations, as most DS or LDAP systems can have a SAML capability “bolted-on”.
It is likely in this model that the entitlement process might also be handled within the organization through the use of a Policy Enforcement Point and Policy Server and communicated via XACML (though XACML isn’t that widely used for this yet). Figure 2 illustrates the hub-and-spoke approach.
One benefit of this approach is that maintaining a Policy Enforcement Point within the organization allows the integration of audit logs to be maintained within the organization and even correlated with other disparate audit trails (outside of the cloud environment, or from other cloud environments) to get the complete picture required.
Examples of this include Segregation of Duties analysis and satisfaction of regulatory requirements.
The hub-and-spoke approach is likely to be used when a high degree of control is required over all “users” with a central enrollment process. This is more likely in organizations that are subject to heavy regulation. The hub-and-spoke should also lessen the dependency on the Identity/Attribute providers, as Attributes are often stored (duplicated) within the central hub.
This is also the model used when an organization subscribes to a Bridge or “Identity Hub.”
12.8.2 Free Form Model
In the “free-form” model, the cloud service / application is responsible for maintaining the sources of Identity and Attributes. This solution is more suited for a public facing solution or a solution with a large number of disparate partners.
The free form approach has the advantage that it is easier to setup, at least for current federation protocols (such as SAML) but relies on a good implementation of the entitlement model to allow it to scale to a large amount of “users.”
One approach is to setup a point-to-point federated trust relationship (using protocols such as SAML and OAuth) between the service and Attribute/Identity providers, but this approach needs an efficient process to on-board and off-board those providers.
The free-form model provides challenges to provisioning “users”, as the environment of new entities connecting is likely to be more ad-hoc. Again, careful design of the Entitlement Process will help to alleviate this problem. Figure 3 above illustrates the point-to-point approach.
12.8.3 Hybrid Model
The Hybrid model is (by definition) a mix of both the hub & spoke and free-form model. For example, the entitlement rules may be held inside the organization and pushed to a PDP, which in itself is a cloud service, and then those decisions are delivered to multiple disparate PEP’s that are part of separate cloud services. In more large-scale deployments, there can be several federated policy servers that service many different PDP/PEP’s. The hybrid model will also be found in organizations that mix traditional and/or legacy computing with a (public and/or private) cloud environment.The hybrid model may offer an efficient use of distributed resources, but it risks becoming complex with the attendant scope for security loopholes to creep in. It also makes long-term maintenance more problematic (the reasoning behind simple rules is easy to understand when all who implemented them are long gone).
The hybrid model will also have issues of logging decisions and actions taken with the potential need to bring all logs back into a single place in a common format to allow a holistic view to be taken.
The potential complexity of the hybrid model stresses the need to be able to use visualization tools to develop, maintain, and audit the translation of the Entitlement Rules into actual access control.
12.9 Level of Trust with Identity and Attributes
Identity and Attributes come with many levels of trust, both in the various identities being used in a transaction and with the Attributes attached to those identities. Traditionally this lack of trust has led to organizations having to maintain identities for anyone who needs access to their systems, which can be (in some cases) for hundreds of thousands of people who they do not employ or directly manage.
Some organizations (Military/Aerospace, Pharmaceutical, etc.) that need to collaborate with a pre-agreed level of trust use a “Bridge” or “Federation Hub” (see section 12.4), where trusted identities also have trusted Attributes associated with them.
During the entitlement process it is essential to understand not only the Attributes required, but also the source of those Attributes, the organization that will provide them, and the strength (level of trust) with which they can be asserted.
To accept Attributes from an external organization with any defined level of trust will require an on-boarding process for that organization, and the Identity (Identifier) of the organization that will be asserting those Attributes.
As a rule, the aim should be to source Identity and Attributes from the master / authoritative source of those Attributes with all Attributes having a known Identity asserting them, as the level of trust that can be placed in the Attribute cannot exceed the level of trust that can be placed in the Identity asserting the Attribute.
Where Attributes are being uniquely generated within the cloud system itself, then a governance process must be in place to ensure that all Attributes are accurate and have appropriate lifecycle management.
12.10 Provisioning of Accounts on Cloud Systems
Where it is necessary to provision an “account” on cloud systems (typically for a user, but it could be for any Entity type) there are challenges when provisioning (and de-provisioning) these accounts, as the normal “push” model used within organizations is generally not a viable solution for a cloud implementation.
At the time of writing, there are no widely used or de-facto provisioning standards; SPML (Service Provisioning Markup Language) has not been widely adopted by the cloud providers, and SCIM (Simple Cloud Identity Management) is only starting to emerge as a potential standard.
The key to provisioning entities on a cloud system is to understand the complete lifecycle management of an account, from creation, management, and eventually de-commissioning (including deletion and/or archiving) across all the systems that both provide and consume the Identity and Attributes.
There are some key issues that need to be addressed with sources of Identity and Attributes when it comes to provisioning:
(a) The link to Human Resources (or the authoritative source of person-user information) is problematic as HR is often only the master source for staff on regular payroll.
(b) There are usually no authoritative information sources for partner information and their devices.
(c) The ability to provision other entities (particularly organizations and devices) does not exist in most organizations.
(d) Public Identity services generally only provide self-asserted Identity and only about people; it does not extend to the other Entity types.
(e) De-provisioning needs to extend to all entities, thus most organizations do not have the ability to off-board another organization when the contract finishes or revoke code from operating on systems when it is found to be faulty or obsolete.
These issues and the immaturity of provisioning standards stress the need for good planning and a holistic approach to how Identity, Attributes, accounts, and lifecycle management of all Entity-types will operate in the cloud eco-system being developed.
12.11 Identity-as-a-Service
Cloud Identity as a Service (IDaaS) is a broad term that covers the management of any part of the Identity, Entitlement, and Authorization/Access Management in the cloud service.
This encompasses service for software, platform, or infrastructure services, and for both public and private clouds. Hybrid solutions are also possible, whereby identities can still be managed internally within an organization, while other components such as authentication are externalized through a Service Oriented Architecture (SOA). This effectively creates a Platform as a Service (PaaS) layer to facilitate a cloud-based IAM solution.
12.12 Compliance & Audit
The outcome of the entitlement rules may well need to be logged together with the decisions made by the entitlement rules / authorization process for compliance or security reasons. Compliance and audit is integrally tied to Identity. Without proper Identity management, there is no way to assure regulatory compliance. Auditing also requires proper Identity management, and the use of log files is of little value without a working Identity system.
12.13 Application Design for Identity
This section applies just to application design as it applies to Identity and should be read in conjunction with Domain 10 – Application Security.
Designing cloud based systems or applications necessitates a change in mindset when it comes to Identity as Identity and Attribute information will be consumed by the cloud service or application, needing to be held for at least the duration of the transaction, and probably some facets maintained longer, but because the cloud environment may likely not be a part of an organization’s physical or logical jurisdiction, and may even be in a different legal jurisdiction, the service and application design may need to be substantially different from the design practices used in traditional client server in a DMZ owned and managed by the organization.
The design goal should be to minimize the need for Identity and Attributes. When possible, start from the principle that identification is not required while understanding the threshold where there will be a need to switch from basic “on-the-fly” account provisioning to an “identified” user account. Examples include:
(a) Unique sessions can be established using other Attributes, e.g., the IP address of the connecting device (understanding that IP addresses can be spoofed) or a unique session cookie.
(2) In many cases Attribute-based entitlement alone will be adequate with no need for user information or an actual Identity; don't assume a Persona is needed to tie to a session or even an account.
(3) When encountering a new Entity for the first time (say authenticating with a SAML assertion) then create a basic account on-the-fly. [Note that this approach requires thought about de-provisioning.]
(4) Use Attribute derivation whenever possible, (e.g. don’t ask for date of birth, instead query “if over 18” [if DoB > (today – 18 years)].
When generating any unique accounts, decide whether the system will consume an external unique Identifier from the Entity or whether the system will need to generate its own unique Identifier (such as a customer reference number).
There must be careful thought put into cloud systems that maintain user accounts. There must be careful design thought put into how the cloud user accounts will be synchronized with existing user accounts in other systems (either internal or other cloud systems), particularly around the integration with a “joiners and leavers” process, and the changes in access required when people move internally.
Designing a cloud system to scale (think of 100,000 users with an unconnected username and/or unsynchronized password) requires the need to avoid forcing a common help desk process, including manual or semi-automated synchronization scripts, password strength validation processes, password reset processes, password resets after a compromise, etc. all due to a lack of initial design thought about consuming external identities.
Avoid trying to extend an internal DS into the cloud service and/or replicating the organization’s DS over the Internet (generally very insecure) or via a back-channel (leased line or VPN) as this exposes an organization’s entire DS into an environment the organization does not control. Also be wary of the promise of RSO (reduced-sign-on) products as RSO generally works by compromising on-log-in security internally, more so when trying to extend RSO to a cloud environment.
As a rule, cloud services, and thus cloud applications, should accept the standard SSO federation formats such as SAML and OAuth (or even the less widely accepted WS-Federation).
When designing an application to consume Identity and Attributes, remember that Identity encompasses all Entities, and that the application security should, where possible, be part of a holistic approach that includes all layers; the Network layer; the System layer; the Application layer; the Process layer; and the Data layer (as detailed in section 12.3).
An application could (for example) offer two methods of connecting a full, rich connection using Web/AJAX/Java or an Citrix style “screen-scrape” connection with the type of connection permitted determined by the Entitlement Rules (defined in the Entitlement process).
12.14 Identity and Data Protection
Holding aspects of an Identity that comprises Personal Identifiable Information (PII), and particularly information classified as Sensitive Personal Information (SPI), is an issue for all organizations. Cloud services managed or located outside of the organization will need specialist advice to ensure all applicable laws and regulations are being adhered to.
When considering which laws or jurisdictions might apply, the following (non-exhaustive) list should be considered:
(a) All the countries of the data subjects
(b) The country in which the organization operates
(c) Countries in which the organization has legal entities
(d) Countries in which the organization lists on the stock exchange or issues shares
(e) The country or countries where the cloud services are physically located
(f) The relevant legislation, regulations, and also pseudo-regulation (such as PCI-DSS)
12.15 Consumerization and the Identity Challenge
Interacting with consumers and/or consumer devices brings a number of challenges and opportunities in cloud-based services and applications. The ability of the consumer and consumer devices to interface directly to an Internet-facing cloud service strips away a layer of network complexity but introduces a series of security challenges which can potentially be mitigated using Identity.
However, in the consumer space, standards for device and user Identity are fragmented and (by definition) will rarely have the same level of conformance and standardization that can be achieved in a corporate environment.
Unfortunately, most consumer devices and consumers themselves have no easy or standard way to enroll themselves or their devices into an authentication system providing strong authentication, and thus, authorization without strong Identity is difficult. Even when users have an existing strong authentication method (for example with their bank) for one account, this can almost never be reused with another account/provider. This has resulted in a situation where Identity for the consumer has already passed the limits of scalability. Over 61 percent of people use the same password whenever they can; this results in every additional registration or authentication causing the loss of potential customers.
Solving this problem with seamless access to applications will facilitate business, and clear separation between Identity and authorization will facilitate additional uses, for example allowing one individual to delegate use of their Persona linked to a specific credit card on behalf of another's transactions.
12.16 Identity Service Providers
Consuming information about Identity from an external service brings its own issues. Levels of trust in the providing organization and validation of Attributes are just two examples. Most current proposals or actual offerings for comprehensive and consistent Identity frameworks are extrapolations of single or group players’ needs by those with little or no understanding of other communities’ needs.
Nearly all open/public consumable Identity services deal only with user verification. Those that offer personal information (Attributes as well as Identity) do so using Attributes that are either self-asserted or not from authoritative sources.
Examples of sources of Identity and Attributes are as follows:
(A) National Government
1) United States, NSTIC – strategy & aspiration only
2) German “EID card,” Austrian “Citizen Card,” Estonian “ID Card,” Finland “Citizen Certificate,” Hong Kong “Smart ID Card,” Malaysian “MyCad”
(B)) Public – integration via API's
1) Facebook
2) Amazon
3) Google
4) Microsoft Passport (Windows Live ID)
5) OpenID providers (Various)
6) Twitter
(c) Bridges or “Hubs”
1) Research / Education Bridge (REBCA), serving the US higher education sector
2) Federal PKI Architecture (Federal Bridge) serving all US federal agencies.
3) CertiPath/Transglobal Secure Collaboration Program, serving the aerospace and defense industries
4) SAFE-BioPharma Association, serving the biopharmaceutical and healthcare industry
(D) Identity Service offerings
1) Check / validate my postal code and address (various)
2) Experian / Equifax
3) 3D card verification (Visa/MasterCard)
4) eBay / PayPal / X.Commerce
12.17 Recommendations
12.17.1 Federation Recommendations
a) Consumers, Implementers, and Providers should agree on the context and definition of “federation” being used.
b) Implementers should understand what trust relationship and transitive trust exist and the need for bi-direction trust relationships.
(c) Implementers should, where possible, use federation based on open standards such as SAML and OAuth.
(d) If using a “Bridge” or “Federation Hub”, then Implementers should understand the nature and relationship of the trusts that exist between different members of the club. Understand what it could mean to your entitlement rules if there is another member signed up to the cloud or federating to another bridge.
(e) Implementers should understand that public Identity providers such as Facebook, Yahoo, or Google provide a source of (low grade, typically self-asserted) Identity with no guarantees that they will not federate to other providers in the future.
(f) Implementers should deprecate examples of bad solution design solutions to get Identity from a DS linked into the access management system of a cloud solution. Such examples include in-band VPN’s and out-of-band leased-lines.
12.17.2 Provisioning and Governance Recommendations
(1) All Attributes should be sourced from as close to the authoritative / master source as possible.
(2) As a rule, the cloud service or application itself should avoid being the master source for Identity.
(3) The cloud service or application itself should only be the master source for Attributes it directly controls.
(4) All Attributes consumed should have a known level of trust.
(5) All Attributes consumed should be linked to an Identity.
(6) The Identifier of a defined Entity should sign all Attributes consumed.
(7) Each Attribute should have a lifecycle that is fit-for-purpose.
(8) Each Identity (and related Identifier) should have a lifecycle that is fit-for-purpose.
12.17.3 Entitlement Recommendations
(1) All parties in the entitlement (definition) process should be clearly identified.
(2) There should be clear designated responsibilities for entitlement rule approval and sign-off.
(3) A process to manage changes to the Entitlement Rules should be clearly defined.
(4) A frequency (or trigger) for auditing the Entitlement Rules should be clearly defined.
(5) The entitlement process should focus on producing Entitlement Rules that are simple and minimal and designed using the principle of least privilege.
(6) The entitlement process should focus on producing entitlement rules that minimize the exposure of Identity or avoid needing to consume Identity altogether.
(7) Attributes that are temporal (such as geolocation) need real-time Attribute checking through a lifetime of transaction to revalidate the entitlement rules.
(8) Entitlement rules should be triggered by a process (or attempt to initiate a process, such as money transfer out of environment). In some environments, best practice would be for the entitlement rules to disable such functions. In others, best practice would be to require additional Identity or Attributes at the point of execution to ensure the Entity is entitled to perform the process.
(9) Implementers should ensure bi-directional trust to ensure the optimal secure relationship for the transaction. The entitlement process should define this.
(10) The design of the entitlement rules should include delegation (133) of access by a secondary Entity to some, but not necessarily all, information the primary Entity can access.
(11) The design of entitlement should include the seizing of access (including legal seizure), although the designer of the entitlement rules will need to take into account the jurisdiction of the system, organization, and entities involved. Legal advice must be taken prior to implementing any seizure of access.
(12) Where practical, management interfaces, tools, or other visualization technologies should be used to help in management of Entitlement and to help ensure the interpretation meets the business and/or regulatory (e.g. SOX Segregation-of-Duties) requirements.
133. Delegation is newly supported in XACML 3.0
(13) Implementers should consider the use of “policy-as-a-service” as the policy server if there is a need for a central policy server (for example for cloud mashups).
12.17.5 Architecture Recommendations
(1) Implementers should ensure any cloud provider offers authorization management PEPs/PDP’s that can be configured with entitlement rules.(2) Implementers should ensure that all components of the Identity, Entitlement, and Authorization / Access Management (IdEA) work correctly together.
(3) Implementers should ensure that Policy Decision/Enforcement Points (PEP’s/PDP’s) use standard protocols (e.g. XACML) and avoid (or depreciate) proprietary protocols (e.g. direct web service or other middleware calls).
(4) Implementers should ensure any strong authentication service is OAuth compliant. With an OAuth-compliant solution, organizations can avoid becoming locked into one vendor’s authentication credentials.
(5) Cloud services and applications should support the capability to consume authentication from authoritative sources using SAML.
(6) Implementers should ensure services have an import and/or export function into standards such as OASIS XACML.
(7) Implementers should ensure services can interface with PEP/PDPs installed in the cloud infrastructure and with Policy Monitoring Points for incident monitoring/auditing.
(8) Implementers should ensure that logging of authorization decision and access actually granted can be logged in a common format using standard secure protocols.
12.17.6 Entitlement Recommendations
(1) Implementers should ensure that each Identity and Attribute defined in the entitlement process matches the level of trust that is needed (or is acceptable) in both the Identity/Attribute itself and also matches the source that provides it.(2) Implementers should ensure all sources of Identity / Attributes provide organizational Identity.
(3) Implementers should ensure that Attributes are validated at master / source whenever possible, or as close as possible.
(4) Implementers should ensure Attribute use correctly leads to the right conclusion. (Your context may be different to the originator of the Attribute)
(5) Implementers should ensure that the Identity / Attribute source has both the standards of data quality and a governance mechanism that meets your needs.
(6) Consumers should be aware that reputational trust can be an important source of trust. Through the entitlement definition, consumers should be aware of small value transitions, leading to an increase in transactional trust, which may be defrauded on a subsequent large transaction.
12.17.7 Provisioning Recommendations
(1) Providers should understand whether SPML or SCIM could be a viable option for provisioning.
(2) Implementers should follow the rule of least privilege when provisioning an account. In the case of entities such as computing devices, a link to organizational asset registries is desirable.
(3) Most systems and applications have a one-to-one relationship between the user and access and no concept of delegation.
(4) Implementers should ensure that provisioning and de-provisioning are not limited to user identities. Architectures must include authorization for all Entity types.
(5) Implementers should ensure provisioning and de-provisioning are done in real time.
(6) Providers should ensure the maintenance of both Identity and Attributes are critical if entitlement is to be accurate.
12.17.8 Identity Compliance & Audit Recommendations
(1) Implementers should ensure that the applicable logs from the entitlement rules / authorization process are capable of being made available.
(2) Implementers should ensure where logs need to be integrated into a wider (possibly remote) system (e.g. for wider fraud detection or segregation of duties analysis) to ensure the availability, timeliness, format, and transmission security of the logs is adequate.
(3) When logging access decisions, implementers should group the Attributes together with the entitlement logic used at the time of the decision, and the outcome should be recorded.
(4) All cloud participants should remember that Attributes with a temporal component might need to be revalidated, and hence re-logged, during the lifetime of the session.
(5) When logging PII or SPI then, whenever possible, implementers should use Attribute derivation to minimize the exposure of PII or SPI in the logs.
(6) Consumers should be aware that logs containing PII or SPI will be subject to data protection legislation.
12.17.9 Application Design Recommendations
(1) Implementers should use ITU X.805 / 3-layer definition of User, System, and Management layers to ensure segregation.
(2) Implementers should minimize the need for Identity and Attributes in an application design.
(3) When possible, design cloud systems to consume Identity and Attributes from external sources.
(4) Implementers should ensure the cloud system supports standard SSO federation formats such as SAML and OAuth.
(5) Implementers should take a holistic approach to security, using Identity and Attributes across all the layers of the system.
(6) Implementers should remember that mutual authentication is critical at all levels, and even more important in cloud environments, just as the cloud environment needs entities and other systems to authenticate who they are, so the cloud system needs to be able to authenticate in return.
12.17.10 Data Protection Recommendations
(1) Implementers should minimize the use and storage of PII or SPI. This should be done in the design phase of the entitlement process to ensure only Identities and Attributes essential to the process are used.
(2) The implementer should consider the following technologies to minimize exposure of PII or SPI:
• Encryption
• Tokenization
• Homomorphic Encryption
Refer to Domain 11 “Encryption & Key Management” for more information.
(3) Implementers should consider using best practice approaches to protecting SPI such as using a dual-key approach, one held by the subject (or keyed against their log-in), and one by the system for use with processing.
(4) Implementers should understand how administrator access to PII and SPI might be restricted or stopped.
(5) Implementers should understand how a “Subject Access Request 135” can be dealt with in the legal timeframe mandated especially when the data may be held on a cloud system not owned / managed by the organization that received the request.
135 A “Subject Access Request” is the legal right in some countries to request any PII or SPI held about yourself
(6) If there is a need to share PII or SPI, consumers should understand how the approval of the subject of the PII/SPI will be obtained.
(7) Implementers should reduce PII/SPI being stored, especially when not the authoritative source, and only reference those attributed from the authoritative source rather than store (and maintain) them.
(8) Implementers should understand the processes by which the maintenance of PII/SPI (whether Identity or Attributes) will be handled in a timely manner.
12.17.11 Identity Implementation Recommendations
(1) Implementers should start from the principle of Identity re-use rather than the unique enrollment of new users and/or devices.
(2) Consumers should understand where existing sources of Identity can provide sufficient levels of trust and be re-used.
(3) Providers should understand what Attributes about the user and devices can be asserted to a sufficient level of trust for the transaction being undertaken.
(4) When appropriate, consumers should allow low risk transactions to take place using low grade level of authentication. Only escalate the Identity required when the transaction value / risk increases.
(5) Providers should provide a critical assessment of the Identity and Attributes being required during the Entitlement Process when considering consumers and consumer devices.
(6) Providers should understand what technologies can be used with consumer devices to increase assurance levels, especially technologies than can be used in the background.
(7) Consumers should understand where the management of consumer devices will not be performed and the level of assurance this provides; this could range from no assurance to good assurance.
(8) Consumers should understand where a level of assurance and legal liability resides should an issue arise with a transaction from a consumer device.
12.18 Requirements
(1) Implementers must design the common service layers to act independently to enable the removal of application silos without sacrificing existing information security policies and procedures.
(2) All cloud participants must respect the integrity of the supply chain and respect existing IAM practices in place. Elements such as privacy, integrity, and audit ability must be respected. Identity integrity and audit must be preserved when moving data off-site and/or decoupling the pillars of the solution into web service architecture.
===// END //=====
No comments:
Post a Comment