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)