The objective of this document is to provide functional and non-functional requirements for OSDU Admin UI development team to develop a front-end project for accessing existing API which are currently invoked by Postman. This solution will ease up a lot of admin tasks with the intended UI.<br/>
<h4>1.2 Project Background</h4>
Various parts of OSDU have functions with a need for an OSDU admin person to make changes to the settings. However, at this moment these changes have to be made in different parts of OSDU and that really is not ok for an R3 Production release. For this reason, this request for an OSDU Forum Member Company to drive the development of an Admin functions within OSDU R3.<br/>
<h4>1.3 Project Objectives and Scope</h4>
<h5>1.3.1 Objective</h5>
The objective of this project is to make the day to day work of an admin simpler by providing a UI for admin tasks. Currently these tasks are performed via Postman by invoking individual APIs.<br/>
<h5>1.3.2 In-scope</h5>
1. Admin UI needs to be created for following modules of OSDU<br/>
i. Information Security.<br/>
ii. Data Platform.<br/>
iii. Data Ingestion.<br/>
vi. Data Loading<br/>
vii. System Configuration<br/>
2. All Admin functions will be accessible via a single Admin UI function under OSDU:<br/>
3. Admin UI project to be developed in fully Open Source platform preferably in Angular 9<br/>
Discussions with various Module Owners and CSP is in progress and below requirements are getting updated on a regular basis.<br/>
<h5>1.3.3 Out of scope</h5>
• Development or modification of any API or backend code<br/><br/>
<h2>2. Detailed Business Requirements - Functional</h2>
Below are the point of contacts driving the requirements for Admin UI Project:
<table><thead><th>Modules</th><th>Point of Contact</th><th>Initial Business Requirements Discussion</th><th>User Stories Received</th><th>API Availability</th><th>Prototype Screens Developed</th><th>Access to API</th><thead><tbody><tr><td>Information Security</td><td>Paco Hope</td><td>Completed</td><td>Completed</td><td>Yes</td><td>In Progress</td><td>No</td></tr><tr><td>Data Platform</td><td>Philip Jong & Stephen Whitley</td><td>Completed</td><td>In Progress</td><td>To be Identified</td><td>To be Created</td><td>No</td></tr><tr><td>Data Ingestion</td><td>Stephen Whitely</td><td>Completed</td><td>To be Identified</td><td>To be Identified</td><td>To be Created</td><td>No</td></tr><tr><td>E&O</td><td>Hrvoje Markovic</td><td>Completed</td><td>In Progress</td><td>Yes</td><td>Yes</td><td>No</td></tr><tr><td>Audit and Metrics</td><td>Nidhi Fotedar</td><td>Open</td><td>To be Identified</td><td>To be Identified</td><td>To be Created</td><td>No</td></tr><tr><td>Data Loading</td><td>Michael Haven</td><td>In Progress</td><td>To be Identified</td><td>To be Identified</td><td>To be Created</td><td>No</td></tr><tr><td>System Configuration</td><td>Raj Kannan</td><td>In Progress</td><td>To be Identified</td><td>To be Identified</td><td>To be Created</td><td>No</td></tr></tbody></table>
<h4>a. Login Screen</h4>
<ul><li>Initially Philip had provided requirements for a login and register screens. However, after discussions with Paco and Philip individually, it was decided that login screens should not be created for Admin UI</li><li>Authentication and authorization will happen using the IDP and E&O APIs</li><li>Access to OSDU Admin UI tool will be through bearer token generated through the IDP where the OSDU data platform is deployed</li><li>Admin UI Portal will have unique URL’s depending on which instance it has been hosted on. </li><li>Login and Registration is not part of Admin UI Development. It will be taken care by Organisations in their own IDP.</li><li><b>Question asked by Johan - Where do you refer to Roles based access? Since it needs to be Roles based + then only selective access to approved features.</b><br/>
-- As per our discussion with Hrvoje on Entitilements & Obligation module, the role based access will be taken care in E & O user group section and each individual API will take care of the user validation internally. </li></ul>
<h4>b. Landing page (Home page)</h4>
After Successful authentication from the respective IDP, user will be redirected to the Landing page (Home page).<br/>This home page will list below modules:<br/>
o Entitlement and Obligation <br/>
o Data Ingestion<br/>
o Information Security<br/>
o Data Loading<br/>
o Data Platform<br/>
o Audit and metrics<br/>
o System Configuration.
<h4>c. Entitlement and obligation (E&O) Module</h4>
Entitlements service is used to enable authorization in Data Ecosystem. The service allows for the creation and user mapping for groups. A group name defines a permission. Users who are added to that group obtain that permission. The main motivation for entitlements service is data authorization but the functionality enables three use cases:<br/>
<ol><li>Data groups used for data authorization e.g. data.welldb.viewer, data.welldb.owner</li><li>Service groups used for service authorization e.g. service.storage.user, service.storage.admin </li><li>User groups used for hierarchical grouping of user and service identities e.g. users.datalake.viewers, users.datalake.</li></ol>
<p>For each group a user can either have an OWNER role or a MEMBER role. The only difference being an OWNER of a group is that you can manage the members of respective group.</p>
<p>In Entitlement and obligation page users will have 2 sections Manage Users and Manage Groups. Depending on the visitor’s access level few functionalities like deletion, creation and editing will be enables or disabled. The groups and user mapping will be done via Entitlements Module where the group owner will have access to edit the group permissions for the users. Only the owner of the group can create a user or give permission to use it. </p>
<p>Under E & O Manage Users section we are managing role and permission for a particular member.</p>
<table> <thead> <tr> <th></th> <th></th> <th colspan="4">Dev Rest End Point (URL/Not Available)</th> </tr> <tr> <th>API Name</th> <th>API Purpose</th> <th>AWS</th> <TH>Azure</TH> <th>Google</th> <th>IBM</th> </tr> </thead> <tbody> <tr> <td>GET /entitlements/v1/groups</td> <td>Gives list of the groups that user belongs to</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> </tr> <tr> <td>POST /entitlements/v1/groups</td> <td>Creates the group within the data partition with following email {name}@{data-partition-id}.{domain}.com</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> </tr> <tr> <td>GET /entitlements/v1/groups/{group_email}/members</td> <td>Retrieves members that belong to a group.</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> </tr> <tr> <td>POST /entitlements/v1/groups/{group_email}/members</td> <td>Add members to a group.</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> </tr> <tr> <td>POST /entitlements/v1/groups/data/{group_email}/members</td> <td>Add user group of a primary partition to a data group of a vendor partition.</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> </tr> <tr> <td>DELETE /entitlements/v1/groups/{group_email}/members</td> <td>Delete members from a group within the data partition provided.</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> <td>Not Available</td> </tr> </tbody> </table>
<h4>d. Data Ingestion</h4>
Yet to receive inputs. <br/>
<p> Data Ingestion and Data Loading is a process of getting data into the system. </p>
<table><thead><tr><th></th><th></th><thcolspan="4">Dev Rest End Point (URL/Not Available)</th></tr><tr><th>API Name</th><th>API Purpose</th><th>AWS</th><TH>Azure</TH><th>Google</th><th>IBM</th></tr></thead><tbody><tr><td>Not Available</td><td>Not Available</td><td>Not Available</td><td>Not Available</td><td>Not Available</td><td>Not Available</td></tr><tr><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>
<h4>e. Data Loading</h4>
No user stories received during initial discussions. Follow up calls planned. <br/>
<p>As per our discussion with Michael, in data loading access is limited and user account should be able to locate master data, prod data, etc based on their type and permission.</p>
<p>There are three types of users: </p>
<ol>
<li>User who can do everything.</li><li>User who can only upload prototype.</li><li>User who can only upload master data.</li></ol>
<p>But owner can manage all data.</p>
<table><thead><tr><th></th><th></th><thcolspan="4">Dev Rest End Point (URL/Not Available)</th></tr><tr><th>API Name</th><th>API Purpose</th><th>AWS</th><TH>Azure</TH><th>Google</th><th>IBM</th></tr></thead><tbody><tr><td>Not Available</td><td>Not Available</td><td>Not Available</td><td>Not Available</td><td>Not Available</td><td>Not Available</td></tr><tr><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>
<h4>f. Data Platform</h4>
User stories discussions are in progress. Discussed on requirements to include legal tags update, follow up calls planned.
<table><thead><tr><th></th><th></th><thcolspan="4">Dev Rest End Point (URL/Not Available)</th></tr><tr><th>API Name</th><th>API Purpose</th><th>AWS</th><TH>Azure</TH><th>Google</th><th>IBM</th></tr></thead><tbody><tr><td>Get All Well</td><td>To get list of all wells and it’s details which user has access to</td><td>https://389u8yyazd.execute-api.us-east-1.amazonaws.com/api/search/v2/query/</td><td>Not Available</td><td>Not Available</td><td>Not Available</td></tr><tr><td></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>
<h4>g. Information Security</h4>
Below are some of the user stories captured as part of login and initial admin tasks:
<ul><li>System Administrator</li><li><ul><li>User should be able to login as a system administrator Check for the roles will be done by E&O roles/groups API</li><li>User should be able to configure the OSDU user authentication system to use my company’s IDP. As part of initial setup, an IDP will be configured for authentication of Admin App</li><li>User should be able to set up the authentication system for Single Sign On for users – This will be during initial setup itself</li><li>User should be able to assign roles of the OSDU users – E&O APIs will be called for these operations</li></ul></li><li>System Administrator (roles assignments, system configurations)</li><li><ul><li>System Operator (system monitoring, reporting, dashboarding, etc) – To be discussed and reviewed with what all APIs are available</li><li>Data Manager (Data Loading, ingestion, E&O policy management) To be discussed and reviewed with what all APIs are available</li></ul></li><li>Users (login)</li><li><ul><li>User should be able to configure access to the external data sources (EDS) As part of initial setup, an IDP will be configured for authentication of Admin App</li><li>User should be able to configure the system behaviours (e.g., the visibility of metadata if the actual data is protected) As long as the APIs are available to update the system behaviours, this should be possible</li></ul></li><li>System Operator (Comments as above)</li><li><ul><li>User should be able to login as a system operator</li><li>User should be able to able to run all system audit and operation reporting services</li><li>User should be able to configure the system dashboard</li><li>User should be able to run the system reporting services and create the dashboard</li></ul></li><li>Data Manager (Comments as above)</li><li><ul><li>User should be able to load and ingest data with manifests</li><li>User should be able to load and ingest data without manifests</li><li>User should be able to load and ingest master data</li><li>User should be able to load and ingest reference data</li><li>User should be able to load and ingest quality rules</li><li>User should be able to see a list of all currently-running ingestion jobs with their current status</li><li>User should be able to see a history of recent (for some definition of recent) ingestion jobs, with their status (and maybe size, number of objects, error log, etc.)</li><li>User should be able to kill/cancel a currently-running ingestion job</li></ul></li><li>End Users (Comments as above)</li><li><ul><li>User should be able to login as an end user</li><li>User should be able to search for availability of data</li><li>User should be able to access the application and service catalog of the Marketing Site</li><li>User should be able to purchase the application or service</li><li>Once I purchase the application or service, they will appear on the application of service pages</li><li>User should be able to execute an application or service which I purchase</li><li>User should be able to list all purchased data sets</li></ul></li></ul>
<h4>h. Audit and Metrics (system monitoring)</h4>
To be updated <br/>
<p>All the traceability and individual diagnostics regarding the CRUD activity happening in Data Platform will be available in this module. </p>
<table><thead><tr><th></th><th></th><thcolspan="4">Dev Rest End Point (URL/Not Available)</th></tr><tr><th>API Name</th><th>API Purpose</th><th>AWS</th><TH>Azure</TH><th>Google</th><th>IBM</th></tr></thead><tbody><tr><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>
<h2>3. Design & Development Approach</h2>
Below is the high-level understanding based on various discussions with stakeholders till now.<br/>
1. As part of the Admin UI project, only the front end (GUI) will be developed. All APIS will be provided along with details of authentication & Authorization servers to access these APIs using right authentication (bearer) tokens. There would not be any login or register screen that will be developed as part of Admin UI Project.<br/>
2. Below is a representation of how the overall flow of authentication and API access will work <br/>
a. OSDU Admin UI App – The frontend application development in development scope. This is planned to be developed in Angular 9. Anything other than this block in the below diagram is assumed to be shared to development team.<br/>
b. OSDU Instance Identity Provider – This is the Identity provider which will be used for authentication. The details of the IDP will need to be shared with the development team for initial configuration<br/>
c. User Identity is the User email and authorization token which will be passed as header information for invoking any <br/>
d. OSDU Platform API Management – It is the cloud specific API Management Gateway which will provide REST endpoints to Admin UI Apps. This will internally get data from “OSDU Data Platform” by internally validating user authorization (entitlements)<br/>
4. During the initial setup of OSDU instance, a super user is added to various groups. This superuser will be responsible for configuring the groups access to various other users using Admin UI Application. The entitlements API’s will be used to manage users and groups mapping <br/>
5. Below is a prototype screen of how the initial landing page will look like: <br/><br/>
Below is a prototype screen of how the E&O manage users/groups page will look like: <br/><br/>
<ul><li>User with Owner role will be able to add a member and delete a member from his group</li><li>Owner can also decide the permission of member that is going to be added in that group</li><li>All the logged in users irrespective of their role will be able to view the members of their group</li><li>Search functionality is also provided to users to ease their work</li></ul>
<b>7. Manage Groups </b><br/>
Below is a prototype screen of how the E&O manage groups page will look like:<br/><br/>
<ul><li>User with Owner role and Admin or Creator permission will be able to create a group and can also delete a group</li><li>User with Owner role and Viewer permission can only view the list of groups and member inside a group</li><li>Search functionality is also provided to users to easily search a group or user</li></ul>
<h2>4. Admin Application Deployment Approach</h2>
<p>Deployment approach is yet to be finalized. A few options discussed are as below:</p>
<p>This section defines the assumptions made for the user acceptance process</p>
<ol><li>The project assumes only UI (frontend development). All API’s are to be provided by the individual module owners</li><li>Instance specific IDP will be used for authentication and all APIs are expected to validate the roles and access before returning the results</li><li>This project will not update or create any new API’s or any backend code</li><li>End deliverable for this project is going to be Angular 9 code which can be deployed to any CSPs</li><li><b>Question asked by Johan - Audit trail needs to be available for all key entries.</b> (Need to discuss further on this.)</li></ol>
<h2>6. Glossary</h2>
<p>The glossary provides definitions of all the key business terms used in this document.</p>
<p>Below are key risks and issues specific to the Admin UI Project:</p>
a. Unavailability of pre-flight environment – A development environment is yet to be provided to the development team (23 Nov 2020)<br/>
b. As per discussions till now, there are several APIs required for Admin UI project which are either in development or not yet developed now. This unavailability of APIs may delay Admin UI development significantly
<h2>8. Asks and Open Items</h2>
<table> <thead> <th>Questions</th> <th>Point of Contact</th> <th>Status</th> </thead> <tbody> <tr> <td>As per the discussion so far there are 7 different modules to be developed. Need to confirm with OSDU team if these are the final no of modules.</td> <td>Stephen Whitley</td> <td>Open</td> </tr> <tr> <td rowspan="4">Need Read and Write access to preflight environment and endpoint for all 4 cloud platforms</td> <td>GCP - Ferris(fargyle@google.com) </td> <td>Open</td> </tr> <tr> <td>IBM - Wlad(wsfrazao@us.ibm.com)-IBM</td> <td>Open</td> </tr> <tr> <td>AWS - Paco(pacohope@amazon.com)</td> <td>Open</td> </tr> <tr> <td>Azure – Hrvoje Markovic(HMarkovic@slb.com)</td> <td>Open</td> </tr> <tr> <td>In Entitlement API’s is the data pattern going to be different for different IDP’s?</td> <td>Hrvoje Markovic</td> <td>Open</td> </tr> <tr> <td>In Admin UI home page do we have to show all the modules irrespective of user’s role and permission, or do we get API which will provide us the list of modules that the user has access to?</td> <td>Stephen Whitley</td> <td>Open</td> </tr> <tr> <td>What will be the data partition id for different API’s ?</td> <td>Stephen Whitley</td> <td>Open</td> </tr> <tr> <td>Request for a bootcamp session for various cloud providers like Google, Azure and IBM.</td> <td>Stephen Whitley</td> <td>Open</td> </tr> </tbody> </table>
<h2>9. Appendix</h2>
<p>Below are the resources shared by various module owners as part of initial discussion:</p>
<table><thead><th>Title</th><th>Link</th></thead><tbody><tr><td>Gitlab Directory for Admin UI</td><td>https://community.opengroup.org/osdu/ui/admin-ui</td></tr><tr><tdrowspan="2">API Postman Collection</td><td>https://community.opengroup.org/osdu/platform/testing/-/tree/master/Postman%20Collection</td></tr><tr><td>https://community.opengroup.org/osdu/platform/testing/-/tree/master/Postman%20Collection/00_CICD_Setup_Environment</td></tr><tr><td>Slack</td><td>https://opensdu.slack.com/</td></tr><tr><td>Gitlab</td><td>https://gitlab.opengroup.org/</td></tr><tr><td>Information security home page</td><td>https://gitlab.opengroup.org/osdu/subcommittees/info-sec/home</td></tr><tr><td>Details on OSDU Bootcamp</td><td>https://osduonaws.splashthat.com/</td></tr><tr><td>Admin UI gitlab Use Cases WIKI</td><td>https://gitlab.opengroup.org/osdu/subcommittees/info-sec/projects/dev-sec/home/-/wikis/AdminUIUseCases</td></tr><tr><td>R2 Documentation repository</td><td>https://community.opengroup.org/osdu/documentation/-/wikis/Releases/R2.0/</td></tr><tr><td>R3 E&O design</td><td>https://community.opengroup.org/osdu/platform/security-and-compliance/home/-/wikis/Design</td></tr><tr><tdrowspan="10">Other Important Links</td><td>https://community.opengroup.org/osdu/platform</td></tr><tr><td>https://community.opengroup.org/osdu/platform/security-and-compliance/legal</td></tr><tr><td>https://community.opengroup.org/osdu/platform/security-and-compliance</td></tr><tr><td>https://community.opengroup.org/osdu/governance/project-management-committee</td></tr><tr><td>https://community.opengroup.org/osdu/documentation/-/wikis/Releases/R2.0/Services/Entitlements/Tutorial</td></tr><tr><td>https://community.opengroup.org/osdu/platform/security-and-compliance/legal/-/blob/master/docs/tutorial/ComplianceService.md</td></tr><tr><td>https://collaboration.opengroup.org/forums/og_sdu/webex8/events.php?action=show&bpid=849&evt=aWNhbDo6NWY5ODQ2MDAxYzYyZDoxNjA1NjIzNDAw&_ga=2.204553680.1553274778.1605705956-40047507.1557602412</td> </tr> <tr> <td>https://www.opengroup.org/og_sduaggregatedcalendar</td></tr><tr><td>https://gitlab.opengroup.org/osdu/subcommittees/info-sec/projects/data-sec-en-ob/home/-/wikis/home</td></tr></tbody></table>
\ No newline at end of file
| This project is to develop an admin UI for existing OSDU APIs | |
1.1 [Purpose of this document](https://community.opengroup.org/osdu/ui/admin-ui/-/wikis/OSDU-Admin-UI-Project-Introduction#11-purpose-of-this-document)<br/>
1.3 [Project Objectives and Scope](https://community.opengroup.org/osdu/ui/admin-ui/-/wikis/OSDU-Admin-UI-Project-Introduction#13-project-objectives-and-scope)<br/>
1.3.3. [Out of scope](https://community.opengroup.org/osdu/ui/admin-ui/-/wikis/OSDU-Admin-UI-Project-Introduction#133-out-of-scope)<br/>
2.[Detailed Business Requirements - Functional](https://community.opengroup.org/osdu/ui/admin-ui/-/wikis/OSDU-Admin-UI-Detailed-Business-Requirements-Functional)<br/>
3.[Design & Development Approach](https://community.opengroup.org/osdu/ui/admin-ui/-/wikis/OSDU-Admin-UI--Design-and-Development-Approach)<br/>
4.[User story and API mapping](https://community.opengroup.org/osdu/ui/admin-ui/-/wikis/OSDU-Admin-UI-User-story-and-API-mapping-availability)
