Identity Governance 101: Popular User Stories

What Is Identity Governance

In theory, identity governance refers to the policy-based centralized orchestration of user identity management and access control. In layman’s terms, this refers to managing different aspects of user accounts and how they access the resources offered. It’s believed that the concept of identity governance grew out of the Identity Governance Framework, a now-defunct project by the Liberty Group that aimed to standardize enterprise identity information usage.

That been said, there are some user stories that are identified and catered for in the WSO2 Identity Server, categorized under identity governance. I’m trying to talk about these stories one by one, hoping to have in-depth articles on each of them later.

User Self-Registration

This is the most used method to get a user registered to a particular system. Most online services we use regularly such as Google, Facebook, LinkedIn, Twitter, etc. uses this method. Simply said, if you wanted a new user account on these platforms, you’d go to their website and register yourself as a user. Each service asks you its own set of questions. It mostly starts with your email (well, except for Google) and then your personal details, such as name, address, contact information, etc. This concept is known as user self-registration.

You may wonder what if you use the option of register with Google or sign up with GitHub. That’s also the same concept. Instead of you entering your details, a third party will send them to the system you want to register with. In the IAM domain, we call these third parties identity providers. In this case, these are trusted identity providers by the system you’re trying to register with.

User Account Created by Privileged User

Even though the most common account creation method is the above-mentioned self-registration, there are instances where accounts are created by a privileged user of the system, maybe an administrator, and let the users use those accounts. There are two main methods to this, as well.

  1. Creating accounts with passwords
    1. In this case, the admin creates the user account and adds a password, as well. The user will be notified about the account via email or any other way. Even though the user can change their password once they log in, the admin has access to the new account for a short period of time. This is considered a security hole in some cases, which leads us to the next method.
  2. Creating accounts with ask password option.
    1. Here the admin doesn’t set a password to the account. Once the account is created, the user will receive an email with a special link embedded, and he/she can set a password to the account using this link.

Forgot Password

I don’t think this needs any introduction as all of us have forgotten our passwords one time or another. This user story talks about what should be done in that case to recover the user’s account. The most common method is to ask for your registered email and send a password reset link to that email.

There could be other methods to reset the user’s password, as well. Some websites use security questions, which were collected when you createed the account in the first place. Some may send a one-time password (OTP) to your registered mobile phone and use that to reset the password. More secure instances such as banks may require you to visit in-person to recover your online account.

Forgot Username

Forgot username is a scenario that you don’t see on many sites nowadays. This talks about a scenario where a user forgets his/her username. Mostly, this is used in places where you’d use a username to access your account rather than your email. The main part of the story is identifying the user account. In most cases, the user is asked to enter several attributes of the account such as email, first name, last name, etc. Once the account is identified, an email with the username will be sent to the registered email address of the account.

User Account Locking/Disabling

This is a bit advanced user story that we can see in the identity governance category. Simply the idea is to lock the user account so that the user will not be able to log in to the system nor use its resources. There could be multiple sub-stories that the ability to lock or disable a user account is needed. 

  • Lock user account on incorrect login attempts.
    • As an advanced security measurement, most systems lockout a user account if they receive too many incorrect login attempts. It could be a hacker or someone who doesn’t belong trying to get access to the account. We can see this use case implemented in banks and other highly secure websites.
  • Keep new user accounts locked until a specific attribute is confirmed.
    • There are many sites that need you to confirm your email before completing the registration process. This is another example of user account locking. Your account is there but you can’t log in or perform certain actions until you confirm your email or phone number or any other attribute.
  • Lock/disable idle user accounts.
    • If the user has not been logged into his/her account for a certain period, some systems tend to lock or disable such accounts. You may have to go through a special process to recover the account again.
  • Lock user accounts based on business logic.
    • For example, your account could be blocked due to issues with your subscription. You won’t be able to log in or use the services until you pay the amount.

Password Management Stories

There are a couple of popular user stories around managing the passwords of users. I’m grouping them together to understand them easier.

1. Password Expiration

As the name suggests, the passwords of the users are bound to be expired. Changing passwords regularly is known as a good practice yet as humans, we’d like to use the same password as it’s easy to remember. Therefore, companies tend to expire user passwords which will force us to reset, ensuring security. Depending on the security requirements of the organization, the time of expiry could vary. Most systems use 3 months expiry period.

2. Password History Management

In this user story, a user will not be allowed to use previously used passwords to be set as his/her new password. This is done as an extra security measurement and goes along with the above expiration story. We can see this use case implemented mostly in bank systems. It’d save a number of your previous passwords and prompt an error if you try to use one of them again.

3. Password Policies

Most of us are likely to use a password that is easy to remember. But easy to remember passwords are most likely to be vulnerable to hackers and other third parties. Therefore to prevent users from using simple, easy passwords, most organizations use password policies. Simply said, they want you to follow certain guidelines when setting a password. For example, the below policy can be seen in most places.

Passwords should contain,

  1. At least one upper case letter
  2. At least one lower case letter
  3. At least one digit
  4. At least one special character


Above are the most commonly known identity governance user stories we see every day. In my next post, I’ll explain how to set up these stories in your system using the WSO2 Identity Server. 

Until then, cheers!

Source link

Leave a Reply

Shopping cart


No products in the cart.

Continue Shopping