How-To: Enable Guest Accounts in WSO2 Identity Server

Control Account Activation and Inactivation Time

Introduction

Guest accounts are transient accounts that are created in an organization for for a specific purpose with a specific expiry date, and then automatically gets deactivated once the expiry date is reached. A very popular requirement for creating guest accounts outside the scope of WSO2 Identity Server, is for Internet access in organizations.

Guest accounts are supported in most popular LDAP implementations like Microsoft Active Directory and Oracle Directory Server. In these cases if a user tries to authenticate after his/her account is expired, the LDAP authentication will fail and an appropriate error will be thrown. However, there can be situations where organizations don’t have such products that support guest accounts natively, and somehow needs this to be supported by the IAM provider. WSO2 Identity Server doesn’t have a first class feature to support this requirement till the latest version of the product, at the time of writing this post — 5.8.0. However you can build a solution for this requirement around Identity Server’s capabilities.

Requirements

The “guest account” problem can be broken down to following two requirements.

1. Guest accounts must be active only within a specified time period
2. Deactivate the guest account after the expiry time

Solution

A different way to look at requirement 1 is as an “authorization” problem. In other words, these guest accounts are going to be allowed to login to service providers only within the stipulated time period and not otherwise. This is equivalent to a time based access control problem in XACML [1]. So to build a solution for this problem we can follow steps given below:

1. Define a claim in WSO2 IS that contains the expiry date of the account.
2. Optionally you can designate a particular user store for your guest accounts. This can help improve performance of the solution by omitting XACML evaluation for normal account logins.
3. Implement a XACML policy that authorized access to service providers by guest accounts. The target may specify the user store in case a user store was designated for guest accounts in step (2) above. The target of the XACML policy may narrow the application of the policy to a subset of service providers if needed. The policy must include a rule which validates that the current date is well before the account’s expiry date.
4. Enable conditional access to service providers [2].

Sample XACML 3.0 Policy

<Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" PolicyId="guest_account_policy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable" Version="1.0">
   <Target>
      <AnyOf>
         <AllOf>
            <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
               <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">authenticate</AttributeValue>
               <AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false"></AttributeDesignator>
            </Match>
         </AllOf>
      </AnyOf>
   </Target>
   <Rule Effect="Permit" RuleId="guest_permit">
      <Condition>
         <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:any-of-any">
            <Function FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-less-than"></Function>
            <AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-date" Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment" DataType="http://www.w3.org/2001/XMLSchema#date" MustBePresent="true"></AttributeDesignator>
            <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:date-bag">
               <Apply FunctionId="urn:oasis:names:tc:xacml:3.0:function:date-from-string">
                  <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">
                     <AttributeDesignator AttributeId="http://wso2.org/claims/accountExpiryDate" Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"></AttributeDesignator>
                  </Apply>
               </Apply>
            </Apply>
         </Apply>
      </Condition>
   </Rule>
   <Rule Effect="Deny" RuleId="deny_others"></Rule>
</Policy>

The second requirement can be achieved to a certain extent by enabling the “idle account suspension” [3] feature in WSO2 IS. The only catch is that this feature checks for the last logged in time of the account in WSO2 IS; it doesn’t look for the last successful authorization of the particular account. In other words, if the user keeps on trying to login with WSO2 IS after the account expiry date, those events get captured as successful authentication attempts but unsuccessful authorization attempts due to the XACML policy enforced. What this means is that the account deactivation point for those accounts may get extended and as a result guest accounts are going to be eventually deactivated after the user gives up trying to login with his/her account, but there is no certainty as to when it will happen. But this delay is acceptable for most organizations.

References

[1] https://docs.wso2.com/display/IS580/Working+with+XACML

[2] https://docs.wso2.com/display/IS530/Configuring+Access+Control+Policy+for+a+Service+Provider

[3] https://docs.wso2.com/display/IS580/User+Account+Suspension