Hi,
I think the access control model needs to be flexible so that you can
define actions (operations) and attach them to roles as you wish {assuming
RBAC}. In that case, Admin is yet another role. Identifying potential
admin-level operations is fine but I think you get my point.
Danushka
On Wed, Jun 25, 2014 at 2:13 AM, Eroma Abeysinghe <
[email protected]> wrote:
> Hello Devs,
>
> Hello,
>
> Summarizing the offline discussion had with Saminda on Admin module of
> Airavata.
> *Open for discussion*
> Devs, please add anything i have missed out and we need to decide what we
> are going to add into the gateway admin API and provide UIs in PHP
> reference gateway in phase I (by the time for XSEDE).
>
> In Airavata there are two Admin levels;
> Airavata admin level & Gateway Admin level.
>
> Airavata admin level (user) being the highest level; should be able to
> create ;
>
> 1. Gateways in Airavata
> 2. Gateway admin users in Airavata
>
> for Airavata admin IMO we don't need to provide any UI but providing an
> API would be sufficient.
>
> For Gateway Admin users;
>
> 1. Create & maintain gateway users and user roles (e.g. Airavata
> admin, Gateway admin, standard user, etc...)
> 2. Create & manage resources
> 3. Create & manage resource level credentials
> 4. Create and manage projects
> 5. Create and manage applications (app catalog) - Assumption: App
> catalog is managed and records created at gateway admin level.
> 6. View all experiments in the gateway and their current statuses.
> Admin user should also be able to terminate/cancel experiments (manage
> experiments) created by other users.
> 7. View audit logs and other logs related to experiment executions
> 8. Statistical report generations - on experiments, users, projects,
> resources, applications,etc....
>
>
> --
> Thank You,
> Best Regards,
> Eroma
>
