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 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 your self as a user. Each service ask their own set of questions from you. Mostly starts with your E Mail (well, except for Google :p ) and then your personal details such as name, address, contact information, etc. This concept is know 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 Creating 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.
In this case, the admin creates the user account and add a password as well. The user will be notified about the account via an email or any other way. Even though the user can change their password ones login, the admin has access to the new account for a short period of time. This considers as a security hole in some cases, which leads us to the next method.
2. Creating Accounts with Ask Password Option.
Here the admin doesn’t set a password to the account. Once the account is created, the user will receive an E Mail with a special link embedded, and he/she can set a password to the account using this link.
I don’t think this needs any introduction as all of has 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. 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 uses security questions, which were collected when you create 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 is a scenario that you don’t see in much sites nowadays. This talks about a user forgetting his/her username. Mostly this is used in place 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, user is asked to enter several attributes of the account such as email, first name, last name, etc. Once the account is identified, an E Mail 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 login to the system nor use it’s 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 measurements, most systems locks out a user account if they receive too many incorrect login attempts. It could be a hacker or someone doesn’t belong trying to get access to the account. We can see this use case implemented in banks and other highly secure web sites.
- Keep new user accounts locked until a specific attribute is confirmed.
- Their 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 their but you can’t login or perform certain actions until you confirm you 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 lock or disable such accounts. You may have to go through a special process to recover the account again.
- Lock user accounts based business logic.
- For an example, your account could be locked due to issues with your subscription. You won’t be able to login or use the services until you pay the amount.
Password Management Stories
There are a couple of popular user stories around managing passwords of users. I’m grouping them together to understand them easier.
1. Password Expiration
As the name suggests, 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 n 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 an example the below policy can be seen in most places.
Passwords should contain,
- At least one upper case letter
- At least one lower case letter
- At least one digit
- At least one special character
Above are the most commonly known Identity Governance User Stories we see every day. From my next post, I’ll explain how to setup these stories to your system using WSO2 Identity Server.
Until then, cheers!