Identity is the most fundamental tenet of establishing digital trust. As a producer of digital assets, you have to know who is interested in using your assets. A passenger has to present a passport to an officer who verifies their identity before letting them board a plane. Similarly, in the digital world, a consumer of your digital assets or services has to provide digital identities such as a username and password, which the producer of the service has to verify before letting the consumer access the digital asset.

In the era of legacy mainframe systems, the burden of managing identity was low given the closed nature of such systems. As mainframes evolved into open distributed systems communicating over the Internet, identity management across internal systems and corporate boundaries became necessary. Identity stores such as LDAP[1] servers became a central system of record for identities with a variety of standards such as Kerberos, SAML and OAuth enabling the sharing of identity information.

With corporations rapidly adopting public cloud services with their own set of identity requirements and users moving to mobile devices, handling a large variety of digital identities is now a critical issue for companies.

Layered on top of the efficient handling of identities is building mechanisms that prevent identity theft[2] – an issue that continues to plague our society with profound political, financial and social impacts.

Multifactor authentication that requires additional ‘factors’ (e.g., biometrics or SMS validation) beyond a simple username and password is now becoming a norm for most organisations.[3] Email systems, such as Gmail from Google and many online bank applications, now provide such multifactor capabilities.

So, what are the challenges for large corporations?

• Establishing identity (authentication): In a highly distributed ecosystem of IoT, cloud, mobile, enterprise systems and humans, each consumer of a service, human or machine, has to let the service know who is trying to invoke it. With artificial intelligence (AI) driven devices, such as Amazon Echo, iPhone Siri, autonomous drones and vehicles replacing human functions, the number of non-human services interacting with each other will inevitability surpass human-to-device interaction. These services have to consume digital identity tokens and then make a decision on whether to allow the consumer, human or non-human, to use it. Once the service has properly interpreted the identity provided by a consumer, it then has to go to a central identity store, most likely an LDAP server, and check if the consumer is on the list of known users. In a rapidly scaling digital API economy, a service consumer may quickly face the challenge that a producer service may only know how to interpret a single type of identity, such as OAuth.[4] So it then becomes the responsibility of the consumer to provide the token in the correct format in order to invoke the service. This is, of course, neither user-friendly nor a policy that can be kept up to cover a global market.
  
  
• Establishing access rights (authorisation): Who gets to see or use what is a simple exercise for a single application. However, opening up hundreds or thousands of applications is a different story. Once a consumer’s identity is validated by checking against an identity store, the next step is to decide whether or not the consumer should be given access to the requested service. Such digital access policies have to be established based on the value and sensitivity of the digital assets and intended actions requested by the consumer. Managing authorisation involves understanding the business value of the digital asset, who should be allowed to use this asset and for what purpose, when it should be accessible and from where a user can request the digital asset.
  
  
• Context is everything: As we just described, with a well-established digital identity, the next decision of whether or not to authorise the consumer to invoke a service usually involves a significant number of attributes, such as consumer location, membership level (e.g., TOP SECRET) and, most importantly, the content sent by and returned to the consumer. Without deep business-level understanding of corporate data, user profiles and roles, service invocation patterns and the business partnership ecosystem, effective context-based access policies are impossible to implement. Once a corporate-level understanding is established, the next step is to use this knowledge to deploy an access control gateway.

All identity policies and actions should be consistently enforced across an enterprise.

They should be actively managed and audited for compliance with corporate governance directives. Letting API service producers and consumers code their own identity policies right into the business service components should be avoided at all costs since it results in an inconsistent and non-auditable infrastructure with a high-risk profile. We therefore recommend establishing a centralised and dedicated identity layer, which decouples business logic and services.

This layer can be implemented by an API security gateway, which brings authentication, authorisation and context-based access control all together in a centralised gateway model for strong governance. It provides deep, fine-grained content-based access control in a decoupled manner by sitting between the consumer and the producer services. Through centralised access control policies, API security gateways enable rapid deployment of business services. This level of agility is crucial in an era of accelerating digital transformation.