Users

Introduction

Users can be bound to a customer account or not be related to any customer.

The user model is used in different APIs for different reasons:

IAM API handles user find, creation, update and destroy
User Controller
AUTH API handles login/logout, registering, inviting and resetting passwords

Users bound to customers

Usually, users created using AdmiralCloud WebApp with a authenticated customer will create users which are bound to that customer.

Administrators of that customer can see all user related data and administer the user (with the exception of a few fields).

These users cannot register to apps of other customers with the same e-mail address.

Users not linked to a customer

Users which register by themselves do not have a fixed customerId and their released timestamp will be automatically set. That means, these users can not be managed by a customer account (except for approval or securitygroups) but only by the user itself.

Administrators of customer accounts cannot manage the user and will only see a very limited set of user data (least privilege principle).

User data model and beviour in detail

Creation via client app

Users created using the client app will be

Bound to that customerId (field customerId is set)
Field origin will be the ac client app
Relation between ac client app and this user will be approved (user-app-relation flag 0)

If this user is deleted, the following will happen

The user has contributed data (uploaded media, change metadata, etc):

all user-app-relations are set to deleted (flag 99)
the user will be anonymized

The user has not contributed data

the user-app-relation will be deleted
the user will be deleted

Users created by external authentication services (e.g. ADFS/SAML)

Identical to users create using the client app.

User created by self-registration

User not bound to any customerId (field customerId is not set
Field origin contains the clientId of the app the user first registers for
Relation between app (the user registers for) and user will usually be set to flag 2 (approval pending)

If this user is approved for an app and then later this approval is deleted the following will happen:

the user-app-relation will be set to flag 99 (deleted) if the user has contributed data to that app or will be deleted if the user has never contributed data to that app
If the user has no more active user-app-relations the user will be anonymized (if the user has contributed data) or deleted.

If the user is rejected for an app, the following will happen:

If the app has markRejected = true, the relation between user and app is marked as rejected (flag 90). The user cannot register again for this app and will receive an error message when trying.
If the app has not set markRejected (or it is set to false) the user-app-relation is deleted (default setting)