Good Identity Architecture

24-Sep-2013 Like this? Dislike this? Let me know

Practically every website these days uses email address as a login name. This is a very clever and useful construct for many reasons including:


email addresses and logins are things that a user experiences at the interface to the system, not the internal design. I recently came across a design where the object to capture User exactly mirrored the database table User (already a dead end...) and was constructed as follows. I am showing the private fields only but the get/set methods did nothing except get/set these fields so in this context they are only a distraction:

    class User {
        private String emailAddr;
        private String cryptPW;
        private String prevCryptPW;
        private int wantsEmailNotify;
        private Date createDate;
        private String whoAmI;
        private String avatarKey;
I give the developer +1 for at least encrypting the password (or so the field claims) but that's about it. The single User entity above is heavily overloaded and does not provide the necessary separation of concerns. An email address is not a suitable internal identifier for identity and it is not the basis for an identity architecture.
Systems must strongly define and implement the following five concepts:
  1. Digital Identity
  2. Identity Attributes
  3. Credentials
  4. Identity-based Application Attributes
  5. Authentication

Before we show the reengineered version of the above, let's explore the concepts in greater detail.

  1. Digital Identity
    Digital Identity (DID) is an abstract identifier for an actor. which is a person or a system process (a.k.a. a functional ID or system ID). Digital Identity carries no other information. Not even a name or or an SSN. We'll see why in a moment.

  2. Identity Attributes
    Identity Attributes are data associated with a DID that map one-to-one with the DID. These attributes can include name, address, SSN, email address(es), etc. They do not include information at an application level or, more generally, things associated with the DID as opposed to things that are fundamental to the actor behind the DID. The reason these attributes are separate from the DID is that although there is only a single domain of DID, there may be more than one locus of infomation for identity attributes. For example, a system design may choose to manage SSN and other private data in objects and databases separately from other less sensitive data. These other objects and databases are keyed by DID just like email and name and thus are peers.

    In practice, though, it has become common to embed simple identity atttributes like name and email address directly into the DID structure. One can pragmatically rationalize the difference between sensitive and non-sensitive information and let non-sensistive information live in the DID structure. Further, co-locating critical info like actor name with DID may make processing simpler and therefore more reliable than if these attributes lived elsewhere. For the purposes of this article, however, we are showing what the high-bar design should be.

  3. Credentials
    A credential contains three things:
    1. A DID
    2. Any amount of material that is required by the authentication engine for that kind of credential
    3. Relative strength
    The most common form of credential is the LoginPassword credential. For DID A456, for example, it would contain DID A456, login "", and an encrypted password. Very important concepts are present here:

  4. Authentication
    Authentication is the process of taking a credential appropriate for consumption by a particular authenticator process and basically returning yea or nay. Of course, more sophisticated things like tokens and such can be returned too but truly the main purpose is simply to yield true or false.
    Authenticators are not necessarily credential stores although very often they play this role because of the close association of credential and the logic necessary to validate it. Conceptually, however, credentials need to be managed independently of a tool that consumes them -- especially simple credential types like LoginPassword.

  5. Identity-Based Application Attributes
    This closely aligns with entitlements management and represents information that is bespoke to an actor and its interaction with a particular program and/or system. Things like "maximum comments to make," "dollar limit of purchases", "default screen color," etc., are well away from the core of DID management and authentication and need to be managed in a separate set of objects and persistors. They are of course still keyed by DID.

Overall, this design leads to increased flexibility, security, and changes to data without disrupting the key structure of the information architecture:

User, revisited

To make this all very concrete, let's go beyond the classes and recast the User design above in a set of RDBMS tables. Assume a new user setup where the user enters for an email address and a password. Upon completion, this is what we might see. Essential bookkeeping fields like createdOn, modifiedOn, checksum have been omitted in places for clarity:

  • The setup process confirmed that the login+password was unique in the domain and a new identity (DID) could be created.
  • The system process that created the DID is itself identified as X111.
  • It is important to understand the level of vetting/authenticity of a particular DID and since this was created anonymously over the internet, a code of I2 was assigned. An employee of the site or a B2B partner might have a different code indicating stronger level of provenance.
  • The email address was captured but as an anonymous internet login, no first or last name is known. A "premium" user or one that elects to add the information would populated these fields at a later time.
  • The initial login+password credential set up for the user; note that the previous encrypted password is blank.
  • This kind of credential carries strength 1. Credential strength can be used by consuming application/entitlements logic to drive features and capabilities. Other kinds of credentials may be stronger, meaning they are more securely linked to the actor to whom they were issued.
  • All application level attributes live in a table (or tables) well-removed from the core identity and credential information.

To demonstrate the capability of this design, assume that Bob's engagement with the site expands over time. We might see the following:

  • As a result of further vetting and engagement, the authenticity and connection between Bob and his DID has improved to provenance level I4.
  • More detailed information about Bob is known.
  • In this system, login+password combined is used as a test for uniqueness of credential material, not just login. Thus, Bob can have a second login with the same name ( and a different password. The login+password credential is strength 2. The idea here is Bob has one login for low-security interaction and one for higher-security interaction.
A457Finger14552(binary data)4
  • Fingerprint credentials are also supported. Some fingerprint authenticators may not be able to match based on just the fingerprint data and may require an ID (i.e. ID is quickly looked up first, then fingerprint data is matched). We show such a setup here where Bob has been assigned ID 4552 in the Finger1 authentication engine.
  • Although we show the fingerprint data captured here in the FP column, more likely the Finger1 authentication engine would domicile that data, in which case the ID becomes the critical link between our system's DID based world and the identity domain in Finger1. In the most exterme vendor-specific case, the authentication engine owns all the data, and will have to capture DID as well. Remember that a credential cannot be created without a valid DID.
  • The strength of this credential is 4, stronger than login+password.

Like this? Dislike this? Let me know

Site copyright © 2013-2017 Buzz Moschetti. All rights reserved