PDF

swipe to navigate

Identity attributes

Less is more. Users don't want to share personal information with third parties unless absolutely necessary -- it is an invasion of their privacy and a nuisance to enter. Organizations should strive to maintain a minimal set of data about users, because this limits their liability in the event that a security compromise leads to unauthorized disclosure of this information.

Best Practice

Hitachi ID Systems Best PracticesCollect only the minimum required data from each user.

In the same vein, users do not want to remember new things. If a user can use a pre-existing identifier to sign into the web portal, or an existing password to authenticate, then the user is much more likely to use the service than if he has to remember yet another new ID or password.

Best Practice

Hitachi ID Systems Best PracticesAllow users to use an existing identifier, such as their e-mail address, to sign into the system.

Best Practice

Hitachi ID Systems Best PracticesIf security policy allows for this level of trust, enable users to create a profile on the IAM system and directory based on a pre-existing identity.

The above should be the guiding principles when designing a schema for a B2C portal. Following are the data elements that together constitute a user profile:

Attribute Description
Identification
Primary ID A static, globally unique identifier. This could be a GUID or sequence counter and should not be visible to the user.
Friendly ID A globally unique, user friendly but possibly not static user identifier. The user's pre-existing e-mail address is an ideal choice here, since the user will easily remember it but (with the static, hidden identifier above) it can be changed without too much trouble.
Name The user's name. This may be broken up into first, middle and last names or left as a simple description field. Be sure to support Unicode if the user population is multinational.
Email Only needed if for some reason the Friendly ID is not Email. Used to contact the user.
Country or region Only needed if users in different locations must be treated differently.
Postal address Only needed if there is some reason to send physical mail to the user.
Federation provider ID To be used if users may enroll a profile and/or authenticate using a third party identity provider, such as Facebook, Google, etc. This is the identity of that provider (e.g., one code specifies Facebook, another code specifies Google, etc.).
   
External identity To be used if users may enroll a profile and/or authenticate using a third party identity provider, such as Facebook, Google, etc. This is the identity of this user at that provider. It is normally an opaque string.
   
Authentication
Mobile number Optional. If included, it should be used for exactly one purpose and that is to authenticate the user in the event that he forgot his password.
Security questions Note: may not be required if users sign in via federated protocol.
  Note: it may not be appropriate to store this in the directory, since directories are designed to publish information and this is definitely not something we want to publish. This data should be cryptographically encrypted or hashed.
  Note: ensure that a cryptographically strong hash and random salt are used.
Password Note: may not be required if users sign in via federated protocol.
  Note: ensure that a cryptographically strong hash and random salt are used.
  Note: ensure that users are required to choose hard-to-guess values and that there are no onerous requirements limiting length or character set.
   
State of the profile
Creation date Time/date when the account was first created
Activated date Optional. Time/date when the account was activated. For example, a user might have to complete security questions, choose an initial password, accept a terms and conditions page or demonstrate possession of an e-mail address after an account is created but before it can be used.
Last good login Time/date of last successful login.
Type of user Typically there are at least two types: end users (i.e., b2c customers) and IT support users. The former are extremely limited while the latter are allowed to manipulate the former.
Last failed login Time/date of last failed login.
Failure count Number of failed logins since last good login.
Number of successful logins Optional. Can be used to see which users are active.
Intruder lockout Boolean -- indicates that the account is temporarily disabled from login. Optional but strongly recommended.
Lockout expiry When the lockout flag (if set) should be automatically cleared.
Administratively disabled Boolean -- indicates that the account has been disabled on purpose by a user with elevated privileges.
Expiration date Optional. Specifies that the user profile should be blocked from login and perhaps disabled after the indicated time/date.
   
   
   
User preferences
Language Every multi-lingual portal should allow users to choose their preferred language, from a set of supported options.
Application data This is a placeholder, to represent anything else that the portal -- rather than the IAM system, identity processes, enrollment processes or authentication processes -- needs to track about users.

PDF

Comment via LinkedIn