lahirujayathilake opened a new issue, #575: URL: https://github.com/apache/airavata-custos/issues/575
This issue is to address how a non-cluster user gets access to submit jobs through a verified third-party gateway that is registered with the signer service. A non-cluster user has a Custos account but no cluster account. A PI adds them to an allocation, and their jobs run in the PI's cluster account with an SSH certificate. ## Workflow 1. A PI with an allocation exists. The PI has a cluster account (eg, `jdoe`). 2. The PI opens the allocation, goes to Members, and clicks `Add delegated user`. 3. The PI enters the person's email and name. 4. The portal shows a disclaimer about the PI's responsibility, and the PI accepts it. 5. Custos creates the person as a delegated user, which is the user type for a non-cluster user (similar to temp account user type `VIRTUAL`), and adds them to the allocation. No cluster account is created. 6. The invited person must sign in to the portal once. This makes their account active, so certificates can be generated for them. 7. Custos tells the signer service, through the signer connector, that this person may use the PI's account. 8. The user signs in to a registered gateway and submits a job. (signer-service app-registration to be implemented) 9. The gateway asks the signer service for an SSH certificate on the user's behalf. 10. The signer service checks that the gateway is registered and that the user is allowed. It then issues a short-lived certificate. 11. The gateway uses the certificate to submit the job on the cluster, in the PI's account. The user never holds a key or a certificate. 12. The cluster accepts it, because the certificate comes from the signer service and the user is on the allowed list. 13. Access ends when the PI revokes it or the allocation ends. 14. If the person is vetted later, a site admin can give them their own cluster account. Their Custos user and history stay, and the access through the PI's account ends. ## High-level architecture <img width="1230" height="518" alt="Image" src="https://github.com/user-attachments/assets/8fec3474-9df2-4d87-a707-f2d30fc36130"; /> Sequence, 1. PI adds a delegated user 2. Invoke the core service 3. Persist the delegated user with other info 4. Delegated user signs in through the IdP 5. Notify the signer connector 6. Update the allowed list in the signer service 7. Delegated user submits a job through a registered gateway 8. Request an SSH certificate from the signer service 9. Sign with the cluster CA key 10. Connect to the login node with the certificate 11. Verify the certificate, open the session in the PI's account 12. Job runs in the PI's account UI/UX Mockups 1. Members tab on the allocation Allocation admin can add the delegated user by clicking "Add delegated user" <img width="1157" height="652" alt="Image" src="https://github.com/user-attachments/assets/a66dc5ae-7ae8-4ef9-9394-f9723add2937"; /> 2. Add delegated user prompt <img width="1138" height="769" alt="Image" src="https://github.com/user-attachments/assets/d17fe67d-148f-48ce-a852-fd68a77945fe"; /> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
