@laudney Sounds great - glad you understand this is an area Redd-ID can touch on.
Here’s an excellent paper for reference material: http://arxiv.org/ftp/arxiv/papers/1101/1101.0427.pdf
Laudney you may know some of the below but I’m putting it here for anybody else interested in this train of thought.
The 4 basics of IDM:
- a directory of the personal data the system uses to define individual users (think of it as an ID repository);
- a set of tools for adding, modifying and deleting that data (the access lifecycle management stuff);
- a system that regulates user access (enforcement of security policies and access privileges);
- and an auditing and reporting system (so you’ll have a way to verify what’s actually been happening on your system).
From here evolved the Federated IDM:
Federation lets you share digital IDs with trusted partners. It’s an authentication-sharing mechanism designed to allow users to employ the same user name, password or other ID to gain access to more than one network. commonly referred to as “single sign-on.” A single sign-on standard lets people who verify their identity on one network or website carry over that authenticated status when moving to another. The model works only among cooperating organizations—known as trusted partners—that essentially vouch for each other’s users.
So a big consideration/challenge for Redd-ID would be to become trusted to the point where other platforms are happy to integrate.
The federated model relies on the security assertion markup language specification, (SAML)
I’m not from a technical discipline so I wouldn’t be able to describe the ‘problems’ of SAML which Redd-ID could possibly solve. Im a project manager so can understand on a design & infrastructure level what the pitfalls in UI/compliance may be in existing IAM frameworks.
Here is the current considerations for any IAM system:
Features, such as authentication, authorization, trust and security auditing, are part and parcel of the top ID management systems.
An identifier employed by the user to gain access to a network. ie - user’s password, public key infrastructure (PKI) certificate or in a physical environment: biometric information (fingerprint, retinal scan).
The process of removing an identity from an ID repository and terminating access privileges.
Description of the user and his/her/its access privileges. (“Its” because an endpoint, such as a laptop or a cell phone, can have a digital identity.)
The set of attributes that specify the access rights and privileges of an authenticated security principal.
Identity lifecycle management
Buzz phrase. Like access lifecycle management. It refers to the entire set of processes and technologies for maintaining and updating digital identities. Identity lifecycle management includes identity synchronization, provisioning, de-provisioning, and the ongoing management of user attributes, credentials and entitlements.
The process of ensuring that multiple identity stores—say, the result of an acquisition—contain consistent data for a given digital ID.
Common for all ID management systems - allows users to re-establish their own passwords, relieving the administrators of the job and cutting support calls. The reset application is done by a set of questions to verify the user’s identity.
The process of creating identities, defining their access privileges and adding them to an ID repository.
A digital identity with one or more credentials that can be authenticated and authorized to interact with the network.
Is there anything missed?
So basically a good place to start would be to go over the above IAM considerations/facets and identify the problems with each component + which one’s and how Red-ID solves.