OX Cloud Provisioning Introduction
OX Cloud Provisioning Use-Cases And Concepts
Provisioning means creating, changing and deleting "informations" on OX Cloud. This is primarily done via a SOAP interface.
There are many ways to review and explain provisioning on a Cloud system. Technically, commercially, user view, admin view, based on the APIs or the UIs.
The idea of this document is to combine them and give the right hints to the respective documentation especially to the "hands on" sections. You will find some colored boxes on the right side, that give some additional hints.
HandsOn
Gives you a link to the technical documentation with code examples and more technical details. Like the one below directly guides you to the technical documentation
UI Remark
Gives you small hints in regards to UI development
API Remark
Gives you small warnings about things you need to keep in mind, when developing against the APIs
If you want to jump to a specific topic, the list below might help you. Otherwise the document should guide you through the necessary steps to successfully provision and manage users on OX Cloud.
OX Cloud was built to host and manage multi-million mailboxes. The beauty is, that those can be provisioned and managed from different sources. This is possible, because we have different administration levels, which give us the flexibility to allow that kind of operations.
Create a context
Creating a context requires to create the first user in that context, which is the Context admin.
The Context admin is like an ordinary OX Cloud user, except that it can add, remove and edit users and groups within OX Cloud using the provisioning API. In addition, it inherits shared data of users, that are deleted. In OX Cloud, however, the Context admin cannot read, send or receive mail.
This means, that in practice this user actually only “lives” in the tool you are creating for this. The interactions take place in OX Cloud, but can only be initiated from the UIs you provide to your customers.
This results in this list of mandatory settings to create a context:
- context-name [name of the Context]
- name [login name of the Context admin]
- password [password of the Context admin]
- email [email address of the Context admin (remember there is not a real mailbox, but the API requires that attribute still. Thus something like admin@inval.id is sufficient. Important: do NOT use an email address which might be used for a regular user because email addresses have to be unique.)]
- displayname [displayname (usually first name last name)]
- first name
- last name
- mail-quota [Quota for Mail in MB]
- file-quota [Quota for Files in MB]
While these two are optional, but still often used to change the default directly:
- lang [language, e.g. en_GB, en_US, de_DE, ...]
- timezone [Java timezone such as Europe/Berlin]
For certain situations it might be helpful to create “two” accounts for the Context admin:
- The “technical” Context Admin → That is needed for CRUD operations in the Context.
- The “normal” user the Admin could also be → That can send and receive mails in a Context. See “Create Users” section below.
HandsOn
Find examples for Context creation here:
UI Remark
Quota is usually defined by the package you offer to your customers and thus is not necessarily as input for which you would require a separate UI field.
The same is true for the Context admin email address.
API Remark
Due to the architecture of OX Cloud, a login/username must be unique across all created contexts. That means it is not possible to create two "oxadmin" accounts.
The typical solution is to use email addresses as usernames which makes sure those are unique by definition.
UI Remark
Depending on other user flows and UI elements, the admin information could be pre-filled or not necessary at all. Otherwise the admin administration and the normal user administration should be rather identical and should contain following information:
UI Remark
Depending on how your customers will use your provisioning tool, the “normal” user account might be needed or irritating. Both views are valid depending on the use case.
In doubt, you could also add a checkbox field and only create the “normal” mailbox on request.
Create Users
Create “normal” users requires a similar set of parameters and settings like for the Context admin. But we will see a new elements, which will be explained below: The Module Access Name (moduleaccess).
Additionally we will have to clarify, how to use domains within the mail addresses.
Here is the list of settings:
- context-name [name of the Context]
- context-ID [Numerical ID of the Context]
- name [login name of the Context admin]
- password [password of the Context admin]
- email [email address of the “normal” user]
- displayname [displayname (usually first name last name)]
- first name
- last name
- mail-quota [Quota for Mail in MB]
- file-quota [Quota for Files in MB]
- moduleaccess [defines the package / functionalities the user can use]
- class of service [part of the package definition like moduleaccess]
While these two are still optional, it might be worth changing the default directly:
- lang [language, e.g. en_GB, en_US, de_DE, ...]
- timezone [Java timezone such as Europe/Berlin]
Next stop moduleaccess
UI Remark
Is and Administrator taking care of entering the End-User information or do you want to provide a Self-Service portal? Do you want to allow bulk or CSV uploads?
Most of the time a simple and clean user list is sufficient, as e.g. here:
UI Remark
As mentioned are language and timezone optional. You could use the account information or allow individual settings. The user will be still able to change the settings within AppSuite, so this is a convenience feature only.
