2016-08-25#

What's New#

In the past we needed to provide Authentication and Authorization at the application level and that Digital Identity was verified, via various methods, back to LDAP. Using LDAP we typically only used password Authentication.

When we started using LDAP, most of the applicaitons were traditional monolithic applications which all of the application work was done within one large application often with some back-end storage database.

This scenario allowed us to provide Consistent Sign-On so end users only had one username/password combination and, in general, all was well.

Then we wanted Single Sign-On and so we added an WEB Access Management system in front of LDAP. These proprietary WEB Access Management systems did allow HTTP Single Sign-On in most cases. We often added GSSAPI to the mix so we could usually get the credentials from the Windows Client Operating System and use it to perform Authorization to the WEB Access Management and provide even a broader range of Single Sign-On and, in general, all was well.

Then Security Assertion Markup Language (SAML) came along and we could connect to outside monolithic applications and provide even a broader range of Single Sign-On and, in general, all was well.

Then the world started changing. The monolithic application wanted became too large and complex to handle and their appetite for access to data not within their databases became more and more desirable. We added more and more attributes to LDAP which we synchronized from this data-store to that data-store and the Identity And Access Management systems became too complex to handle.

The monolithic application projects became larger and more complex. Then Identity And Access Management projects became more and more complex.

As tends to happen in the technology world, programmer's started using Lean Product Development to simplify and prioritize what was really necessary. These Lean Product Development caused the monolithic applications to be broken down into smaller "chunks" of applicaitons that were loosely coupled. These loosely coupled applicaitons have become (and will become even smaller) and adds to the agility of the Lean Product Development.

This continued Lean Product Development has led to the movement to Application Programing Interfaces where nearly any application, monolithic or not, can have almost "instant" access to the data.

And in this API Economy, Application Programing Interfaces (APIs) act as the digital glue that links services, applications and systems. This allows businesses to make the most of their data to create compelling customer experiences and open new revenue channels.[1]

What does it mean to Identity And Access Management teams?#

More work and more learning. We used to only need to provide Authentication and Authorization services for users and now we need to be able to determine if this Application is able to access some API or other application on be-half of this user.

The good news, we have help. OpenID Connect provides the tools to make all this happen and there are a lot Open Source projects that can help.

More Information#

There might be more information for this subject on one of the following: ...nobody

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-11) was last changed on 01-Dec-2016 12:45 by jim