Expiration in VO
WARNING: This part of the documentation is not complete yet.
Introduction
In Perun, the user becomes a member of Virtual Organizations (VO), their groups and possibly subgroups.
The VO is the main unit for maintaining a proper user structure, but membership in a group or subgroups only addresses user access to the required services.
The manager may limit the membership in the VO to a certain period of time. See below for setting user expiration rules.
Application form
To user access, the VO manager has the option to set up an application form for users who are interested in membership.
With the application, the manager can obtain the necessary attributes from the user to allow him to access the service.
How to create application form - designed especially for VO/group manager.
Notifications
Notifications must be set for these applications, which are predefined email information for the user and also for managers.
Notifications for users may contain information such as:
- The application has been accepted and is awaiting evaluation
- Application was rejected + reason for refusal
- Application was accepted – User joined the VO
Notifications for VO managers may include, for example:
- Information that the user has submitted an application
- Information that the user has submitted to extend membership
Notifications are set as – initial (for the first registration to the VO) and extension (for extension membership).
Examples of notifications are here.
Expiration rules
Please note: If expiration rules are not set it means users membership never expires.
A main important element in this part of the documentation is the possibility to set the expiration in the VO.
Thus, a manager can set an expiration date (for example, once a year) when users of his VO must extend membership if they want to continue as members of the VO.
In this way, the VO manager can maintain order in his VO structure.
In the event of expiration in the VO comes to the setting of notifications about which we said, see text above.
Explanation of expiration and examples will be described later in text.
Manual expiration set
The VO manager can set the expiration to the users manually.
When the valid user is set to expiration in past, Perun will switch user status to expired at nighttime data processing.
When the expired user is set to expiration in the future, Perun will switch user status to valid at nighttime data processing.
Automatic expiration set
Membership expiration can be set so that the process itself occurs automatically, without the tedious intervention of the VO manager.
The VO manager sets expiration settings using attributes. Instructions for setting attributes are in the text below.
Creating rules to account extensions
If it is necessary to set attribute membershipExpirationRules for VO, an attribute can be added in Settings in VO. Its items can be:
doNotAllowLoa - list of LoAs separated by comma, which won't be allowed in VO (users can't become members).
period - time period to extend membership. It can be set as a fixed date (without year), e.g. 1. 2. or as a number of days/months/years with prefix "+"
that defines the time period that extends membership. Units are d = day, m = month, y = year, e.g. +128d extends account to 128 days. +6m, +1y.
doNotExtendLoa - list of LoAs separated by comma, that are not extensible.
gracePeriod - when a present date of initial application or extending request equal extension date minus gracePeriod then user account is extended to the next time period
(period date in next year). Value is in format number days/months/years. Units are d = day, m = month, y = year, e.g. 128d, 6m, 1y
periodLoa - an exception in period for given LoA. Format of value is: LoA|period[.]. LoA is given Loa number and period is in same format as a period.
The optional dot at the end means whether extend an account to the user with filled membershipExpiration or not. If a dot is present, the user with filled membershipExpiration is not allowed to extend an account.
Explanation and examples
In the event that a user gets into a VO via synchronization to a group, it is an indirect membership in the VO and therefore the expiration period in the group is applies.
If a user is a member of multiple groups, he is a valid member of the VO as long as he/she is valid in at least one of the groups (no matter of expiration period in VO). Therefore, in this case, the user is expired within the VO.
In all of the following cases, it is taken into account that at the end of the expiration period, the user didn‘t apply to extend the membership. Extending membership wouldn‘t lead to scenarios, see labels below!
1) The user has become a member of the VO and after also become a member of the group.
The group is part of the VO and both may have different expiration settings.
The user comes to the group through the application to the VO and also to the group.
If group expiration is set once a year and the VO has a set expiration date to never (it means expiration rules are not set),
after the expiration date, the user's membership will expire in group.
2) The user has become a member of the VO and two groups.
The groups are part of the VO. Groups and VO may have different expiration settings.
The user comes through the applications to VO and both groups.
If a user is a member of multiple groups, he/she is a valid member of the VO as long as he/she is valid in at least one of the groups.
In this case, the user is valid in VO and group #1.
3) The user has become a member of a group by synchronization and he/she is an indirect member of the VO.
The group is part of the VO and both may have different expiration settings.
The user comes to the group through synchronization, thereby becoming an indirect member of the VO.
If group expiration is set on never and the VO has expiration set once a year,
the user will have the valid state in group and also he/she is valid in VO.
