Next Generation Distributed Authorization

Many of today's security models spend a lot of time focusing upon network segmentation and authentication.  Both of these concepts are critical in building out a baseline defensive security posture.  However, there is a major area that is often overlooked, or at least simplified to a level of limited use.  That of authorization.  Working out what, a user, service, or thing, should be able to do within another service.  The permissions.  Entitlements.  The access control entries.  I don't want to give an introduction into the many, sometimes academic acronyms and ideas around authorization (see RBAC, MAC, DAC, ABAC, PDP/PEP amongst others). I want to spend a page delving into the some of the current and future requirements surrounding distributed authorization.

New Authorization Requirements

Classic authorization modelling, tends to have a centralised policy decision point (PDP)- a central location where applications, agents and other SDK's call, in order to get a decision regarding a subject/object/action combination.  The PDP contains signatures (or policies) that map the objects and actions to a bunch of users and services.

That call out process is now a bottle neck, for several reasons.  Firstly the number of systems being protected is rapidly increasing, with the era of microservices, API's and IoT devices all needing some sort of access control.  Having them all hitting a central PDP doesn't seem a good use of network bandwidth or central processing power.  Secondly, that increase in objects, also gives way to a more mesh and federated set of interactions such as the following, where microservices and IoT are more common.


Distributed Enforcement


This gives way to a more distributed enforcement requirement.  How can the protected object perform an access control evaluation without having to go back to the mother ship?  There are a few things that could help.  

Firstly,  we need to probably achieve three things.  Work out what we need to identify the calling user or service (aka authentication token), map that to what that identity can do, before finally making sure that actually happens.  The first part, is often completed using tokens - and in the distributed world a token that has been cryptographically signed by a central authority.  JSON Web Tokens (JWTs) are popular, but not the only approach.

The second part - working out what they can do - could be handled in two slightly different ways.  One, is the calling subject brings with them what they can do.  They could do this by having the cryptographically signed token, contain their access control entries.  This approach, would require the service that issues tokens, to also know what the calling user or service could do, so would need to have knowledge of the access control entries to use.  That list of entries, would also need things like governance, audit, version control and so, but that is needed irregardless of where those entries are stored.



So here, a token gets issued and the objects being protected, have a method to crytographically validate the presented token, extract the access control entries (ACE) and enforce what is being asked.

Having a token that contains the actual ACE, is not that new.  Capability Based Access Control (CBAC) follows this concept, where the token could contain the object and associated actions.  It could also contain the subject identifier, or perhaps that could be delivered as a separate token.  A similar practical implementation is described in Google's Macaroons project.

What we've achieved here, is to basically remove the access control logic from the object or service, but equally, removed the need to perform a call back to a policy mother ship.

A subtly different approach, is to pass the access control logic back down to the object - but instead of it originating within the service itself - it is still owned and managed by central authority - just distributed to the edges.



This allows for local enforcement, but central governance and management.  Modern distribution technologies like web sockets could be useful for this.  In addition, even flat file systems like JSON and YAML, could allow for "repave and replace" approach, as policy definitions change, which fits nicely into devops deployment models.  

The object itself, would still need to know a few things to make the enforcement complete - a token representing the user or service and some context to help validate the request.

Contextual Integration

Access control decisions generally require the subject, the object and any associated actions.  For example subject=Bob, could perform actions=open on object=Meeting Room.  Another dimension that is now required, especially within zero trust based approaches, is that of context.  In Bob's example, context may include time of day, day of the week, or even the project he is working on.  They could all impact the decision. 

Previous access control requests and decisions could also come into play here.  For example, say Bob was just given access to the Safe Room where the gold bullion was stored.  Maybe his request two minutes later to gain access to the Back Door is denied.  If that first request didn't occur, perhaps his request to open the Back Door is legitimate and is permitted.

The capturing of context, both during authentication time and during authorization evaluation time is now critical, as it allows the object to have a much clearer understanding of how to handle access requests.

ML - Defining Normal

I've talked a lot so far about access control logic and where that should sit.  Well, how do we know what that access control logic looks like?  I spent many a year, designing role based access control systems (wow, that was 10+ years ago), using a system known as role mining.  Big data crunching before machine learning was in vogue.  Taking groups of users and trying to understand what access control patterns existed, and trying to shoe horn the results into business and technical roles.

Today, there are loads of great SaaS based machine learning systems, that can take user activity logs (logs that describe user to application interactions) and provide views on whether their activity levels are "normal" - normal for them, normal for their peers, their business unit, location, purchasing patterns and so on.  The typical "access path analytics".  The output of that process, can be used to help define the initial baseline policies.

Enforcing access based on policies though is not enough though.  It is time consuming and open to many many avenues of circumvention.  Machine learning also has a huge role to play within the enforcement aspect too, especially as the idea of context and what is valid or not, becomes a highly complicated and ever changing question.

One of the key issues of modern authorization, is the distinction between access control logic, enforcement and the vehicles used to deliver the necessary parts to the protected services.

If at all possible, they should be as modular as possible, to allow for future proofing and the ability to design a secure system that is flexible enough to meet business requirements, scale out to millions of transactions a second and integrate thousands of services simultaneously.


















Implementing JWT Profile for OAuth2 Access Tokens

There is a new IETF draft stream called JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens.  This is a very early 0 version, that looks to describe the format of OAuth2 issued access_tokens.

Access tokens, are typically bearer tokens, but the OAuth2 spec, doesn’t really describe what format they should be.  They typically end up being two high level types – stateless and stateful.  Stateful just means “by reference”, with a long opaque random string being issued to the requestor, which resource servers can then send back into the authorization service, in order to introspect and validate.  On their own, stateful or reference tokens, don’t really provide the resource servers with any detail.

The alternative is to use a stateless token – namely a JSON Web Token (JWT).  This new spec, aims to standardise what the content and format should be.

From a ForgeRock AM perspective, this is good news.  AM has delivered JWT based tokens (web session, OIDC id_tokens and OAuth2 access_tokens) for a long time.  The format and content of the access_tokens, out of the box, generally look something like the following:

The out of the box header (using RS256 signing):

The out of the box payload:

Note there is a lot of stuff in that access_token.  Note the cnf claim (confirmation key).  This is used for proof of possession support which is of course optional, so you can easily reduce the size by not implementing that.  There are several claims, that are specific to the AM authorization service, which may not always be needed in a stateless JWT world, where perhaps the RS is performing offline validation away from the AS.

In AM 6.5.2 and above, new functionality allows for the ability to rapidly customize the content of the access_token.  You can add custom claims, remove out of the box fields and generally build token formats that suit your deployment.  We do this, by the addition of scriptable support.  Within the settings of the OAuth2 provider, note the new field for OAuth2 Access Token Modification Script.

The scripting ability, was already in place for OIDC id_tokens.  Similar concepts now apply.

The draft JWT profile spec, basically mandates iss, exp, aud, sub and client_id, with auth_time and jti as optional.  The AM token already contains those claims.  The perhaps only differing component, is that the JWT Profile spec –  section 2.1 – recommends the header typ value be set to “at+JWT” – meaning access token JWT, so the RS does not confuse the token as an id_token.  The FR AM scripting support, does not allow for changes to the typ, but the payload already contains a tokenName claim (value as access_token) to help this distinction.

If we add a couple of lines to the out of the box script, namely the following, we cut back the token content to the recommended JWT Profile:

accessToken.removeField(“cts”);
accessToken.removeField(“expires_in”);
accessToken.removeField(“realm”);
accessToken.removeField(“grant_type”);
accessToken.removeField(“nbf”);
accessToken.removeField(“authGrantId”);
accessToken.removeField(“cnf”);

The new token payload is now much more slimmed down:

The accessToken.setField(“name”, “value”) method, allows simple extension and alteration of standard claims.

For further details see the following documentation on scripted token content – https://backstage.forgerock.com/docs/am/6.5/oauth2-guide/#modifying-access-tokens-scripts

This blog post was first published @ http://www.theidentitycookbook.com/, included here with permission from the author.

Directory Services – Docker, Kubernetes: Friends or Foes?

Two weeks ago, at the ForgeRock Identity Live conference, I did a talk about ForgeRock Directory Services (DS) in the Docker/Kubernetes (K8S) world, trying to answer the question whether DS and Docker/K8S were friends or foes.

Before I dive into the question, let me say that it’s obvious that our whole industry is moving to the Cloud, and that Docker/Kubernetes are becoming the standard way to deploy software in the Cloud, in any Cloud. Therefore whether DS and K8S are ultimately friends or foes is not the right question. I believe it is unavoidable and that in the near future we will deploy and fully support Directory Services in K8S. But is it a good idea to do it today? Let’s examine why we are questioning this today, what are the benefits of using Kubernetes to deploy software, what are the constraints of deploying the current version of Directory Services (6.5) in Kubernetes, and what ForgeRock is working on to improve DS in K8S. Finally I will highlight why Directory Services is a good solution to persist data, whether it’s on premise or in the Cloud. 

Why the discussion about DS and K8S?

The main reason we are having this discussion is due to the nature of Directory Services. DS is not the usual stateless web application. Directory Services is both a stateful application and a distributed one. These are two main aspects that require special care when trying to deploy in containers. First Directory Services is a stateful application because it is the place where one can store the state for all these stateless web-applications. In our platform, we use DS to store ForgeRock Access Management data, whether it’s runtime configuration data, tokens and user identities. Second Directory Services is a distributed application because instances need to talk with each other so that the data is replicated and consistent. Because databases and distributed applications require stronger orchestration and coordination between elements of the system, they are implemented as Stateful Sets in the Kubernetes world, and make use of Persistent Volumes (PV). Therefore our Cloud Deployment Model of ForgeRock Directory Services is also implemented this way.

It’s worth noting that Persistent Volume is a Kubernetes API and there are several types of volumes and many different providers implementations. Some of the PV types are very recent and still beta versions. So, when using Kubernetes for applications that persist data, you should have a good understanding of the characteristics and the performance of the Persistent Volumes choices that are available in your environment.

Benefits of Containers and Kubernetes

Developers are making a great use of containers because it simplifies focus on what they have to build and test. Instead of spending hours figuring how to install and configure a database, and build a monitoring platform to validate their work, they can pull one or more docker images that will automate this task.

When going into production, the automation is a key aspect. Kubernetes and its family of tools, allow administrators to describe their target architectures, automate deployment, monitoring and incident response. Typically in a Kubernetes cluster, if the administrator requires at least 3 instances of an application, Kubernetes will react to the disappearance of an instance and will restart a new one immediately. Another key benefit of Kubernetes is auto-scalability. The Kubernetes deployment can react to monitoring alerts or external signals to add or remove instances of an application in order to support a greater or smaller workload. This optimises the cost of running the solution, balancing the capacity to absorb peak loads with the cost of running at normal or low usage levels.

Directory Services 6.5 constraints in K8S

But auto-scaling is not something that is suitable to all applications, and typically Directory Services, like most of the databases, does not scale automatically by adding more running instances. Because databases have state and data, and expect exclusive access to the files, adding a new replica is a costly operation. The data needs to be duplicated in order to let another instance using it. Also, adding a Directory Services instance only helps to scale read operations. A write operation on any server will need to be replicated to all other servers. So all servers will have the same write throughput and the same amount of disk I/Os. In the world of databases, the only way to scale write operations is to distribute (shard) the data to multiple servers. Such capability is not yet available in Directory Services, but it’s planned for future releases. (Note that Directory Proxy Services 6.5 already has support for sharding, but with some constraints. And the proxy is not yet part of the Cloud Deployment Model).

Another constraint of Directory Services 6.5 is how replication works. The DS replication feature was designed years ago when customers would deploy servers and would not touch them unless they were broken. Servers had stable hostnames or IP addresses and would know all of their peers. In the container world, the address of an instance is only known after the instance is started. And sometimes you want to start several instances at the same time. The current ForgeRock Cloud Deployment Model and the Directory Services docker images that we propose, work around the design limitation of replication management, by pre-configuring replication for a fixed (and small) maximum number of replicas. It’s not possible to dynamically add another replica after that. Also, the “dsreplication” utility cannot be used in Kubernetes. Luckily, monitoring replication and more importantly its latency is possible with Prometheus which is the default monitoring technology in Kubernetes.

Coming Improvements in Directory Services

For the past year, we’ve been working hard on redesigning how we manage and bootstrap replication between Directory Services instances. Our main challenge with that work has been to do it in a way that allows us to continue to replicate with previous versions. Interoperability and compatibility of replication between different versions of Directory Services has been and will remain a key value of the product, allowing customers to roll out new versions with zero downtime of the service. We’re moving towards using full CA-based certificates and mutual TLS authentication for establishing trust between replicas. Configuring a new replica will no longer require updating all servers in the topology, and replicas that are uninstalled or stopped for some time will be automatically removed from the topology (and so will be their associated change logs and meta-data). When starting a new replica, it will only need to know of one other running replica (or be told that it is the first one). These changes will make automating the deployment of new replica much simpler and remove the limit to the number of replicas. We are also improving the way we are doing backup and restore of a database backend or the whole server, allowing to directly use cloud buckets such as S3 or GCS. All of these things are planned for the next major release due in the first half of 2020. Most of these features will be used by our own ForgeRock Identity Platform as a Service offering that will go in stages of Early Access and Beta later this year.

Once we have the ability to fully automate the deployment and the upgrade of a cluster of Directory Services instances, in one or more data-centres, we will start working on horizontal scalability for Directory Services, and provide a way to scale the number of servers as the data stored grows, allowing a consistent level of write throughout. All of this fully automated to be deployed in the Cloud using Kubernetes.

Benefits of using Directory Services as a data store

Often people ask me why they should use ForgeRock Directory Services rather than a real database. First of all, Directory Services is a database. It’s a specialised database, built on a standard data model and a standard access protocol: Lightweight Directory Access Protocol aka LDAP. Several people in the past have pointed out that LDAP might have even been the first successful NoSQL database! 🙂  Furthermore, Directory Services also exposes all of the data through a REST/JSON API, yet still providing the same security and fine grained access controls mechanisms as through LDAP. But the main value of Directory Services is that you can achieve very high availability of the data (in the 5 9’s), using standard systems (whether they are bare metal systems or virtual hosts or containers), even with world wide geographic distribution. We have many customers that have deployed a single directory services distributed in 3 to 6 data centers around the globe. The LDAP data model has a flexible schema that can be extended, customised without having to rebuild the database nor even restart the servers. The data can even be exposed through versioned APIs using our REST API. Finally, the combination of flexible and extensive schema with fine-grained access controls, allow multiple applications to access the data, but with great control of which application can read or write which data. This results in a single identity and credentials for a user, but multiple sets of attributes, that can be shared by applications or restricted to a single one: a single central view of the user that is then easier and more cost effective to manage.

Conclusion

Back to the track of Kubernetes, and because of the constraints of the current Directory Services Cloud Deployment Model with version 6.5, we would recommend that you try to keep your Directory Services deployed in VMs or on bare metal. But with the next release which underpins the ForgeRock Cloud offering, we will fully support deploying Directory Services on Docker/Kubernetes. We will continue our investment in the product to be able to support Auto-Scaling (using data sharding) in subsequent releases. Building these solutions is not extremely difficult, but we need time to prove that it’s 100% reliable in all conditions, because in the end, the most wanted and appreciated feature of ForgeRock Directory Services is its reliability.

This blog post was first published @ ludopoitou.com, included here with permission.

ForgeRock Identity Live Berlin

Last week, the IdentityLive tour stopped in Berlin for the first European event of 2019 (the second one will be in London on October 8th-9th).

It was a good opportunity to meet and discuss with our European customers (or the European teams of our global customers). For me, the main topic of discussion was Kubernetes and running Directory Services in Docker/K8S. It was also something that I’ve discussed a little bit during the Nashville Identity Live, but not as much as I did in Berlin. I also did a talk on that subject at the Identity Live Cloud Workshop (the second day of the event is focusing on the technical aspects of our products and solutions). I’ve started to write another article to detail my talk. I hope to publish it here in the next few days. Meanwhile, you can find all the photos from Identity Live Berlin on my Flickr page as usual.

ForgeRock IdentityLive Berlin 2019

Note that Identity Live Berlin took place at the “Classic Remise” which is a showroom for old and sports cars. An unusual place for a conference, but a good opportunity to admire some pretty old cars and try to take a different kind of photos.

Cars from Classic Remise Berlin

ForgeRock Identity Live Nashville, TN

Two weeks ago debuted the ForgeRock Identity Live series of events. This year the USA based event moved to Nashville TN.

Untitled

This was my first visit to the city of Country Music and honky-tonks. It was fun listening to the live music everywhere, trying (and buying) boots, visiting the Country Music Hall of Fame, although we didn’t really have much time for leisure.

Untitled
Untitled

The Identity Live event itself was really good and very well attended. The engagement of our Customers and Partners was great and we’ve had a myriad of discussions, feedbacks and questions about our products, our roadmap and our progress on our move to the Cloud.

Untitled

The videos of the sessions are already available on ForgeRock website. And you can also see the photos that I took during the event.

Next is Berlin Identity Live, on June 6-7. Registration is still open! I’m looking forward to seeing you in Berlin!

How To Build An Authentication Platform

Today’s authentication requirements go way beyond hooking into a database or directory and challenging every user and service for an Id and password.  Authentication and the login experience, is the application entry point and can make or break your security posture and end user experience. 

Authentication is typically associated with identifying, to a certain degree of assurance, who or what you are interacting with.  Authorization is typically identifying and allowing what that person or thing can do.  This blog is focused on the former, but I might stray in to the latter from time to time.

There are numerous use cases that a modern enterprise needs to fulfil, if authentication services are to deliver value.  These can include:

  • Authentication for a service or API
  • Device authentication
  • Metrics, timing and analytics of flows
  • Threat intelligence integration
  • Anonymous to known authentication profiling
  • Contextual analysis
In addition to the basic functional requirements, there are several non-functional basics too.  These are going to include:
  • Simple customisation
  • Being highly available
  • Stateless and elastic
  • Simple integrations
  • API first
I’m going to take some of these key requirements and describe them in a little more detail.

Non Identity Intelligence

From a feature perspective, the new requirements consistently rely upon Intelligence:  the new buzz in the cyber security world.  Every week a new more consolidated threat intelligence tool comes to market.  Organisations up and down the land, are rapidly building out Security Operations Centres (SOC) with wily ex-military veterans creating strategies and starry eyed graduates analysing SIEM and NIDS logs.  We need data.  We have data.  What we need is information.  Actionable intelligence.  Intelligence can be rapidly integrated into any number of different security architecture components. 
Intelligence here, is basically a focus upon non-identity data signals.  Sources of malware, malicious IP addresses, app assurance ratings, breached credentials data and so on.
The vast breadth and depth of cyber threat intelligence (CTI) sources is staggering.  Free, chargeable, subscription based, cloud based, you name it, it’s available.  A common factor must be simplicity of integration – ideally via some like a REST/JSON based API that developers are familiar with.  Long tale integration must be avoided too, with the ability to swap out and have a zero barrier to exit being important.  This last point is extremely important.  You need to able to future proof your data inputs.  
Whatever you want to integrate today, will be out of date tomorrow.  

Integration

Integration is not just limited to threat intelligence sources.  This is really just a non-functional, but I want to spend some time on it.  It is quite common to find legacy (I hate this word, let’s call them “classic” or initial system) authentication products are generally difficult to integrate against and extend.  
Many systems integrators (SI’s) (and many do excellent jobs in highly challenging environments) will work tirelessly, and at some considerable cost, to add different authentication modalities, customize one time password options, integrate with difficult LDAP account lockout options, mobile-ise and more.  These “integration” steps are often described as non-BAU.  They require change control and are charged via a time and materials or scope creep premium model.  Integration costs in a modern system, really need to be minimized if not removed.  Authentication is becoming so fluid that changes including new authentication factors, data sources, UI flows and so on, should be a standard operator journey.

Roadmapping

So why is integration such an issue?  A common problem of historical authentication deployments, has often been around lack of foresight. In honesty, foresight and robust road mapping has never been a real requirement for a login system.  Login using user names and passwords and occasionally an MFA, was pretty much it.  Like it or lump.  Well, in today’s digitised ecosystems, new requirements pop up daily.  Think of the following basic scenarios, that will impact an authentication system:
  • New go to markets requiring localization
  • A new product that requires new API’s and apps
  • A merger resulting in differing regulatory compliance requirements
  • New attack patterns and vector discovery
  • Competitive innovations
  • Commodity innovations
If you looked at your authentication services library and compare that to the applications and users consuming those services, do you know their functional and non-functional requirements, business objectives and challenges for  the next 12-18 months?  Some will, so the underlying authentication service needs to a) have a road map and b) be able to accommodate new requirements and demands, in a agile and iterative fashion.
Part of this is technical and part of that is operational management.  The business owners of an authentication platform, need to have interactions with the new stakeholders to the login journey.  The login process is basically the application from an end user perspective.  It needs to uphold security, whilst improving the user experience.  Requirements gathering must be a fully integrated process not just for application development, but for identity and authentication services too.

Platform versus Product

I purposefully chose the word platform in the title as opposed to service or product.  Modern authentication is a platform.  It powers transformation, by supporting API’s, applications and services that allow organisations to create value driven software.  It becomes the wiring in the hotel, that allows all of the auxiliary products and shiny things to flourish.  
Many point authentication products exist. I am not discrediting them by any means.  Best of breed point solutions for biometry, mobile SDK integration, device operating or behaviour profiling exist and will need integrating to the underlying platform.  They are integration points.  Cogs inside a bigger machine.
The glue that drives the business value however, will be the authentication platform, capable of delivering a range of services to different applications, user communities, geographies and customers.  A single product is unlikely to be able to achieve this.
In summary, authentication has become a critical component, not only for securing user and data centric integrations, but also for helping to deliver continuous modernization of the enterprise.  
It has become a foundational component, that requires a wide breadth of coverage, coupled with agility and extensibility.

This blog post was first published @ www.infosecprofessional.com, included here with permission.

How To Build An Authentication Platform

Today's authentication requirements go way beyond hooking into a database or directory and challenging every user and service for an Id and password.  Authentication and the login experience, is the application entry point and can make or break your security posture and end user experience. 

Authentication is typically associated with identifying, to a certain degree of assurance, who or what you are interacting with.  Authorization is typically identifying and allowing what that person or thing can do.  This blog is focused on the former, but I might stray in to the latter from time to time.

There are numerous use cases that a modern enterprise needs to fulfil, if authentication services are to deliver value.  These can include:

  • Authentication for a service or API
  • Device authentication
  • Metrics, timing and analytics of flows
  • Threat intelligence integration
  • Anonymous to known authentication profiling
  • Contextual analysis
In addition to the basic functional requirements, there are several non-functional basics too.  These are going to include:

  • Simple customisation
  • Being highly available
  • Stateless and elastic
  • Simple integrations
  • API first

I'm going to take some of these key requirements and describe them in a little more detail.

Non Identity Intelligence

From a feature perspective, the new requirements consistently rely upon Intelligence:  the new buzz in the cyber security world.  Every week a new more consolidated threat intelligence tool comes to market.  Organisations up and down the land, are rapidly building out Security Operations Centres (SOC) with wily ex-military veterans creating strategies and starry eyed graduates analysing SIEM and NIDS logs.  We need data.  We have data.  What we need is information.  Actionable intelligence.  Intelligence can be rapidly integrated into any number of different security architecture components. 

Intelligence here, is basically a focus upon non-identity data signals.  Sources of malware, malicious IP addresses, app assurance ratings, breached credentials data and so on.

The vast breadth and depth of cyber threat intelligence (CTI) sources is staggering.  Free, chargeable, subscription based, cloud based, you name it, it's available.  A common factor must be simplicity of integration - ideally via some like a REST/JSON based API that developers are familiar with.  Long tale integration must be avoided too, with the ability to swap out and have a zero barrier to exit being important.  This last point is extremely important.  You need to able to future proof your data inputs.  

Whatever you want to integrate today, will be out of date tomorrow.  

Integration

Integration is not just limited to threat intelligence sources.  This is really just a non-functional, but I want to spend some time on it.  It is quite common to find legacy (I hate this word, let's call them "classic" or initial system) authentication products are generally difficult to integrate against and extend.  

Many systems integrators (SI's) (and many do excellent jobs in highly challenging environments) will work tirelessly, and at some considerable cost, to add different authentication modalities, customize one time password options, integrate with difficult LDAP account lockout options, mobile-ise and more.  These "integration" steps are often described as non-BAU.  They require change control and are charged via a time and materials or scope creep premium model.  Integration costs in a modern system, really need to be minimized if not removed.  Authentication is becoming so fluid that changes including new authentication factors, data sources, UI flows and so on, should be a standard operator journey.

Roadmapping

So why is integration such an issue?  A common problem of historical authentication deployments, has often been around lack of foresight. In honesty, foresight and robust road mapping has never been a real requirement for a login system.  Login using user names and passwords and occasionally an MFA, was pretty much it.  Like it or lump.  Well, in today's digitised ecosystems, new requirements pop up daily.  Think of the following basic scenarios, that will impact an authentication system:

  • New go to markets requiring localization
  • A new product that requires new API's and apps
  • A merger resulting in differing regulatory compliance requirements
  • New attack patterns and vector discovery
  • Competitive innovations
  • Commodity innovations
If you looked at your authentication services library and compare that to the applications and users consuming those services, do you know their functional and non-functional requirements, business objectives and challenges for  the next 12-18 months?  Some will, so the underlying authentication service needs to a) have a road map and b) be able to accommodate new requirements and demands, in a agile and iterative fashion.

Part of this is technical and part of that is operational management.  The business owners of an authentication platform, need to have interactions with the new stakeholders to the login journey.  The login process is basically the application from an end user perspective.  It needs to uphold security, whilst improving the user experience.  Requirements gathering must be a fully integrated process not just for application development, but for identity and authentication services too.


Platform versus Product

I purposefully chose the word platform in the title as opposed to service or product.  Modern authentication is a platform.  It powers transformation, by supporting API's, applications and services that allow organisations to create value driven software.  It becomes the wiring in the hotel, that allows all of the auxiliary products and shiny things to flourish.  

Many point authentication products exist. I am not discrediting them by any means.  Best of breed point solutions for biometry, mobile SDK integration, device operating or behaviour profiling exist and will need integrating to the underlying platform.  They are integration points.  Cogs inside a bigger machine.

The glue that drives the business value however, will be the authentication platform, capable of delivering a range of services to different applications, user communities, geographies and customers.  A single product is unlikely to be able to achieve this.

In summary, authentication has become a critical component, not only for securing user and data centric integrations, but also for helping to deliver continuous modernization of the enterprise.  

It has become a foundational component, that requires a wide breadth of coverage, coupled with agility and extensibility.



How To Build An Authentication Platform

Today's authentication requirements go way beyond hooking into a database or directory and challenging every user and service for an Id and password.  Authentication and the login experience, is the application entry point and can make or break your security posture and end user experience. 

Authentication is typically associated with identifying, to a certain degree of assurance, who or what you are interacting with.  Authorization is typically identifying and allowing what that person or thing can do.  This blog is focused on the former, but I might stray in to the latter from time to time.

There are numerous use cases that a modern enterprise needs to fulfil, if authentication services are to deliver value.  These can include:

  • Authentication for a service or API
  • Device authentication
  • Metrics, timing and analytics of flows
  • Threat intelligence integration
  • Anonymous to known authentication profiling
  • Contextual analysis
In addition to the basic functional requirements, there are several non-functional basics too.  These are going to include:

  • Simple customisation
  • Being highly available
  • Stateless and elastic
  • Simple integrations
  • API first

I'm going to take some of these key requirements and describe them in a little more detail.

Non Identity Intelligence

From a feature perspective, the new requirements consistently rely upon Intelligence:  the new buzz in the cyber security world.  Every week a new more consolidated threat intelligence tool comes to market.  Organisations up and down the land, are rapidly building out Security Operations Centres (SOC) with wily ex-military veterans creating strategies and starry eyed graduates analysing SIEM and NIDS logs.  We need data.  We have data.  What we need is information.  Actionable intelligence.  Intelligence can be rapidly integrated into any number of different security architecture components. 

Intelligence here, is basically a focus upon non-identity data signals.  Sources of malware, malicious IP addresses, app assurance ratings, breached credentials data and so on.

The vast breadth and depth of cyber threat intelligence (CTI) sources is staggering.  Free, chargeable, subscription based, cloud based, you name it, it's available.  A common factor must be simplicity of integration - ideally via some like a REST/JSON based API that developers are familiar with.  Long tale integration must be avoided too, with the ability to swap out and have a zero barrier to exit being important.  This last point is extremely important.  You need to able to future proof your data inputs.  

Whatever you want to integrate today, will be out of date tomorrow.  

Integration

Integration is not just limited to threat intelligence sources.  This is really just a non-functional, but I want to spend some time on it.  It is quite common to find legacy (I hate this word, let's call them "classic" or initial system) authentication products are generally difficult to integrate against and extend.  

Many systems integrators (SI's) (and many do excellent jobs in highly challenging environments) will work tirelessly, and at some considerable cost, to add different authentication modalities, customize one time password options, integrate with difficult LDAP account lockout options, mobile-ise and more.  These "integration" steps are often described as non-BAU.  They require change control and are charged via a time and materials or scope creep premium model.  Integration costs in a modern system, really need to be minimized if not removed.  Authentication is becoming so fluid that changes including new authentication factors, data sources, UI flows and so on, should be a standard operator journey.

Roadmapping

So why is integration such an issue?  A common problem of historical authentication deployments, has often been around lack of foresight. In honesty, foresight and robust road mapping has never been a real requirement for a login system.  Login using user names and passwords and occasionally an MFA, was pretty much it.  Like it or lump.  Well, in today's digitised ecosystems, new requirements pop up daily.  Think of the following basic scenarios, that will impact an authentication system:

  • New go to markets requiring localization
  • A new product that requires new API's and apps
  • A merger resulting in differing regulatory compliance requirements
  • New attack patterns and vector discovery
  • Competitive innovations
  • Commodity innovations
If you looked at your authentication services library and compare that to the applications and users consuming those services, do you know their functional and non-functional requirements, business objectives and challenges for  the next 12-18 months?  Some will, so the underlying authentication service needs to a) have a road map and b) be able to accommodate new requirements and demands, in a agile and iterative fashion.

Part of this is technical and part of that is operational management.  The business owners of an authentication platform, need to have interactions with the new stakeholders to the login journey.  The login process is basically the application from an end user perspective.  It needs to uphold security, whilst improving the user experience.  Requirements gathering must be a fully integrated process not just for application development, but for identity and authentication services too.


Platform versus Product

I purposefully chose the word platform in the title as opposed to service or product.  Modern authentication is a platform.  It powers transformation, by supporting API's, applications and services that allow organisations to create value driven software.  It becomes the wiring in the hotel, that allows all of the auxiliary products and shiny things to flourish.  

Many point authentication products exist. I am not discrediting them by any means.  Best of breed point solutions for biometry, mobile SDK integration, device operating or behaviour profiling exist and will need integrating to the underlying platform.  They are integration points.  Cogs inside a bigger machine.

The glue that drives the business value however, will be the authentication platform, capable of delivering a range of services to different applications, user communities, geographies and customers.  A single product is unlikely to be able to achieve this.

In summary, authentication has become a critical component, not only for securing user and data centric integrations, but also for helping to deliver continuous modernization of the enterprise.  

It has become a foundational component, that requires a wide breadth of coverage, coupled with agility and extensibility.



2019 Digital Identity Progress Report

Schools out for summer?  Well not quite.  Unless you're living in the east coast of Australia, it's looking decidedly bleak weather wise for most of Europe and the American east coast.  But I digress.  Is it looking bleak for your digital identity driven projects?  What's been a success, where are we heading and what should we look out for?

Where We Are Today

Passwordless - (Reports says B-)

Over the last 24 months, there have been some pretty big themes that many organisations embarking on digital identity and security related projects, have been trying to succeed at.  First up, the age old chestnut...of passwordless authentication.  The password is dead, long live the password!  We are definitely making progress though.  Many of the top public sites (Facebook, LinkedIn, Twitter et al) provide multi-factor authentication options at least.  Passwords are still required as the first step, but the end user education and familiarity with something other than a password during login, must surely be the first steps to getting ridding of them entirely.  2018 also saw the rise of WebAuthn - the W3C standards based approach for crypto based challenge response authentication.  Could this hopefully accelerate adoption to a password-free world?

API Protection - (Report says C+)

API's will eat the world?  Well, digital disruption needs speed, agility and mashups.  API's help organisations achieve those basic aims, but where are we, with respect to the protection of those API's?  API management platforms are now common in most enterprise architectures.  They help to perform API provisioning, versioning and life cycle management, but what about security?  Many use cases fall into the API security band wagon such as service to service authentication, least privilege authorization, token exchange and contextual throttling.  Most API services are now sitting comfortably behind basic authentication, but fine grained controls and basic use cases such as token revocation and rotation are still in their infancy.  Report says "we must do better".

Microservices Protection - (Report says B-)

Not all API's are microservices, but many net new additions to projects will leverage this approach.  But microservices infrastructures, bring many new security challenges as well as benefits.  Service versioning, same service load balancing, high through puts and fine grained access controls have created some new emerging security patterns.  Both the side car and inflight/proxy approach for traffic introspection and security enforcement have appeared.  Microservices by their design, normally means very high transactions per second, as well as fine grained access control - with each service performing only a single task.  Stateless OAuth2 seems to fit the bill for many projects, but the consistency around high scale token introspection and scope design seems immature.

IoT Security - (Reports says C-)

Many digital disruption projects are embracing smart device (HTTP-able) infrastructures.  Pairing those devices to real people seems a winner for many industries, from retail, insurance to finance.  But and there's always a but, the main interest for many organisations is not the device, but the data the device is either collecting or generating.  Device protection is often lacking - default credentials, hard coded keys, un-upgradable firmware, inability to use HTTPS and the inability to store access tokens are all very common.  There are costs and usability issues with increased device security and no emerging patterns are consistent.  Several regulations and security best practice documents now exist, but adoption is still low.

User Consent Management - (Report says B-)

GDPR has probably had the biggest impact, from an awareness perspective, than any other piece of regulation relating to consent.  The consumer, from a pure economic buyer perspective at least, has never been so powerful.  One click away from a competitor.  From a data perspective however, it seems the capitalist corporate machine is holding all the cards.  Marketing analytics, usage tracking, location tracking, you name it, the service provider wants that data to either improve your service, or improve their ability to market new services.  Many organisations are not stupid.  They realise that by offering basic consent management functionality (contact preferences, ability to be removed, data exportation, activity viewing) they are not only ticking the compliance check box, but can actually create a competitive advantage by giving their user community the image of being at trusted partner to do business with.  But will the end user be ever truly in control of their data?

What's Coming

The above 4 topics are not going away any time soon.  Knowledge, standards maturity and technology advances, should all allow each of those areas to bounce a grade within the next 18-24 months.  But what other concerns are on the horizon?  

Well skills immediately spring out.  Cyber security in general is known to have a basic skills shortage.  Digital Identity seems to fall in to that general trend and some of these topics are niches within a niche.  Getting the right skill set to design micro services security or consent management systems will not be trivial.

What about new threats - they are emerging every day.  Bot protection - at both registration and login time - not only helps improve the security posture of an organisation, but also helps improve user analytics, remove opportunities for false advertising and provide a clearer picture to a service's real organic user community.  How will things like ML/AI help here - and does that provide another skills challenge or management black hole?

The final topic to mention is that of usability.  Security can be simple in many respects, but usability can make or break a service.  As underlying ecosystems become more complex, with a huge supply chain of API's, cross-boundary federations and devices, how can the end user be both protected, yet offered a seamless registration and login experience? Dedicated user experience teams exist today, but their skill set will need to be sharpened and focused on the security aspect of any new service. 


2019 Digital Identity Progress Report

Schools out for summer?  Well not quite.  Unless you're living in the east coast of Australia, it's looking decidedly bleak weather wise for most of Europe and the American east coast.  But I digress.  Is it looking bleak for your digital identity driven projects?  What's been a success, where are we heading and what should we look out for?

Where We Are Today

Passwordless - (Reports says B-)

Over the last 24 months, there have been some pretty big themes that many organisations embarking on digital identity and security related projects, have been trying to succeed at.  First up, the age old chestnut...of passwordless authentication.  The password is dead, long live the password!  We are definitely making progress though.  Many of the top public sites (Facebook, LinkedIn, Twitter et al) provide multi-factor authentication options at least.  Passwords are still required as the first step, but the end user education and familiarity with something other than a password during login, must surely be the first steps to getting ridding of them entirely.  2018 also saw the rise of WebAuthn - the W3C standards based approach for crypto based challenge response authentication.  Could this hopefully accelerate adoption to a password-free world?

API Protection - (Report says C+)

API's will eat the world?  Well, digital disruption needs speed, agility and mashups.  API's help organisations achieve those basic aims, but where are we, with respect to the protection of those API's?  API management platforms are now common in most enterprise architectures.  They help to perform API provisioning, versioning and life cycle management, but what about security?  Many use cases fall into the API security band wagon such as service to service authentication, least privilege authorization, token exchange and contextual throttling.  Most API services are now sitting comfortably behind basic authentication, but fine grained controls and basic use cases such as token revocation and rotation are still in their infancy.  Report says "we must do better".

Microservices Protection - (Report says B-)

Not all API's are microservices, but many net new additions to projects will leverage this approach.  But microservices infrastructures, bring many new security challenges as well as benefits.  Service versioning, same service load balancing, high through puts and fine grained access controls have created some new emerging security patterns.  Both the side car and inflight/proxy approach for traffic introspection and security enforcement have appeared.  Microservices by their design, normally means very high transactions per second, as well as fine grained access control - with each service performing only a single task.  Stateless OAuth2 seems to fit the bill for many projects, but the consistency around high scale token introspection and scope design seems immature.

IoT Security - (Reports says C-)

Many digital disruption projects are embracing smart device (HTTP-able) infrastructures.  Pairing those devices to real people seems a winner for many industries, from retail, insurance to finance.  But and there's always a but, the main interest for many organisations is not the device, but the data the device is either collecting or generating.  Device protection is often lacking - default credentials, hard coded keys, un-upgradable firmware, inability to use HTTPS and the inability to store access tokens are all very common.  There are costs and usability issues with increased device security and no emerging patterns are consistent.  Several regulations and security best practice documents now exist, but adoption is still low.

User Consent Management - (Report says B-)

GDPR has probably had the biggest impact, from an awareness perspective, than any other piece of regulation relating to consent.  The consumer, from a pure economic buyer perspective at least, has never been so powerful.  One click away from a competitor.  From a data perspective however, it seems the capitalist corporate machine is holding all the cards.  Marketing analytics, usage tracking, location tracking, you name it, the service provider wants that data to either improve your service, or improve their ability to market new services.  Many organisations are not stupid.  They realise that by offering basic consent management functionality (contact preferences, ability to be removed, data exportation, activity viewing) they are not only ticking the compliance check box, but can actually create a competitive advantage by giving their user community the image of being at trusted partner to do business with.  But will the end user be ever truly in control of their data?

What's Coming

The above 4 topics are not going away any time soon.  Knowledge, standards maturity and technology advances, should all allow each of those areas to bounce a grade within the next 18-24 months.  But what other concerns are on the horizon?  

Well skills immediately spring out.  Cyber security in general is known to have a basic skills shortage.  Digital Identity seems to fall in to that general trend and some of these topics are niches within a niche.  Getting the right skill set to design micro services security or consent management systems will not be trivial.

What about new threats - they are emerging every day.  Bot protection - at both registration and login time - not only helps improve the security posture of an organisation, but also helps improve user analytics, remove opportunities for false advertising and provide a clearer picture to a service's real organic user community.  How will things like ML/AI help here - and does that provide another skills challenge or management black hole?

The final topic to mention is that of usability.  Security can be simple in many respects, but usability can make or break a service.  As underlying ecosystems become more complex, with a huge supply chain of API's, cross-boundary federations and devices, how can the end user be both protected, yet offered a seamless registration and login experience? Dedicated user experience teams exist today, but their skill set will need to be sharpened and focused on the security aspect of any new service.