CIAM Solutions- FAQ1 : Renewable Guest User Accounts
Today I am going to discuss another aspect of Guest User account scenario which described here in Johan’s blog
Why we need a Guest User Account?
At a glace a guest user account is a temporary user account that a user can use for a defined period of time. But there can be different requirements around this guest user account story as shown below.
Let’s look at a requirement we got recently.
Another Guest User Account use case:
In some business use cases, they have a requirement of having expiry time for all their user accounts similar to guest accounts. Whenever user wants to expand his expiry time, the user has to fill a form and request its from the administrator. A user should get a notification when his account is closer to expire. If the account expired, the account will be deleted after n days, but still a notification should be sent to the user prior to 5 days before it expire. This is merely to comply with GDPR.
From the looks of this use case, it obvious that WSO2 Identity Server does not support this requirement OOTB. Not even in the latest release. But, still we can!!
If you think deeper with your creative skills, we can easily achieve this requirement from the existing features and extension points. In this blog, I would like to elaborate how we can cater this solution to match the business need by using WSO2 Identity Server which is an Open Source IAM product in the market.
Step 1. Expiry time for the guest user account
In this use case, the expiry time can be extended if the user requests to do so via a form. Hence this time should be changeable.
Therefore, we can create a custom claim called Account Expiry Date which can store a Date which the account will expire.
In order to disable the user account access, we can use this Account Expiry Date claim to write a XACML policy which can restrict user from accessing this user account beyond the expiry date.
This policy will enable conditional access to all the service providers in the authentication flow.
Step 2. Update user account expiry time when user is created
When a user is created in the new system, we need to assign a expiry time for each user account. For this we need to extend the do POST Operation event listener when creating user. Simply postAddUser method can be overridden to update the Account Expiry Date claim. You can refer https://is.docs.wso2.com/en/latest/develop/user-store-listeners/ documentation on how to that.
Step 3. Handle account expiry notification and Deleting account after expiry
After setting the expiry time, the next thing that we need to think is how to expire the accounts or disable the account after expiry.
What WSO2 Identity Server has in the product is the idle account disabling feature. But here we want is to disable the expired accounts. So in order to achieve this, we can follow a similar approach.
Simply we can write a AccountExpiryNotificationHandler which subscribed to POST_ADD_USER event. When a user is added and expiry time is set we can start a scheduler similar to “account suspension after idle time” use-case in https://github.com/wso2-extensions/identity-governance/blob/master/components/org.wso2.carbon.identity.account.suspension.notification.task/src/main/java/org/wso2/carbon/identity/account/suspension/notification/task/handler/AccountSuspensionNotificationHandler.java#L196
In this notification handler we need to handle 4 main key activities:
- Notify the user via an email that his account is expiring before n days prior to the expiry date. — In this email we can add a form to fill submit for an account extension. Based on the entries of the form admin can manually update the Account Expiry Date claim.
- Disable the account on the expired date and send an email. This email should contain a form that can request to activate the account and mention the date that account will get deleted.
- Send an email n days after to expired date to notify the user that his account will get deleted in y days.
- Delete account in n+y days after the Account Expiry Date.
Note : This n and y values can be changed according to the business requirement.
To write the Custom Notification Handler you can refer https://is.docs.wso2.com/en/latest/develop/writing-a-custom-event-handler/ following documentation for more details and syntax.
You also can achieve this same requirement by a daemon or a java client that runs in background, separately from Identity Server and periodically check account expiry time. As this is a separate client, this will not effect WSO2 Identity Server performance as well. But you need to use a third party notification mechanism to send emails. If you have enough technology then this is the easiest way to do.
If you are able to successfully achieve all these three steps, then you have already achieve this business requirement.
So with WSO2 Identity Server you can easily achieve these types of business requirements through our existing extension points. This is one of the main advantages of using WSO2 Identity Server as your CIAM solution.
Let’s meet with another solution for another problem in CIAM world!!!
