Seqera Platform Feature Requests

We’d love to see Seqera Platform support cloud identity passthrough, allowing pipelines to securely access cloud resources (like storage, compute, secrets) using native identity mechanisms from AWS, Azure, and GCP — without needing to manage long-lived credentials. (Seqera Platform already supports this for HPC). This would allow access to cloud services to be governed directly by cloud IAM policies, improving both security and enterprise integration. Why this matters Today, jobs typically authenticate to cloud services using infrastructure-level credentials (e.g., an IAM role or service principal attached to the compute environment). These credentials are: Shared across users Often over-permissioned Not user-aware — cloud services can’t tell who requested access This limits enterprises from applying their existing IAM policies and can create operational or audit complexity. ✅ What we’re asking for Enable Seqera Platform to support cloud-native, credential-less authentication, such as: AWS: IAM Roles with identity federation (e.g., via IAM Identity Center or OIDC) Azure: System- and user-assigned Managed Identities GCP: Workload Identity Federation tied to user or workspace context This would allow: Per-user or per-pipeline IAM role/identity selection Fine-grained access controls to cloud resources, managed entirely in the cloud provider’s IAM system Removal of static secrets (like service principal keys or access tokens)

Enable OIDC SSO in Seqera Cloud Pro. Current Seqera Cloud only supports email, Google, and Github authentication providers. This would enable support for users to bring their own providers such as Azure AD, Okta, and Google Workspace for seamless integration with existing identity infrastructure.

We are currently utilizing Exchange Online with Basic Authentication ( SMTP AUTH ) to send emails from the Platform. However, we recently received a notification from Microsoft regarding their plans to deprecate Basic Authentication for SMTP AUTH by September 2025. As per their announcement, OAuth will be required for SMTP AUTH after this date: https://techcommunity.microsoft.com/blog/exchange/exchange-online-to-retire-basic-auth-for-client-submission-smtp-auth/4114750 Given this update, we would like to ask for the platform to support OAuth for SMTP AUTH in the future. Ensuring compatibility with OAuth will be critical for maintaining seamless email functionality once Basic Authentication is retired. Thank you for your attention to this matter. Please let us know if further details are needed from our side. We look forward to your response.

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.

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!

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?