RODA Temporary Access Accounts

[luis100]

Introduce an access integration method for external platforms that allows application users (with master accounts) to create temporary access accounts subordinate to their account. These accounts will have limited access to specific functionality and content, providing a secure and controlled solution for sharing resources.

US01 - Creating subordinate user accounts

As the main user
I want to create a subordinate account via REST-API
so that you can share specific resources with a guest user

Acceptance criteria:

• Application users should be able to create child accounts via RODA's REST-API.
• The subordinate account must be restricted to only the features and content that the parent account has access to.
• The subordinate account can be configured to have more restricted permissions (roles) than the parent account.
• The subordinate account can be configured to access only a subset of objects that the parent account has access to (AIP, DIPs), thus restricting the scope of the subordinate account.
• Actions performed by the subordinate account must be stored in the audit log, including the identification of the associated parent account.
• After creating the subordinate account, RODA must start the subordinate account preparation plugin (see US03)
• The REST-API response must contain the identifier of the created user, its expiration date and the one-time access token (see US04).

Complexity: High

US02 - Expiration date for access permissions to an AIP

As the main user
I want to set an expiration date for access permissions to an AIP
so that access is automatically revoked after the defined period

Acceptance criteria:

• Access permissions can have an expiration date, configurable up to a maximum limit defined by the system (e.g., 5 minutes, 24 hours or 30 days).
• When requesting new access using the integration, the expiration date will be extended according to the defined time limit (e.g. 5 minutes, 24 hours or 30 days).
• After expiration, RODA cannot allow access in search and navigation
• Expiration date information should be stored in the user database (OpenLDAP) and in the Members collection
• In the permissions management graphical interface, you should be presented with the option to (re)define an expiration date for each permission.

Complexity: High

US03 - Subordinate Account Preparation Plugin

As the main user
I want to run a permission update plugin
so you can ensure that subordinate user accounts have access only to authorized objects within the defined scope.

Acceptance criteria:

• A new plugin should be developed to update permissions of subordinate user account objects.
• The plugin must add the list of allowed objects to the subordinate account.
• After updating the objects with the appropriate permissions, the plugin should update the subordinate account with the objects that are ready for access.
• The information about the list of allowed objects must be in the user database (OpenLDAP) and in the Members collection
• If an error occurs during the update, the plugin should record the subordinate account as the error information, so that the guest user can understand the problem.

Complexity: Medium

US04 - Support for authentication via one-time-token (OTT)

As a guest user (subordinate account)
I want to authenticate using a one-time access token
so you can securely and easily access shared resources

Acceptance criteria:

• RODA login flow must allow one-time token (OTT) to authenticate system accounts.
• The OTT must be consumed after its first access, not allowing a second authentication with the same token.
• OTT should automatically expire after a set period
• It should be possible to identify an authentication with OTT in the audit log.
• The REST-API should allow you to obtain an access token through OTT to allow subsequent calls.

References:
https://docs.spring.io/spring-security/reference/servlet/authentication/onetimetoken.html#customize-generate-consume-token

Complexity: High