User life cycle in Perun
WARNING: This part of the documentation is not complete yet.
First steps
If a user wants to become a member of the Perun ecosystem, he/she must be invited to one of the Virtual Organizations (VO) by means of an application.
The user fill-in the application, sends it and waits for the next information (or it's accepted automatically). The VO manager evaluates whether the application is filled correctly
and the user meets the conditions for membership in his VO. The VO manager may accept or reject the application.
If the application is rejected, the user gets a notification about the condition.
If the application is approved, the user is subsequently notified that he has become a member of the VO and can use their resources (for example access to the service).
Automatically accepted application
The application can be automatically approved if is set to Approval style to automatic ( in VO / Application form / Settings).
Subsequently, applications can be accepted automatically if all values in the application are syntactically correct.
Life cycle in VO
As soon as the user is registered in VO, his life cycle begins. Also included in this cycle are membership statuses in the VO. These can be set manually or automatically.
Once the application is approved, the member status is INVALID.
This is the initial state of the user attributes checking process. In the case of incorrectly set attributes, the status remains invalid.
If the user's initial status "invalid" remains, the attributes must be checked. Once the attributes have been set correctly,
the user can be switched to the "valid" state, which must be done manually by the manager.
An example of such an attribute may be a login for a particular namespace that the service may require. If the user doesn't own this attribute, he/she must create it.
If the checked attributes are OK, the user comes into the VALID (ACTIVE) state. In this state, the user is an active VO member and can access the services.
If the VO has set membership expiration for a limited time, it is necessary to request a renewal of the membership subscription periodically once in a while.
Otherwise, the user is automatically switched to EXPIRED (INACTIVE). If the VO doesn't have such rules, the VO member can get into this state at the manual intervention of the VO manager.
If membership expires, the user's status will switch to EXPIRED. In such a state, the user can use only some selected services, but his attributes are constantly controlled.
Not every expired user has to be interested after some time to renew membership. Such users can enter a terminal state called DISABLED.
The user still exists in the VO and it isn't possible to access to the services. Attributes are no longer checked.
The user in this state may request a renewal of the membership through the application and he/she will switch to a valid status upon approval of his application.
If the user is synchronized from an external source, then the user's status may be switched to a valid state.
The last part of the life cycle is the deletion of all user data in the VO context. The user and his data don't exist in VO anymore.
Information status
In connection with these conditions, there is a SUSPENDED or BAN information status that tells about the user that a security incident has occurred and it is up to the service itself to block this user or not.
Example of life cycle in VO
The process of a user's life in VO can look something like this:
The user must first apply for membership in the VO.
If his membership application is approved, the user receives the initial status INVALID.
1) After the attributes are set correctly and checked, the user's status changes to VALID.
2) In this state, he/she is an active VO member and has access to services.
3) In the event that the VO is set to the expiration date and the user doesn't extend the membership, the user's status switches to EXPIRED after the expiry date.
4) In this state, the user's data is still being sent to the service, but the service administrator must decide if he/she wants to give access to the user into his service in that state.
5) However, an expired user may apply for an extension of membership and become valid for access to service.
6) If the user isn't interested in renewing membership, he/she may be manually or automatically (after some time) switched to DISABLED. This is the terminal status of the user within the VO membership.
7) In this state, the system behaves to the user as if he/she wasn't in the VO. If the user re-submits the application to VO, VALID status is restored.
8) In this state, all user data regarding his membership in the VO is removed.
9) However, if he/she would be interested in becoming a member again, he/she must apply for membership again and his life cycle in the VO will start again from the INVALID state.
Expiration in VO
Information about expiration in VO is here.
Life cycle in groups and subgroups
Existence only in the VO is insufficient for the quality management of users and their access to services.
For this reason, users are sorted into groups and possibly subgroups. Groups are tied to the services that users need to use.
Even in groups or subgroups, users go through different states, namely: VALID (ACTIVE), EXPIRED (INACTIVE).
In this state attributes are OK and the user is an active group member and he/she can access the services.
If the group has set membership expiration for a limited time, it is necessary to request a renewal of the membership subscription periodically once in a while.
Otherwise, the user is automatically switched to EXPIRED (INACTIVE). If the group doesn't have such rules, the group member can get into this state at the manual intervention of the group manager.
If membership expires, the user's status will switch to EXPIRED. In such a state, the user can use only some selected services, but his attributes are constantly controlled.
These states can arise from automatic processes or can be manually set by the group manager.
The status of the user in the group respects the status in the VO, which means that under normal conditions the status in the VO is superior to the status of the group,
the status in the group is superior to the status in the subgroup, and so on.
Group members
In each VO there is a special group called members. All VO members are automatically collected in this group. Group property is similar to that of authoritative groups.
The manager can set any other group as authoritative, which means that if a user's membership in that group expires, it also expires in the VO.
This process takes place only in case of automatic synchronization.
Synchronization in groups and subgroups
The life cycle also supports synchronization to groups (or subgroups). Users can be synchronized from external sources such as LDAP, SQL database, or CSV files.
In this way, the user becomes a member of the group and at the same time becomes an indirect member of the VO, and therefore expiration in the VO (when the VO expiration is set) is not applied to avoid inconsistency.
However, a synchronized user may expire within a group if he/she stops syncing to the group.
Expiration in groups and subgroups
Information about expiration in groups and subgroups is here.
Life cycle schema
The user membership schema could look like this:
