This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
IDM The Application Developers Dilemma
IDM The Application Developers Dilemma

Version management

Difference between version and

At line 1 added 39 lines
!!! Overview
[{$pagename}]
When creating an [application], whether it is for internal if [authentication] or [compliance] is required then the developer has some difficult issues to deal with:
* How do I deal with [authentication]?
* Where do I get the user’s [Digital Identity] information from?
* What [Digital Identity] information do I need based on the problems I have to solve?
* How do I make sure [Digital Identity] information is correct?
* Where do I store the [Digital Identity] information?
* How do I protect the [Digital Identity] information?
* How do can we [auditing] and show [compliance] for the [Application]?
!! Not the Primary Objective
These are difficult questions and are not the primary objective of the [application] team, usually these are the least of the [application] teams concern.
Usually the [application] team will use what the method that they are most comfortable with to and own identity infrastructure. [Database] developers create user tables, login screens and processes, [permission] and [authorization] modules, account registration procedures, and profile management tools.
!! And they do it again and again.
The outcome is what is common in almost every organization that we look at today.
Many, many [Data Stores] with identity and [privacy] information spread all over the [organizational Entity].
A large insurance company admitted they found more than 400 [applications] that contained [Digital Identity] and [Private data] information.
This presents the following issues for organizations to deal with:
* No methodology for consistent, centralized enforcement of enterprise-wide policies
* Users with [passwords] in many different [Data Stores] each with:
** Different [passwords]
** No common method to synchronize [passwords]
** Multiple [Password Policy] [enforcement|Policy Enforcement Points]
** Multiple [Data Stores] that require updates (all via different methodologies) on termination or other user profile changes
* The list goes on and on.
!!Easy Sell
Needless to say [Identity Management] should be an easy sell to any developer team.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop