Representations
Introduction
A representation is a established one-way trust between two users. The representation can be initiated a user and will go through a configured workflow. In most cases, this is a double-opt-in workflow. In that case, the initiator will provide the e-mail address of the other user, who will receive an invitation by email. Once he checks the invitation, he will be presented with the personal data of the initiator and will be asked to submit his personal data back to the him. The initiator will then be notified and presented with the personal date of the other user, to make sure he invited the correct person. After accepting, the representation is established.
My Representations
As mentioned, this representation is a one-way trust. So if one user invites another user and successfully goes through that process, he is now able to delegate permissions to that other user.
My Representatives
On the other hand, the user on the other side of the trust only receives the right to accept permission. If he would like to delegate permissions back to the other user, he himself has to establish a representation with the other user in the same fashion.
States and actions
The representation can have multiple states. By performing actions on the presentation, the state can be changed. Each state will be stored as a state change and displayed to the user in the user interface. The following states are available:
State | Description |
---|---|
| The representation is active. |
| The invitation has been created, the workflow was started but the decision is still open. |
| The representation was deactivated manually. |
| The representation is deleted and no longer active or in use. |
| The invitation was was not accepted and the timeout was reached. |
| The representation was suspended automatically. |
| The invitation was not accepted. |
Delegations
Once you have established a representation you can delegate permission to those people. The delegation always consists of a service and a specific permission of that service. Also the delegation has to go through a workflow and in most cases, this is the described double-opt-in workflow. Here the first user will delegate the permission and the second user will have to accept the invitation and choose, in what relation he wants to accept the delegation. He can do so in the private context or as a representative of an organization. The invitee has then to reconfirm the invitation.
States and actions
The delegation can have multiple states. By performing actions on the delegation, the state can be changed. Each state will be stored as a state change and displayed to the user in the user interface. The following states are available:
State | Description |
---|---|
| The delegation is active. |
| The delegation has been created, the workflow was started but the decision is still open. |
| The delegation was deactivated manually. |
| The delegation is deleted and no longer active or in use. |
| The delegation was was not accepted and the timeout was reached. |
| The delegation was suspended automatically, for example if the representation was deactivated. |
| The invitation was not accepted. |
Service deletion
If a user deletes a service and there are still delegations in the system for this specific service, the following state changes will be automatically performed.
State before | State after | Description |
---|---|---|
|
| If there were active delegations, the delegations will be deactivated. Once the user will reuse the service, he will be informed that there are deactivated delegations that he can check manually. Because he has to check them manually by design, the state does not change to suspended. |
|
| If there was an open invitation, the invitation will automatically set to the state deleted. |
© ITSENSE AG. Alle Rechte vorbehalten. ITSENSE und CoreOne sind eingetragene Marken der ITSENSE AG.