You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@airavata.apache.org by "Eroma (JIRA)" <ji...@apache.org> on 2018/02/05 17:37:00 UTC

[jira] [Comment Edited] (AIRAVATA-2500) Automated cluster account provisioning for gateway users

    [ https://issues.apache.org/jira/browse/AIRAVATA-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345851#comment-16345851 ] 

Eroma edited comment on AIRAVATA-2500 at 2/5/18 5:36 PM:
---------------------------------------------------------

Tested in [dev.seagrid.org |https://dev.seagrid.org/]

Test Cases
 # A campus gateway user A uses CILogon and logs in to the gateway after getting an active role. His account in campus cluster is auto provisioned. Can view the details under 'User Settings' – PASS
 # A campus gateway user Q uses CILogon and logs in to the gateway desktop application after getting an active role. His account in campus cluster is auto provisioned. Can view the details under 'User Settings' -
 # Above user A submits a job using individual allocation. Used Mothur application -  PASS
 # Above user A clones and submits another job using individual allocation. - PASS
 # Above user A clones and submits another job using community allocation. - PASS
 # Above user Q submits a job through desktop application using individual allocation. Used Mothur application -  
 # Above user Q clones and submits another job through desktop application using individual allocation. -
 # Above user Q clones and submits another job through desktop application using community allocation. –
 # User Q create, launches (with LDAP account provisioning) and shares an experiment using desktop application with user R who has an individual allocation in the same cluster. User R clones the shared job and submits using his own allocation through desktop application. –
 # User A create, launches (with LDAP account provisioning) and shares an experiment with user B who has an individual allocation in the same cluster. User B clones the shared job and submits using his own allocation. – PASS
 # User A create, launches (with LDAP account provisioning) and shares an experiment with user B who has an individual allocation in the same cluster. User B clones the shared job and submits using his own allocation using the SEAGrid desktop application. –
 # User A create, launches (with LDAP account provisioning) and shares an experiment with user B who has an individual allocation in the same cluster. User B clones the shared job and submits using community allocation using the SEAGrid desktop application. -
 # User A create, launches (with LDAP account provisioning) and shares an experiment with user B who has an individual allocation in the same cluster. User B clones the shared job and submits using community allocation. - PASS
 # User A create, launches (with LDAP account provisioning) and shares an experiment with gateway user C (who is from same institute) who doesn't have an individual allocation in the same cluster. User C clones and submits using community allocation. - PASS
 # User A creates, launches (with LDAP account provisioning) and shares with user D who does not belong to the institute, has an account created manually in the gateway. User D will clone the experiment and submit with community allocation. User D is in gateway-user role. - PASS
 # User navigates to User settings -Since this cluster is auto provisioned enabled cannot change the auto added details – PASS
 # A campus gateway user D logs in by creating a gateway account and getting gateway-user role. Adds the auto provisioned cluster manually in User settings. - Can add the cluster but since it’s an auto provisioned cluster cannot do and editing, deleting once added. – PASS
 # Above user D launches an experiments using the manually added allocation. If the configuration was added correctly can use it. – PASS
 # Test deleting the credential store key for auto provisioning cluster in User settings àCredential store for a user using CILogon. – Cannot delete the key assigned to auto provisioning cluster, its read only - PASS
 # Test deleting the credential store key for auto provisioning cluster in User settings àCredential store for a user using locally created account. – Cannot delete a key assigned to auto provisioned or manual provisioned cluster, its read only – PASS

 

NOTE: SEAGrid desktop application testing on LDAP provisioned CILogon users still pending.


was (Author: eroma_a):
Tested in [dev.seagrid.org |https://dev.seagrid.org/]

Test Cases
 # A campus gateway user uses CILogon and logs in to the gateway after getting an active role. His account in campus cluster is auto provisioned. Can view the details under 'User Settings' - PASS
 # Above user submits a job using individual allocation. used Mothur application -  PASS
 # Above user clones and submits another job using individual allocation.
 # Above user clones and submits another job using community allocation.
 # User create, launches and shares an experiment with another gateway user who has an individual allocation in the same cluster.
 # User create, launches and shares an experiment with another gateway user who doesn't have an individual allocation in the same cluster.
 # User navigates to User settings --> Compute resource and tries to change the details in user preferences- Since this cluster is auto provisioned enabled cannot change the auto added details - PASS

> Automated cluster account provisioning for gateway users
> --------------------------------------------------------
>
>                 Key: AIRAVATA-2500
>                 URL: https://issues.apache.org/jira/browse/AIRAVATA-2500
>             Project: Airavata
>          Issue Type: Bug
>          Components: Airavata System
>            Reporter: Marcus Christie
>            Assignee: Marcus Christie
>            Priority: Major
>
> The initial use case for this system is the IU Cybergateway.  We need the following capabilities:
> * query for whether a user has an account
> ** for IU Cybergateway the user cluster access is determined by querying LDAP
> * add an SSH public key for the user to authenticate (actually Airavata to authenticate on behalf of the user) to the cluster
> ** for IU Cybergateway the key is added to LDAP
> Once the user has a cluster account and their SSH key has been added the following additional things need to be done
> * test that Airavata can authenticate to the cluster on the users behalf
> * add a scratch location that Airavata will use for the user on the cluster
> Eric Coulter has developed a prototype LDAP client that can query for a user's account and deposit an SSH key in LDAP: https://github.iu.edu/jecoulte/airavata-ldap-prototype (note: this link is only accessible via IU credentials).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)