Automated Expiry of Group Membership

Question

Hi,
is there a way to expire group membership via Adaxes?

We would like to limit the user's membership in certain groups based on an expiry date. Idea so far is to establish a scheduled task removing a user from group when expiration of membership for that user in the group is reached. Question is, where to store the information needed for such a task. The expiry date shall be provided individually during the request/approval process by the approver. We can also think of having a fixed duration defined on the target group. Then we need the point in time when the user was added to the group. Type of groups shall be both security groups and distribution groups.
Any ideas?

Thanks for your help.

Greetings,
Thomas

Comments

Hello Thomas,

What do you think about the following scenario:

1. In the Web interface, there will be several Home Page Actions, using which users can request membership in a group. There will be one Home Page Action for each group.
2. When a user clicks a Home Page Action, they will be presented with a form where they will be able to specify the end date where their membership in the group should be revoked. Once they submit the form, the operation will be sent for approval.
3. Once approved, the user will be added to the group, and the end date that the user specified will be saved in a certain property of the user. For example, you can use one of Adaxes virtual properties. Adaxes has 5 properties to store date/time information (CustomAttributeDate1 ... CustomAttributeDate5), so you'll be able to handle up to 5 groups in such a manner.
4. A Scheduled Task run, say, once a day will check the date specified in the user properties and will remove the user from the group on the date specified.

Will this suit your needs?

---

Hello,

We already have a generic Home Page Action for users to request membership in groups. Currently we have >100 groups a user can request membership for. Therefore one Home Page Action for each group would not be the best solution. But we can think of integrating the expiry date input into this generic Home Page Action.

I was also thinking about the CustomAttributes but we propably have more limited groups for each user than CustomAttributes...
The other aspect is that the apporver shall be able to define or at least edit the expiry date before approving.

Thank you!
Greetings,
Thomas

---

Hello Thomas,

In such a case, we can suggest an alternative solution. You can use a virtual property that can store multiple values. For example, CustomAttributeTextMultivalue1 can store multiple string (text) values.

So, instead of storing the membership expiry date in the user properties, you can store the date when membership expires and some property of the user who was added to the group (say, GUID) in the CustomAttributeTextMultivalue1 property of the group, one value for each user. When user requests membership, and membership is granted, the date when membership should be revoked, alongside with the user's GUID, is stored in the CustomAttributeTextMultivalue1 property of the group by a Business Rule. When membership expires, a Scheduled Task removes the user from the group and removes the value that corresponds to the user from the CustomAttributeTextMultivalue1 property.

As for editing the expiry date before approving, currently an approver cannot update properties of an operation before approving it. We have such a request in our product backlog, but currently this is impossible. As a workaround, the approvers can use the denial reason. When denying a request, approvers can specify a reason why the request is disapproved. In the denial reason they can, for example, notify users that they can request membership for a shorter time, for example.