prowler/ui/tests/providers/providers.md

E2E Tests: AWS Provider Management

Suite ID: PROVIDER-E2E Feature: AWS Provider Management.

---

Test Case: PROVIDER-E2E-001 - Add AWS Provider with Static Credentials

Priority: critical

Tags:

• type → @e2e, @serial
• feature → @providers
• provider → @aws

Description/Objective: Validates the complete flow of adding a new AWS provider using static access key credentials

Preconditions:

• Admin user authentication required (admin.auth.setup setup)
• Environment variables configured: E2E_AWS_PROVIDER_ACCOUNT_ID, E2E_AWS_PROVIDER_ACCESS_KEY and E2E_AWS_PROVIDER_SECRET_KEY
• Remove any existing provider with the same Account ID before starting the test
• This test must be run serially and never in parallel with other tests, as it requires the Account ID not to be already registered beforehand.

Flow Steps

1. Navigate to providers page
2. Click "Add Provider" button
3. Select AWS provider type (its connect step opens on the "Single AWS Account" tab)
4. Select the "Static access keys" method card
5. Fill provider details (account ID and alias)
6. Fill static credentials (access key and secret key)
7. Click "Connect account": the account and credentials are saved and the connection is tested in one step
8. Confirm the launch step appears and close it without launching a scan
9. Verify return to Providers page
10. Verify provider exists in Providers table

Expected Result

• AWS provider successfully added with static credentials
• Provider connection validated without launching a scan
• User returned to Providers page
• Provider appears in Providers table with the expected UID

Key verification points

• Provider page loads correctly
• Connect account page displays AWS option
• Credentials form accepts static credentials
• Launch step appears
• Successful return to Providers page after closing the launch step
• Provider exists in Providers table (verified by account ID)
• Provider UID matches the expected value

Notes

• Test uses environment variables for AWS credentials
• Provider cleanup performed before each test to ensure clean state
• Requires valid AWS account with appropriate permissions

---

Test Case: PROVIDER-E2E-003 - Add Azure Provider with Static Credentials

Priority: critical

Tags:

• type → @e2e, @serial
• feature → @providers
• provider → @azure

Description/Objective: Validates the complete flow of adding a new Azure provider using static client credentials (Client ID, Client Secret, Tenant ID)

Preconditions:

• Admin user authentication required (admin.auth.setup setup)
• Environment variables configured: E2E_AZURE_SUBSCRIPTION_ID, E2E_AZURE_CLIENT_ID, E2E_AZURE_SECRET_ID, E2E_AZURE_TENANT_ID
• Remove any existing provider with the same Subscription ID before starting the test
• This test must be run serially and never in parallel with other tests, as it requires the Subscription ID not to be already registered beforehand.

Flow Steps

1. Navigate to providers page
2. Click "Add Provider" button
3. Select Azure provider type (its connect step opens right away)
4. Stay on the "Single Azure Subscription" tab
5. Fill provider details (subscription ID and alias)
6. Fill Azure credentials (client ID, client secret, tenant ID)
7. Click "Connect subscription": the account and credentials are saved and the connection is tested in one step
8. Confirm the launch step appears and close it without launching a scan
9. Verify return to Providers page
10. Verify provider exists in Providers table

Expected Result

• Azure provider successfully added with static credentials
• Provider connection validated without launching a scan
• User returned to Providers page
• Provider appears in Providers table with the expected UID

Key verification points

• Provider page loads correctly
• Connect account page displays Azure option
• Azure credentials form accepts all required fields
• Launch step appears
• Successful return to Providers page after closing the launch step
• Provider exists in Providers table (verified by subscription ID)
• Provider UID matches the expected value

Notes

• Test uses environment variables for Azure credentials
• Provider cleanup performed before each test to ensure clean state
• Requires valid Azure subscription with appropriate permissions
• Client credentials must have sufficient permissions for security scanning

---

Test Case: PROVIDER-E2E-004 - Add M365 Provider with Static Credentials

Priority: critical

Tags:

• type → @e2e, @serial
• feature → @providers
• provider → @m365

Description/Objective: Validates the complete flow of adding a new Microsoft 365 provider using static client credentials (Client ID, Client Secret, Tenant ID) tied to a Domain ID.

Preconditions:

• Admin user authentication required (admin.auth.setup setup)
• Environment variables configured: E2E_M365_DOMAIN_ID, E2E_M365_CLIENT_ID, E2E_M365_SECRET_ID, E2E_M365_TENANT_ID
• Remove any existing provider with the same Domain ID before starting the test
• This test must be run serially and never in parallel with other tests, as it requires the Domain ID not to be already registered beforehand.

Flow Steps

1. Navigate to providers page
2. Click "Add Provider" button
3. Select M365 provider type (its connect step opens right away)
4. Select the "App client secret" method card
5. Verify the client secret fields are shown
6. Fill provider details (domain ID and alias)
7. Fill M365 credentials (client ID, client secret, tenant ID)
8. Click "Connect tenant": the account and credentials are saved and the connection is tested in one step
9. Confirm the launch step appears and close it without launching a scan
10. Verify return to Providers page
11. Verify provider exists in Providers table

Expected Result

• M365 provider successfully added with static credentials
• Provider connection validated without launching a scan
• User returned to Providers page
• Provider appears in Providers table with the expected UID

Key verification points

• Provider page loads correctly
• Connect account page displays M365 option
• M365 credentials form accepts all required fields
• Launch step appears
• Successful return to Providers page after closing the launch step
• Provider exists in Providers table (verified by domain ID)
• Provider UID matches the expected value

Notes

• Test uses environment variables for M365 credentials
• Provider cleanup performed before each test to ensure clean state
• Requires valid Microsoft 365 tenant with appropriate permissions
• Client credentials must have sufficient permissions for security scanning

---

Test Case: PROVIDER-E2E-005 - Add M365 Provider with Certificate Credentials

Priority: critical

Tags:

• type → @e2e, @serial
• feature → @providers
• provider → @m365

Description/Objective: Validates the complete flow of adding a new Microsoft 365 provider using certificate-based authentication (Client ID, Tenant ID, Certificate Content) tied to a Domain ID.

Preconditions:

• Admin user authentication required (admin.auth.setup setup)
• Environment variables configured: E2E_M365_DOMAIN_ID, E2E_M365_CLIENT_ID, E2E_M365_TENANT_ID, E2E_M365_CERTIFICATE_CONTENT
• Remove any existing provider with the same Domain ID before starting the test
• This test must be run serially and never in parallel with other tests, as it requires the Domain ID not to be already registered beforehand.

Flow Steps

1. Navigate to providers page
2. Click "Add Provider" button
3. Select M365 provider type (its connect step opens right away)
4. Select the "App certificate" method card
5. Verify the certificate fields are shown
6. Fill provider details (domain ID and alias)
7. Fill M365 certificate credentials (client ID, tenant ID, certificate content)
8. Click "Connect tenant": the account and credentials are saved and the connection is tested in one step
9. Confirm the launch step appears and close it without launching a scan
10. Verify return to Providers page
11. Verify provider exists in Providers table

Expected Result

• M365 provider successfully added with certificate credentials
• Provider connection validated without launching a scan
• User returned to Providers page
• Provider appears in Providers table with the expected UID

Key verification points

• Provider page loads correctly
• Connect account page displays M365 option
• Certificate credentials form accepts all required fields
• Launch step appears
• Successful return to Providers page after closing the launch step
• Provider exists in Providers table (verified by domain ID)
• Provider UID matches the expected value

Notes

• Test uses environment variables for M365 certificate credentials
• Provider cleanup performed before each test to ensure clean state
• Requires valid Microsoft 365 tenant with certificate-based authentication
• Certificate must be properly configured and have sufficient permissions for security scanning

---

Test Case: PROVIDER-E2E-006 - Add Kubernetes Provider with Kubeconfig Content

Priority: critical

Tags:

• type → @e2e, @serial
• feature → @providers
• provider → @kubernetes

Description/Objective: Validates the complete flow of adding a new Kubernetes provider using kubeconfig content authentication

Preconditions:

• Admin user authentication required (admin.auth.setup setup)
• Environment variables configured: E2E_KUBERNETES_CONTEXT, E2E_KUBERNETES_KUBECONFIG_PATH
• Kubeconfig file must exist at the specified path
• Remove any existing provider with the same Context before starting the test
• This test must be run serially and never in parallel with other tests, as it requires the Context not to be already registered beforehand.

Flow Steps

1. Navigate to providers page
2. Click "Add Provider" button
3. Select Kubernetes provider type (its connect step opens right away)
4. Fill provider details (Kubernetes context and alias)
5. Verify the kubeconfig field is shown
6. Fill Kubernetes credentials (kubeconfig content)
7. Click "Connect cluster": the account and credentials are saved and the connection is tested in one step
8. Confirm the launch step appears and close it without launching a scan
9. Verify return to Providers page
10. Verify provider exists in Providers table

Expected Result

• Kubernetes provider successfully added with kubeconfig content
• Provider connection validated without launching a scan
• User returned to Providers page
• Provider appears in Providers table with the expected UID

Key verification points

• Provider page loads correctly
• Connect account page displays Kubernetes option
• Provider details form accepts context and alias
• Connect step shows kubeconfig content field
• Kubeconfig content is properly filled in the correct field
• Launch step appears
• Successful return to Providers page after closing the launch step
• Provider exists in Providers table (verified by context)
• Provider UID matches the expected value

Notes

• Test uses environment variables for Kubernetes context and kubeconfig file path
• Kubeconfig content is read from file and used for authentication
• Provider cleanup performed before each test to ensure clean state
• Requires valid Kubernetes cluster with accessible kubeconfig
• Kubeconfig must have sufficient permissions for security scanning
• Test validates that kubeconfig content goes to the correct field (not the context field)

---

Test Case: PROVIDER-E2E-007 - Add GCP Provider with Service Account Key

Priority: critical

Tags:

• type → @e2e, @serial
• feature → @providers
• provider → @gcp

Description/Objective: Validates the complete flow of adding a new GCP provider using service account key authentication

Preconditions:

• Admin user authentication required (admin.auth.setup setup)
• Environment variables configured: E2E_GCP_PROJECT_ID, E2E_GCP_BASE64_SERVICE_ACCOUNT_KEY
• Remove any existing provider with the same Project ID before starting the test
• This test must be run serially and never in parallel with other tests, as it requires the Project ID not to be already registered beforehand.

Flow Steps

1. Navigate to providers page
2. Click "Add Provider" button
3. Select GCP provider type (its connect step opens right away)
4. Stay on the "Single GCP Project" tab
5. Select the "Service account key" method card
6. Verify the service account key field is shown
7. Fill provider details (project ID and alias)
8. Fill GCP service account key credentials
9. Click "Connect project": the account and credentials are saved and the connection is tested in one step
10. Confirm the launch step appears and close it without launching a scan
11. Verify return to Providers page
12. Verify provider exists in Providers table

Expected Result

• GCP provider successfully added with service account key
• Provider connection validated without launching a scan
• User returned to Providers page
• Provider appears in Providers table with the expected UID

Key verification points

• Provider page loads correctly
• Connect account page displays GCP option
• Provider details form accepts project ID and alias
• Connect step shows service account key field
• Service account key is properly filled in the correct field
• Launch step appears
• Successful return to Providers page after closing the launch step
• Provider exists in Providers table (verified by project ID)
• Provider UID matches the expected value

Notes

• Test uses environment variables for GCP project ID and service account key
• Service account key is provided as base64 encoded JSON content
• Provider cleanup performed before each test to ensure clean state
• Requires valid GCP project with service account having appropriate permissions
• Service account must have sufficient permissions for security scanning
• Test validates that service account key goes to the correct field
• Test uses base64 encoded environment variables for GCP service account key

---

Test Case: PROVIDER-E2E-008 - Add GitHub Provider with Personal Access Token

Priority: critical

Tags:

• type → @e2e, @serial
• feature → @providers
• provider → @github

Description/Objective: Validates the complete flow of adding a new GitHub provider using personal access token authentication for a user account

Preconditions:

• Admin user authentication required (admin.auth.setup setup)
• Environment variables configured: E2E_GITHUB_USERNAME, E2E_GITHUB_PERSONAL_ACCESS_TOKEN
• Remove any existing provider with the same Username before starting the test
• This test must be run serially and never in parallel with other tests, as it requires the Username not to be already registered beforehand.

Flow Steps

1. Navigate to providers page
2. Click "Add Provider" button
3. Select GitHub provider type (its connect step opens right away)
4. Select the "Personal access token" method card
5. Verify the token field is shown
6. Fill provider details (username and alias)
7. Fill GitHub personal access token credentials
8. Click "Connect account": the account and credentials are saved and the connection is tested in one step
9. Confirm the launch step appears and close it without launching a scan
10. Verify return to Providers page
11. Verify provider exists in Providers table

Expected Result

• GitHub provider successfully added with personal access token
• Provider connection validated without launching a scan
• User returned to Providers page
• Provider appears in Providers table with the expected UID

Key verification points

• Provider page loads correctly
• Connect account page displays GitHub option
• Provider details form accepts username and alias
• Connect step shows token field
• Personal access token is properly filled in the correct field
• Launch step appears
• Successful return to Providers page after closing the launch step
• Provider exists in Providers table (verified by username)
• Provider UID matches the expected value

Notes

• Test uses environment variables for GitHub username and personal access token
• Provider cleanup performed before each test to ensure clean state
• Requires valid GitHub account with personal access token
• Personal access token must have sufficient permissions for security scanning
• Test validates that personal access token goes to the correct field

---

Test Case: PROVIDER-E2E-009 - Add GitHub Provider with GitHub App

Priority: critical

Tags:

• type → @e2e, @serial
• feature → @providers
• provider → @github

Description/Objective: Validates the complete flow of adding a new GitHub provider using GitHub App authentication for a user account

Preconditions:

• Admin user authentication required (admin.auth.setup setup)
• Environment variables configured: E2E_GITHUB_USERNAME, E2E_GITHUB_APP_ID, E2E_GITHUB_BASE64_APP_PRIVATE_KEY
• Remove any existing provider with the same Username before starting the test
• This test must be run serially and never in parallel with other tests, as it requires the Username not to be already registered beforehand.

Flow Steps

1. Navigate to providers page
2. Click "Add Provider" button
3. Select GitHub provider type (its connect step opens right away)
4. Select the "GitHub App" method card
5. Verify the App ID and private key fields are shown
6. Fill provider details (username and alias)
7. Fill GitHub App credentials (App ID and private key)
8. Click "Connect account": the account and credentials are saved and the connection is tested in one step
9. Confirm the launch step appears and close it without launching a scan
10. Verify return to Providers page
11. Verify provider exists in Providers table

Expected Result

• GitHub provider successfully added with GitHub App credentials
• Provider connection validated without launching a scan
• User returned to Providers page
• Provider appears in Providers table with the expected UID

Key verification points

• Provider page loads correctly
• Connect account page displays GitHub option
• Provider details form accepts username and alias
• Connect step shows App ID and private key fields
• GitHub App credentials are properly filled in the correct fields
• Launch step appears
• Successful return to Providers page after closing the launch step
• Provider exists in Providers table (verified by username)
• Provider UID matches the expected value

Notes

• Test uses environment variables for GitHub username, App ID, and base64 encoded private key
• Private key is base64 encoded and must be decoded before use
• Provider cleanup performed before each test to ensure clean state
• Requires valid GitHub App with App ID and private key
• GitHub App must have sufficient permissions for security scanning
• Test validates that GitHub App credentials go to the correct fields

---

Test Case: PROVIDER-E2E-010 - Add GitHub Provider with Organization Personal Access Token

Priority: critical

Tags:

• type → @e2e, @serial
• feature → @providers
• provider → @github

Description/Objective: Validates the complete flow of adding a new GitHub provider using organization personal access token authentication

Preconditions:

• Admin user authentication required (admin.auth.setup setup)
• Environment variables configured: E2E_GITHUB_ORGANIZATION, E2E_GITHUB_ORGANIZATION_ACCESS_TOKEN
• Remove any existing provider with the same Organization name before starting the test
• This test must be run serially and never in parallel with other tests, as it requires the Organization name not to be already registered beforehand.

Flow Steps

1. Navigate to providers page
2. Click "Add Provider" button
3. Select GitHub provider type (its connect step opens right away)
4. Select the "Personal access token" method card
5. Verify the token field is shown
6. Fill provider details (organization name and alias)
7. Fill GitHub organization personal access token credentials
8. Click "Connect account": the account and credentials are saved and the connection is tested in one step
9. Confirm the launch step appears and close it without launching a scan
10. Verify return to Providers page
11. Verify provider exists in Providers table

Expected Result

• GitHub provider successfully added with organization personal access token
• Provider connection validated without launching a scan
• User returned to Providers page
• Provider appears in Providers table with the expected UID

Key verification points

• Provider page loads correctly
• Connect account page displays GitHub option
• Provider details form accepts organization name and alias
• Connect step shows token field
• Organization personal access token is properly filled in the correct field
• Launch step appears
• Successful return to Providers page after closing the launch step
• Provider exists in Providers table (verified by organization name)
• Provider UID matches the expected value

Notes

• Test uses environment variables for GitHub organization name and organization access token
• Provider cleanup performed before each test to ensure clean state
• Requires valid GitHub organization with organization access token
• Organization access token must have sufficient permissions for security scanning
• Test validates that organization personal access token goes to the correct field

---

Test Case: PROVIDER-E2E-011 - Add AWS Provider with Assume Role via AWS SDK Defaults

Priority: critical

Tags:

• type → @e2e, @serial
• feature → @providers
• provider → @aws

Description/Objective: Validates adding an AWS provider assuming a role while sourcing credentials from the AWS SDK default chain.

Preconditions:

• Admin user authentication required (admin.auth.setup setup)
• Environment variables configured: E2E_AWS_PROVIDER_ROLE_ARN
• Remove any existing provider with the same Account ID before starting the test
• This test must be run serially and never in parallel with other tests, as it requires the Account ID not to be already registered beforehand

Flow Steps

1. Navigate to providers page
2. Click "Add Provider" button
3. Select AWS provider type (its connect step opens on the "Single AWS Account" tab)
4. Keep the "IAM Role" method card (selected by default)
5. Fill the alias (the account ID is read from the role ARN)
6. Nothing to choose: the role is assumed with the host's AWS SDK default credentials
7. Fill the role ARN
8. Click "Connect account": the account and credentials are saved and the connection is tested in one step
9. Confirm the launch step appears and close it without launching a scan
10. Verify return to Providers page
11. Verify provider exists in Providers table

Expected Result

• AWS provider successfully added using AWS SDK default credentials to assume the role
• Provider connection validated without launching a scan
• User returned to Providers page
• Provider appears in Providers table with the expected UID

Key verification points

• Provider page loads correctly
• Connect account page displays AWS option
• The role form asks for no credentials of its own: the AWS SDK default chain assumes the role
• Role ARN field accepts the provided value
• Launch step appears
• Successful return to Providers page after closing the launch step
• Provider exists in Providers table (verified by account ID)
• Provider UID matches the expected value

Notes

• Test leverages AWS SDK default credential chain (environment-configured keys) for Access Key and Secret Key
• Environment variable E2E_AWS_PROVIDER_ROLE_ARN must reference a valid assumable role
• Provider cleanup performed before each test to ensure clean state
• Requires valid AWS account with permissions to assume the target role

---

Test Case: PROVIDER-E2E-012 - Add OCI Provider with API Key Credentials

Priority: critical

Tags:

• type → @e2e, @serial
• feature → @providers
• provider → @oci

Description/Objective: Validates the complete flow of adding a new OCI provider using API Key credentials.

Preconditions:

• Admin user authentication required (admin.auth.setup setup)
• Environment variables configured: E2E_OCI_TENANCY_ID, E2E_OCI_USER_ID, E2E_OCI_FINGERPRINT, E2E_OCI_KEY_CONTENT, E2E_OCI_REGION (optional, defaults to us-ashburn-1)
• Remove any existing provider with the same Tenancy ID before starting the test
• This test must be run serially and never in parallel with other tests, as it requires the Tenancy ID not to be already registered beforehand.

Flow Steps

1. Navigate to providers page
2. Click "Add Provider" button
3. Select OCI provider type (its connect step opens right away)
4. Fill provider details (tenancy OCID and alias)
5. Verify the OCI credentials fields are shown
6. Fill OCI credentials (user ID, fingerprint, key content, home region)
7. Click "Connect tenancy": the account and credentials are saved and the connection is tested in one step
8. Confirm the launch step appears and close it without launching a scan
9. Verify return to Providers page
10. Verify provider exists in Providers table

Expected Result

• OCI provider successfully added with API Key credentials
• Provider connection validated without launching a scan
• User returned to Providers page
• Provider appears in Providers table with the expected UID

Key verification points

• Provider page loads correctly
• Connect account page displays OCI option
• Provider details form accepts tenancy ID and alias
• Connect step shows the OCI credentials fields
• Credentials form accepts all required fields (user ID, fingerprint, key content, home region)
• Launch step appears
• Successful return to Providers page after closing the launch step
• Provider exists in Providers table (verified by tenancy ID)
• Provider UID matches the expected value

Notes

• Test uses environment variables for OCI credentials
• Provider cleanup performed before each test to ensure clean state
• Requires valid OCI account with API Key set up
• API Key credential type is automatically used for OCI providers

---

Test Case: PROVIDER-E2E-013 - Update OCI Provider Credentials

Priority: normal

Tags:

• type → @e2e, @serial
• feature → @providers
• provider → @oci

Description/Objective: Validates the complete flow of updating credentials for an existing OCI provider. This test verifies that the provider UID is correctly passed to the update credentials form, which is required for OCI credential validation.

Preconditions:

• Admin user authentication required (admin.auth.setup setup)
• Environment variables configured: E2E_OCI_TENANCY_ID, E2E_OCI_USER_ID, E2E_OCI_FINGERPRINT, E2E_OCI_KEY_CONTENT, E2E_OCI_REGION (optional, defaults to us-ashburn-1)
• An OCI provider with the specified Tenancy ID must already exist (run PROVIDER-E2E-012 first)
• This test must be run serially and never in parallel with other tests

Flow Steps

1. Navigate to providers page
2. Verify OCI provider exists in the table
3. Click row actions menu for the OCI provider
4. Click "Update Credentials" option
5. Verify the wizard opens on the OCI connect step with "Cancel" and "Save and test" in the footer
6. Verify OCI credentials form fields are visible (identity fields are hidden; the tenancy comes from the provider UID)
7. Fill OCI credentials (user ID, fingerprint, key content, home region)
8. Click "Save and test": the credentials are saved and the connection is tested
9. Verify the wizard closes back on the Providers page

Expected Result

• Update credentials page loads successfully
• OCI credentials form is displayed with all required fields
• Provider UID is correctly passed to the form (hidden field populated)
• Credentials can be updated and submitted
• The connection is tested on submit and the wizard closes once it passes

Key verification points

• Provider page loads correctly
• OCI provider row is visible in providers table
• Row actions dropdown opens and displays "Update Credentials" option
• The update opens the connect step with only the credentials fields
• OCI credentials form displays all required fields (user ID, fingerprint, key content, home region)
• Form submission succeeds (no silent failures due to missing provider UID)
• Wizard closes on the Providers page after a passed connection test

Notes

• Test uses same environment variables as PROVIDER-E2E-012 (add OCI provider)
• Requires PROVIDER-E2E-012 to be run first to create the OCI provider
• This test validates the fix for OCI update credentials form failing silently due to missing provider UID
• The provider UID is required for OCI credential validation (tenancy field auto-populated from UID)

---

Test Case: PROVIDER-E2E-014 - Add AlibabaCloud Provider with Static Credentials

Priority: critical

Tags:

• type → @e2e, @serial
• feature → @providers
• provider → @alibabacloud

Description/Objective: Validates the complete flow of adding a new Alibaba Cloud provider using static credentials (Access Key ID and Access Key Secret)

Preconditions:

• Admin user authentication required (admin.auth.setup setup)
• Environment variables configured: E2E_ALIBABACLOUD_ACCOUNT_ID, E2E_ALIBABACLOUD_ACCESS_KEY_ID, E2E_ALIBABACLOUD_ACCESS_KEY_SECRET
• Remove any existing provider with the same Account ID before starting the test
• This test must be run serially and never in parallel with other tests, as it requires the Account ID not to be already registered beforehand.

Flow Steps

1. Navigate to providers page
2. Click "Add Provider" button
3. Select AlibabaCloud provider type (its connect step opens right away)
4. Verify the "RAM role" and "Static access keys" method cards are shown
5. Select the "Static access keys" method card
6. Verify the access key fields are shown
7. Fill provider details (account ID and alias)
8. Fill AlibabaCloud credentials (access key ID and access key secret)
9. Click "Connect account": the account and credentials are saved and the connection is tested in one step
10. Confirm the launch step appears and close it without launching a scan
11. Verify return to Providers page
12. Verify provider exists in Providers table

Expected Result

• AlibabaCloud provider successfully added with static credentials
• Provider connection validated without launching a scan
• User returned to Providers page
• Provider appears in Providers table with the expected UID

Key verification points

• Provider page loads correctly
• Connect account page displays AlibabaCloud option
• Provider details form accepts account ID and alias
• Connect step shows the "RAM role" and "Static access keys" method cards
• Connect step shows access key ID and access key secret fields
• Static credentials are properly filled in the correct fields
• Launch step appears
• Successful return to Providers page after closing the launch step
• Provider exists in Providers table (verified by account ID)
• Provider UID matches the expected value

Notes

• Test uses environment variables for AlibabaCloud credentials
• Provider cleanup performed before each test to ensure clean state
• Requires valid Alibaba Cloud account with appropriate permissions
• Static credentials must have sufficient permissions for security scanning

---

Test Case: PROVIDER-E2E-015 - Add AlibabaCloud Provider with RAM Role Credentials

Priority: critical

Tags:

• type → @e2e, @serial
• feature → @providers
• provider → @alibabacloud

Description/Objective: Validates the complete flow of adding a new Alibaba Cloud provider using RAM Role credentials (Access Key ID, Access Key Secret, and Role ARN)

Preconditions:

• Admin user authentication required (admin.auth.setup setup)
• Environment variables configured: E2E_ALIBABACLOUD_ACCOUNT_ID, E2E_ALIBABACLOUD_ACCESS_KEY_ID, E2E_ALIBABACLOUD_ACCESS_KEY_SECRET, E2E_ALIBABACLOUD_ROLE_ARN
• Remove any existing provider with the same Account ID before starting the test
• This test must be run serially and never in parallel with other tests, as it requires the Account ID not to be already registered beforehand.

Flow Steps

1. Navigate to providers page
2. Click "Add Provider" button
3. Select AlibabaCloud provider type (its connect step opens right away)
4. Verify the "RAM role" and "Static access keys" method cards are shown
5. Select the "RAM role" method card
6. Verify the RAM role fields are shown
7. Fill provider details (account ID and alias)
8. Fill AlibabaCloud RAM Role credentials (access key ID, access key secret, and role ARN)
9. Click "Connect account": the account and credentials are saved and the connection is tested in one step
10. Confirm the launch step appears and close it without launching a scan
11. Verify return to Providers page
12. Verify provider exists in Providers table

Expected Result

• AlibabaCloud provider successfully added with RAM Role credentials
• Provider connection validated without launching a scan
• User returned to Providers page
• Provider appears in Providers table with the expected UID

Key verification points

• Provider page loads correctly
• Connect account page displays AlibabaCloud option
• Provider details form accepts account ID and alias
• Connect step shows the "RAM role" and "Static access keys" method cards
• Connect step shows access key ID, access key secret, and role ARN fields
• RAM Role credentials are properly filled in the correct fields
• Launch step appears
• Successful return to Providers page after closing the launch step
• Provider exists in Providers table (verified by account ID)
• Provider UID matches the expected value

Notes

• Test uses environment variables for AlibabaCloud RAM Role credentials
• Provider cleanup performed before each test to ensure clean state
• Requires valid Alibaba Cloud account with RAM Role configured
• RAM Role must have sufficient permissions for security scanning
• Role ARN must be properly configured and assumable

---

Test Case: PROVIDER-E2E-016 - Add AWS Organization Using AWS Organizations Flow

Priority: critical

Tags:

• type → @e2e, @serial
• feature → @providers
• provider → @aws

Description/Objective: Validates the complete flow of adding AWS accounts through AWS Organizations, including organization setup, authentication, account selection, and scan scheduling.

Preconditions:

• Admin user authentication required (admin.auth.setup setup)
• Environment variables configured: E2E_AWS_ORGANIZATION_ID, E2E_AWS_ORGANIZATION_ROLE_ARN
• Remove any existing provider with the same Organization ID before starting the test
• StackSet must be deployed in AWS Organizations and expose a valid IAM Role ARN for Prowler
• This test must be run serially and never in parallel with other tests, as it requires the Organization ID not to be already registered beforehand.

Flow Steps

1. Navigate to providers page
2. Click "Add Provider" button
3. Select AWS provider type
4. Select the "Full AWS Organization" tab on the AWS connect step
5. Fill organization details (organization ID and optional name)
6. Continue to authentication details and provide role ARN
7. Confirm StackSet deployment checkbox and authenticate
8. Confirm organization account selection step and continue
9. Verify organization launch step, choose daily scan schedule, and save
10. Verify return to Providers page

Expected Result

• AWS Organizations flow completes successfully
• Accounts are connected and launch step is displayed
• Scan scheduling selection is applied
• User returns to Providers page after saving

Key verification points

• Connect account page displays AWS option
• "Full AWS Organization" tab is available on the AWS connect step
• Authentication details step loads
• Account selection step loads
• Accounts connected launch step appears
• Successful return to Providers page after saving

Notes

• Organization ID must follow AWS format (e.g., o-abc123def4)
• Role ARN must belong to the StackSet deployment for Organizations flow
• Provider cleanup is executed before test run to avoid unique constraint conflicts

---

Test Case: PROVIDER-E2E-017 - Add Google Workspace Provider with Service Account Credentials

Priority: critical

Tags:

• type → @e2e, @serial
• feature → @providers
• provider → @googleworkspace

Description/Objective: Validates the complete flow of adding a new Google Workspace provider using Service Account authentication with Customer ID, Service Account JSON, and delegated user email.

Preconditions:

• Admin user authentication required (admin.auth.setup setup)
• Environment variables configured: E2E_GOOGLEWORKSPACE_CUSTOMER_ID, E2E_GOOGLEWORKSPACE_SERVICE_ACCOUNT_JSON, E2E_GOOGLEWORKSPACE_DELEGATED_USER
• Remove any existing provider with the same Customer ID before starting the test
• This test must be run serially and never in parallel with other tests, as it requires the Customer ID not to be already registered beforehand.

Flow Steps

1. Navigate to providers page
2. Click "Add Provider" button
3. Select Google Workspace provider type (its connect step opens right away)
4. Fill provider details (customer ID and alias)
5. Verify the Google Workspace credentials fields are shown
6. Fill Google Workspace credentials (service account JSON, delegated user email; the customer ID comes from the account field)
7. Click "Connect workspace": the account and credentials are saved and the connection is tested in one step
8. Confirm the launch step appears and close it without launching a scan
9. Verify return to Providers page
10. Verify provider exists in Providers table

Expected Result

• Google Workspace provider successfully added with Service Account credentials
• Provider connection validated without launching a scan
• User returned to Providers page
• Provider appears in Providers table with the expected UID

Key verification points

• Provider page loads correctly
• Connect account page displays Google Workspace option
• Provider details form accepts customer ID (format: C[0-9a-zA-Z]+) and alias
• Connect step shows customer ID, service account JSON textarea, and delegated user email fields
• Customer ID help text is visible with instructions on finding the Customer ID
• Service account JSON field accepts multi-line formatted JSON
• Delegated user email field validates email format
• Launch step appears
• Successful return to Providers page after closing the launch step
• Provider exists in Providers table (verified by customer ID)
• Provider UID matches the expected value

Notes

• Test uses environment variables for Google Workspace credentials
• Service Account JSON is provided as multi-line JSON string (not base64 encoded)
• Customer ID must start with 'C' followed by alphanumeric characters (e.g., C01234abc)
• Delegated user email must be a super admin in the Google Workspace domain
• Provider cleanup performed before each test to ensure clean state
• Requires valid Google Workspace account with Service Account having domain-wide delegation enabled
• Service Account must have appropriate Google Workspace API scopes for security scanning

---

Test Case: PROVIDER-E2E-018 - Add Vercel Provider with API Token

Priority: critical

Tags:

• type → @e2e, @serial
• feature → @providers
• provider → @vercel

Description/Objective: Validates the complete flow of adding a new Vercel provider using API Token authentication, with a Team ID as the provider UID.

Preconditions:

• Admin user authentication required (admin.auth.setup setup)
• Environment variables configured: E2E_VERCEL_TEAM_ID, E2E_VERCEL_API_TOKEN
• Remove any existing provider with the same Team ID before starting the test
• This test must be run serially and never in parallel with other tests, as it requires the Team ID not to be already registered beforehand.

Flow Steps

1. Navigate to providers page
2. Click "Add Provider" button
3. Select Vercel provider type (its connect step opens right away)
4. Fill provider details (team ID and alias)
5. Verify the API token field is shown
6. Fill Vercel credentials (API token)
7. Click "Connect team": the account and credentials are saved and the connection is tested in one step
8. Confirm the launch step appears and close it without launching a scan
9. Verify return to Providers page
10. Verify provider exists in Providers table

Expected Result

• Vercel provider successfully added with API Token credentials
• Provider connection validated without launching a scan
• User returned to Providers page
• Provider appears in Providers table with the expected UID

Key verification points

• Provider page loads correctly
• Connect account page displays Vercel option
• Provider details form accepts team ID and alias
• Connect step shows the API Token field
• API Token is properly filled in the correct (masked) field
• Launch step appears
• Successful return to Providers page after closing the launch step
• Provider exists in Providers table (verified by team ID)
• Provider UID matches the expected value

Notes

• Test uses environment variables for the Vercel Team ID and API Token
• API Token is a masked (password) field; the only credential required for Vercel
• Provider cleanup performed before each test to ensure clean state
• Requires a valid Vercel API Token with read permissions to the resources to assess

---

Test Case: PROVIDER-E2E-019 - Add Okta Provider with OAuth 2.0 Private Key JWT Credentials

Priority: critical

Tags:

• type → @e2e, @serial
• feature → @providers
• provider → @okta

Description/Objective: Validates the complete flow of adding a new Okta provider using OAuth 2.0 Private Key JWT authentication (Client ID and PEM-encoded private key) tied to an Okta Org Domain.

Preconditions:

• Admin user authentication required (admin.auth.setup setup)
• Environment variables configured: E2E_OKTA_DOMAIN, E2E_OKTA_CLIENT_ID, E2E_OKTA_BASE64_PRIVATE_KEY
• Remove any existing provider with the same Org Domain before starting the test
• This test must be run serially and never in parallel with other tests, as it requires the Org Domain not to be already registered beforehand.

Flow Steps

1. Navigate to providers page
2. Click "Add Provider" button
3. Select Okta provider type (its connect step opens right away)
4. Fill provider details (org domain and alias)
5. Verify the Client ID and Private Key fields are shown
6. Fill Okta credentials (client ID and PEM-encoded private key)
7. Click "Connect organization": the account and credentials are saved and the connection is tested in one step
8. Confirm the launch step appears and close it without launching a scan
9. Verify return to Providers page
10. Verify provider exists in Providers table

Expected Result

• Okta provider successfully added with OAuth 2.0 Private Key JWT credentials
• Provider connection validated without launching a scan
• User returned to Providers page
• Provider appears in Providers table with the expected UID

Key verification points

• Provider page loads correctly
• Connect account page displays Okta option
• Provider details form accepts org domain (Okta-managed domain, e.g. acme.okta.com) and alias
• Connect step shows Client ID input and Private Key textarea
• Credentials are properly filled in the correct fields
• Launch step appears
• Successful return to Providers page after closing the launch step
• Provider exists in Providers table (verified by org domain)

Notes

• Test uses environment variables for Okta credentials
• Org Domain is lowercased by the form; cleanup and the table check use the normalized value
• Private Key is provided as base64-encoded PEM content and decoded before use (multi-line content)
• Provider cleanup performed before each test to ensure clean state
• Requires a valid Okta API Services app with a registered public key (JWK) matching the provided private key

---

Test Case: PROVIDER-E2E-020 - Invite a Teammate From the AWS Connect Step

Priority: high

Tags:

• type → @e2e
• feature → @providers
• provider → @aws

Description/Objective: Validates that a user who cannot connect the AWS account can invite a teammate from the AWS connect step, without leaving the wizard, and gets the invitation link to share.

Preconditions:

• Admin user authentication required (admin.auth.setup setup): the option is only offered to users who can invite (manage_account)
• No environment variables required: no provider is created

Flow Steps

1. Navigate to providers page
2. Click "Add Provider" button
3. Select AWS provider type
4. Select the "I don't have access, invite a teammate" option
5. Fill the teammate email and pick a role that can manage providers (the form preselects one only when the tenant has a role named exactly admin; the E2E tenant's is e2e_admin)
6. Click "Send invitation"
7. Verify the confirmation and the invitation link
8. Click "Done"

Expected Result

• The AWS access form is replaced by the invitation form
• The invitation is created and the confirmation shows the invited email and the accept link
• "Done" closes the wizard without creating a provider

Key verification points

• The invite option is visible on the AWS connect step for the admin user (it is offered on every provider's connect step to users with manage_account)
• "Send invitation" is enabled once a valid email is typed and a role is selected
• Confirmation text "Invitation sent to {email}" is visible
• The accept link contains /invitation/accept?invitation_token=
• The wizard modal is closed after "Done"

Notes

• Uses a unique email per run so the invitation never collides with a pending one
• The invitation is left pending; it expires on its own after 7 days