Seqera Platform Feature Requests

We would like to be able to authenticate to MySQL database with Microsoft EntraID due to security regulations. Entra ID Use Entra ID with MySQL database

Using public OpenID identity providers such as Google or GitHub to authenticate with Seqera Platform Enterprise is severely hampered by the inconvenient user management. While a user access allow-list can be used to restrict access to specific email addresses or domains, this list is currently only configurable via environment variables or the tower.yml configuration file ( https://docs.seqera.io/platform/24.1/enterprise/configuration/authentication#configure-user-access-allow-list ) As a result, any changes to the allowed users require administrative access to the server and a restart of the application. In large organizations like universities, the response times of central IT services are typically slow, making the onboarding of new users a process that can take weeks. For short-term users, such as interns or master’s students, gaining access is quite impractical or even impossible before their time at the organization ends. Therefore, it would be beneficial for organization owners on the Seqera Platform to have the ability to manage the allow-list directly through the user interface. Additionally, we have observed that the current allow-list functionality on the Seqera Platform can be too restrictive for users with multiple email addresses linked to their OpenID identity provider. For instance, we recently encountered a case where a user’s primary GitHub email was included in the allow-list, yet access was denied because their secondary email was not. If changes to the allow-list could be made quickly via Seqera Platform's user interface, this issue could have been resolved promptly. However, the weeks-long delay in implementing a change made it particularly frustrating that a user, whose primary GitHub email was already on the allow-list, still could not authenticate. Thank you for your understanding and implementation!

Adding a SSO option using Azure Active Directory (Azure AD) as the IdP for Seqera Platform Cloud would be a big improvement for our organization.

Add Azure AAD-enabled authentication to Azure Credentials set. This will enable Seqera Platform to authenticate as a Service Principal when creating Azure compute resources or accessing Azure storage. Currently, Azure uses account names and keys for accessing Azure. Azure Batch comes in two flavors: Batch managed : The batch service manages VMs so everything is done 'under' the batch account. Uses keys for authentication User Subscription : The VMs etc are run in the user account under one subscription, which is more flexible. Only uses AAD for authentication. An alternative to using account keys, as supported by Nextflow, would be to use a service principal which has the correct permissions. We would have a similar page but with options to add: A batch account name A storage account name An Azure location A service principal ID (Directory tenant ID) A tenant ID (Application Tenant ID) A service principal secret (Client secret value)

Optionally make Nginx redirect all /login links to /oauth/login/oidc Should be a one-line addition to the Nginx file.

We have the Okta integration working, but the button offering the option says "Sign in with OpenID Connect" and our users are confused by it. Every other service we have offers "Login with Okta". Can we customize this button somehow to mention "Okta"?

The current process to create a Tower agent credential is: From credentials select Tower agent will give details on the usage including a connection id . The user has to go the HPC, download the agent then run it. The user now can click on add to add the agent on Tower. I am not sure if step 2 is mandatory here! I think the user experience would be better if the user does not need to run the agent here. Just do the whole creation at once on Tower. And when needed run the agent or Tower will complain. It seems to me that this step is mainly to get the connection id and this does not need to have the agent running. Again, I am not sure what is going on in the background but I thought to highlight this as I think it can be improved.

I noticed that my Enterprise tower instance logs me out much faster than tower.nf does. Is there a setting that controls the timeout value for logins and can this be increased so that we don't need to log in as often?

I'm looking at joining some existing systems to the Seqera Platform, and building some new ones surrounding it. Users log in to those systems and they might request a Seqera Platform Nextflow pipeline to run, or to view the Nextflow Pipeline Run status and metadata, as well as metadata from other places. We're currently moving our SSO system to OpenID Connect through Okta, and having the ability to pass on the JWT based Access Token to Seqera Platform to make requests with a logged in users identity would make this much more possible. As a basic flow: A user logs in to Application A, and gains an Access Token and an Identity Token from Okta. The user views a Nextflow pipeline run, and surrounding metadata and decides to rerun it. In Application A, the user clicks rerun. A request is made to Seqera Platform with the users' Access Token as a Bearer token. Seqera Platform can either validate the JWT is correct or make a request to Okta to check its valid (or both). Seqera Platform validates access, kicking off a Nextflow Pipeline Run on the relevant compute environment. Application A polls the Seqera Platform for updates.

The Seqera Platform API currently allows both PAT and JWT token authentication. PAT: Used for accessing the API using long term access keys JWT: Used for accessing the API with a browser app interaction Allowing access to the Tower APIs via a JWT token acquired programmatically in order to integrate the Tower API into a separate third-party service using an OIDC authentication provider would be another option. This would allow the implementation of an SSO (single sign-on) experience between the third-party application and the Tower backend API.