Purpose: While the EAASI platform does not strictly dictate that it must be deployed this way, it is taken as a given that the primary direction of EAASI development and maintenance will assume a “hosted” service implementation, wherein a single EAASI deployment is managed on behalf of, and accessed by, multiple real-world institutions via the use of Organizations. The Deployment Administrator, with ultimate oversight over user management and related, account- and Organization-dependent usage within the full deployment, must then have granular control over the creation and definition of Organizations, including (but not limited to) the creation and designation of initial Organization Administrators for each and every new Organization.
When logged into the web UI of an EAASI deployment, the Deployment Administrator account should be able to:
- see a list of existing Organizations in the deployment
- create new Organizations in the deployment
- see a list of existing user accounts associated with any Organization
- add new users to any Organization
- edit user account roles within any Organization (e.g. set Organization Administrator vs. Configuration User role)
- reset passwords for any and all user accounts in the deployment
- import and manage emulators available in the deployment
Gap Analysis: Deployment Administrators can use their credentials and the eaas-orgctl Python script to complete actions 1-4 above. Though not documented nor encouraged due to untested/unpredictable behavior, they may also use their credentials to log in to the Keycloak module’s admin console (at https://<eaasi.domain>/auth/admin/master/console) and complete actions 1-7. They can complete actions 8 and 9 via the EAASI UI (see more below).
(Note: under current limitations, all Organization Administrator accounts are also able to complete actions 1-4 above via eaas-orgctl script or actions 1-7 via Keycloak module’s admin console, if they can guess/find the URL. They can also complete actions 8 and 9 via the EAASI UI, with their metadata sync or emulator import actions ultimately affecting all Organizations within the deployment, though via the EAASI UI their user management actions – adding and deleting users, editing user account roles, and resetting passwords – are limited to within their Organization.)
When the designated Deployment Administrator account logs in to the EAASI UI, they see all the same menus and options as Organization Administrators, but default/empty/”undefined” Organization and user-account info is displayed, as the Deployment Administrator account technically belongs to no Organization/group in Keycloak). Behavior on Explore Resources, My Resources, Emulation Project, and Import Resource pages is erratic, as workflows on those pages were intended for Organization Administrators, Configuration Users, and/or Access Users; Deployment Admin accounts are not really intended to directly create and manage resources. Under the “Manage Node” menu, “Node Management” tasks (Emulators, Endpoints/Metadata Sync, Running Task and Troubleshooting pages and their related features) appear and are functional (note: again, under current limitations, Organization Administrator accounts are also able to see/use all of these same features); “Node User Administration” tasks are empty and essentially non-functional, as these menus were designed for user management within a single Organization and the Deployment Administrator account belongs to no Organization.
Purpose: While the EAASI platform does not strictly dictate that it must be deployed this way, it is taken as a given that the primary direction of EAASI development and maintenance will assume a “hosted” service implementation, wherein a single EAASI deployment is managed on behalf of, and accessed by, multiple real-world institutions via the use of Organizations. The Deployment Administrator, with ultimate oversight over user management and related, account- and Organization-dependent usage within the full deployment, must then have granular control over the creation and definition of Organizations, including (but not limited to) the creation and designation of initial Organization Administrators for each and every new Organization.
When logged into the web UI of an EAASI deployment, the Deployment Administrator account should be able to:
Gap Analysis: Deployment Administrators can use their credentials and the eaas-orgctl Python script to complete actions 1-4 above. Though not documented nor encouraged due to untested/unpredictable behavior, they may also use their credentials to log in to the Keycloak module’s admin console (at https://<eaasi.domain>/auth/admin/master/console) and complete actions 1-7. They can complete actions 8 and 9 via the EAASI UI (see more below).
(Note: under current limitations, all Organization Administrator accounts are also able to complete actions 1-4 above via eaas-orgctl script or actions 1-7 via Keycloak module’s admin console, if they can guess/find the URL. They can also complete actions 8 and 9 via the EAASI UI, with their metadata sync or emulator import actions ultimately affecting all Organizations within the deployment, though via the EAASI UI their user management actions – adding and deleting users, editing user account roles, and resetting passwords – are limited to within their Organization.)
When the designated Deployment Administrator account logs in to the EAASI UI, they see all the same menus and options as Organization Administrators, but default/empty/”undefined” Organization and user-account info is displayed, as the Deployment Administrator account technically belongs to no Organization/group in Keycloak). Behavior on Explore Resources, My Resources, Emulation Project, and Import Resource pages is erratic, as workflows on those pages were intended for Organization Administrators, Configuration Users, and/or Access Users; Deployment Admin accounts are not really intended to directly create and manage resources. Under the “Manage Node” menu, “Node Management” tasks (Emulators, Endpoints/Metadata Sync, Running Task and Troubleshooting pages and their related features) appear and are functional (note: again, under current limitations, Organization Administrator accounts are also able to see/use all of these same features); “Node User Administration” tasks are empty and essentially non-functional, as these menus were designed for user management within a single Organization and the Deployment Administrator account belongs to no Organization.