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.



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.

New version of ForgeRock Identity Platform™

This week, we have announced the release of the new version of the ForgeRock Identity Platform, which brings new services in the following areas :

  • Continuous Security at Scale
  • Security for Internet of Things (IoT)
  • Enhanced Data Privacy Controls

FRPlatform

This is also the first identity management solution to fully implement the User-Managed Access (UMA) standard, making it possible for organizations to address expanding privacy regulations and establish trusted digital relationships. See the article that Eve Maler, VP of Innovation at ForgeRock and Chief UMAnitarian posted to explain UMA and what it can do for you.

A more in depth description of the new features of the ForgeRock Identity Platform has also been posted.

The ForgeRock Identity Platform is available for download now at https://www.forgerock.com/downloads/

In future posts, I will detail what is new in the Directory Services part, built on the OpenDJ project.


Filed under: Identity Tagged: access-management, Directory Services, ForgeRock, identity, Identity Relationship Management, opendj, platform, release, security, uma

Nouvelle version de la Plateforme Identité de ForgeRock

Cette semaine nous venons d’annoncer la nouvelle version de la Plateforme d’Identité de ForgeRock (ForgeRock Identity Platform™).

FRPlatform

La Plateforme d’Identité de ForgeRock est maintenant capable d’évaluer dans son contexte et en continu, l’authenticité des utilisateurs, des appareils et des objets.

Cette nouvelle version est aussi la première solution qui offre le support de la norme “User Managed Access” (UMA) qui permet aux individus de partager, contrôler, autoriser et révoquer l’accès aux données de façon sélective, et donc offrent aux entreprises une solution ouverte et standardisée pour protéger et contrôler la confidentialité des données de leurs clients et employés. Ces besoins de confidentialité et de gestion du consentement deviennent importants dans le domaine de la santé, des objets connectés ou même dans le secteur des services financiers.

Pour mieux comprendre “UMA” et les services offerts par la Plateforme d’Identité de ForgeRock, je vous propose de regarder cette courte vidéo (en Anglais).

La plateforme ForgeRock Identity Platform est disponible en téléchargement dès à présent à l’adresse : https://www.forgerock.com/downloads/

Les détails des nouveautés de cette version sont sur le site de ForgeRock.


Filed under: InFrench Tagged: ForgeRock, identité, identity, opensource, plateforme, platform, release, uma