Understanding Customer Identity and Access Management

Also Read : Enterprise Models for Identity Management (Part 2) of this article

While working in security and enterprise design space, I learned that quite a few professionals disagree on when it comes to Identity & Access Management (IAM).One thing most would agree on is that CIAM means many things to many people, and has been shaped more by vendor product boundaries over the years than by overarching architectures, processes, and governance. The basic term “Identity Management” (IdM) can be described very generally as an “administrative area that deals with identifying individuals in a system and controlling access to resources by placing restrictions on them” (source: Wikipedia).

Well, turns out for most people IAM is pretty much the same as IdM – essentially an implementation of tools and processes that deal – at a basic level – with a mix of stuff:

• managing user identity meta-data
• managing resources information (systems)
• offer authentication and federation with some sort of Single-Sign-On (SSO)
• Provisioning, for example setting up user accounts for individuals, or configuring a SAML proxy; provisioning often comes with some workflow automation support that also deals with changes and de-provisioning etc.

If you want to understand emerging Identity and Access Management (IAM) architectures, it’s best to start by forgetting what you know. The directory services we use today (most often LDAP and Active Directory) were designed in the clients-server age, and their implementations generally presuppose a closed system. Third-party cloud services, and to a lesser extent mobile computing, have forced a fresh approach that embraces decentralization. We liken the change from in-house directory service to Cloud IAM as that of moving from an Earth centric view of the universe to a Sun centric view.

What's trending in world of Customer IAM ?

Right now, behind the scenes, new approaches to identity and access management are being deployed — often seamlessly — into cloud services we already use. Classic enterprise IAM is largely about provisioning users and resources into a common directory, such as Active Directory or RACF, where the IAM tool enforces access policy. The cloud changes this model to a chain of responsibility, so a single IAM instance cannot completely mediate access policy. A cloud IAM instance has a shared responsibility, for example, for assertion and/or validation of identity. Carving up this set of shared access policy responsibilities is a game changer for the enterprise. The risk and complexity of mapping identity to public or semi-public infrastructure are reduced, while retaining sufficient flexibility to take full advantage of multiple cloud service and deployment models.

Why your organization needs Customer Identity and Access Management (CIAM or IAM) ?

As you scale your enterprise and decide to service you data through enterprise API, it become fairly vital to open or service Identity as Service (IDaas) through a gateway for your enterprise.

Firstly, in today’s interconnected world of devices, incl. Internet of Things (IoT) and bring your own (mobile) device (BYOD), IAM needs to support both human and machine users. Furthermore, IAM needs to go beyond provisioning (of user accounts etc.) and also focus on the often-neglected topic of restricting information flows between machines and/or users based on access policy.

The diagram above illustrates the change in architecture and deployment for identity, with the first step cloning directory services, moving to outsourced Identity as a Service (IDaaS) that extend in-house capabilities to the cloud: Cloud computing services turn traditional identity management on its ear.

The shift comes in four main parts:

• IT no longer owns the servers and applications the organization relies upon.
• Cloud provider capabilities are not fully compatible with existing internal systems.
• Network centric security model, with clearly defined concepts of ‘insider’ and ‘outsider’, are gone.
• The ways users consume cloud services are radically different when you consider mobile devices and mobile apps.

An employee may consume corporate cloud services without ever touching in-house IT systems, and mix personal and professional services. Just about every enterprise leverages one or more Software as a Service (SaaS) providers, and many are taking their first steps with Platform and Infrastructure as a Service (PaaS and IaaS, respectively) as well — each with its own approaches to Identity and Access Management.

Extending traditional corporate identity services outside the corporate environment is non-trivial — it requires integration of existing IAM systems with cloud service providers. Most companies rely on dozens of cloud service providers, each with a different set of identity and authorization capabilities, as well as different programmatic and web interfaces. The time, effort, and cost to develop and maintain links with each service provider can be overwhelming.

Dealing with Securities and Policies

Another complicating factor is that security policy requirements are getting increasingly complex, lets says policies mandated by HIPAA. And this could mean that an access decision needs to be contextually figured out each time some user (human or machine) accesses a resource based on many, dynamically changing factors (e.g. role, task, geolocation, time of day etc.). It is important to distinguish statically administered user attributes such as roles from such dynamically changing factors.

Many IAM vendors today use wide jargons of confusing and overlapping solutions that are often useful, but mostly misnamed as “dynamic role-based access control”, “ adaptive authentication” .Many advanced access control approaches have been devised over the last 10-15 years to support such complexities, such as attribute-based access control (ABAC) – where (in simplistic terms) access is determined based on rules and attributes about requestors, resources, and context; risk-adaptive access control, where access changes based on calculated risk; proximity-based access control, business process based access control, history-based access control, model-driven security  etc.

Key Issues with Identity Services

Additional capabilities of various services include multi-factor authentication, mobile user integration, and support for multiple user personas. These features help tie traditional identity management into cloud services. But as vendors attempt to solve these issues, cloud IAM creates new problems that don’t get as much attention.

• Audit: In-house systems can be linked with log management and SIEM systems to produce compliance reports and provide monitoring and detection of security events. Audit logs from cloud service providers remain problematic — the multi-tenant model prevents most providers from providing full logs because they could disclose data on other customers
• APIs: While IAM vendors offer connectors to the most common cloud services, they are unlikely to provide all the connectors you need. And cloud providers change APIs on a regular basis, sometimes breaking their customers applications. You will likely need to either provide your own integration, leverage tools from IAM service providers for building custom connections, or contract your IAM vendor to build these for you. This raises the additional challenge of on-boarding third-party developers and giving them appropriate access rights.
• Authorization Mapping: There are many possible ways to specify authorization rules, such as by role vs. by attribute. Existing access rules are likely to need rewriting for a cloud service provider, after all the objects (such as URLs and data) you are granting access to are provided by the cloud provider.
• Privileged User Management: This has been a problem for a long time, and the cloud adds a new wrinkle. Historically privileged users were all employees, and if things went pear-shaped you could handle it as an HR event. In the cloud that breaks down.
• App Identity: Once you have the user logged in you might still need to verify the application they are using — or perhaps there is no user at all, just middleware. But where did the request come from? The sad truth is that as long as you know how to call the service, many applications today do not verify the client at all. Like the previous point, this has been an IT problem for a long time.
• Identity Store Location: If companies are moving their applications and data to cloud services, will they also move existing identity stores? Some firms view this as a logical evolution, while others have security and governance requirements that require identity and authorization data be maintained in-house. As the concepts of ‘inside’ vs. ‘outside’ continue to erode, and the differentiation between ‘enterprise’ and ‘cloud’ applications blur, both the risks and benefits of moving identity stores will be at the center of debate in the coming years. 
•  Privacy: Users, user attributes, and other information are often pushed outside your corporate network and into one or more cloud data repositories. The security and privacy controls for these external repositories are not fully under your control, so you need to explore what data your vendor copies, what they use ‘in-place’, and determine both IAM vendor and cloud service provider security controls on copies that reside in the cloud.
• Latency: Propagating rule changes from internal IAM to cloud IAM can take some time. For example, if an employee is terminated or has their access rights reduced, there may be a lag between the internal change and when the cloud service enforces the change. Latency is a subject to discuss with both your IAM provider and cloud service provider.

Things to ponder upon

Getting IAM done correctly and for real requires that people are involved who deeply understand IAM and capabilities like the support for humans and machines, support for advanced access controls, support for policy-based monitoring/logging, and support for both access federation and authentication federation.

The most important aspects of IAM in any organization is not the technology but rather a strong need of clear and scalable architecture, good IAM process and strong IAM governance model. Avoid decentralized management (here governance comes in scene) and centralize one truth of data ranging from identities, assets, policies, logs, and workflow (some synchronization made by needed with legacy systems and clearly strong architecture, processes, governance in plan

Article will continued (covering other aspects of IAM) in next post