Skip to content

Add end-to-end tests for force_access_check_with_provider #1507

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
nooreldeenmansour wants to merge 1 commit into
base: main
Choose a base branch
from
+61 −0
Open

Add end-to-end tests for force_access_check_with_provider #1507

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions e2e-tests/resources/broker.resource
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -169,6 +169,14 @@ Remove Registered Owner
SSH.Execute sudo snap restart ${BROKER_SNAP_NAME}


Block Network Access To Identity Provider
[Documentation] Blocks outbound HTTPS traffic (IPv4 and IPv6) to simulate the identity
... provider being unreachable. The iptables rules are automatically reverted
... when the VM snapshot is restored at the start of the next test.
SSH.Execute sudo iptables -I OUTPUT -p tcp --dport 443 -j REJECT
SSH.Execute sudo ip6tables -I OUTPUT -p tcp --dport 443 -j REJECT
Comment on lines +176 to +177
Copy link
Copy Markdown
Contributor

@3v1n0 3v1n0 May 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't instead use static resolver routes so that we can block only the requests going to a well know domain name rather than all the https traffic?

Copy link
Copy Markdown
Member Author

@nooreldeenmansour nooreldeenmansour May 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe, but Is there a specific test scenario where blocking only a single domain would be beneficial for our test plan? Since these tests run across multiple brokers (google and entra currently, and maybe we could replace google with the generic broker; perhaps keycloak), blocking all HTTPS feels simpler and more generic. It also gets automatically reverted after each test, each test starts on a clean snapshot. So there's no risk of it affecting subsequent ones. WDYT?

Copy link
Copy Markdown
Contributor

@adombeck adombeck May 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with Noor, it's not worth spending time on blocking only the traffic to the IdP because the e2e-test doesn't require any network traffic to work, and the VM is reset when the next test is started.



# Uses sed to change the broker configuration.
# It should match both commented and uncommented lines.
# The full command looks like:
Expand Down
53 changes: 53 additions & 0 deletions e2e-tests/tests/force_access_check_with_provider.robot
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
*** Settings ***
Resource resources/utils.resource
Resource resources/authd.resource
Resource resources/broker.resource

# Test Tags robot:exit-on-failure

Test Setup utils.Test Setup snapshot=%{BROKER}-installed
Test Teardown utils.Test Teardown


*** Variables ***
${username} %{E2E_USER}
${local_password} qwer1234


*** Test Cases ***
Test second login succeeds with force_access_check_with_provider enabled
[Documentation] Verify that a registered user can log in with their local password
... when force_access_check_with_provider is enabled and the identity provider is reachable.

Log In

Open Terminal
Log In With Remote User Through CLI: QR Code ${username} ${local_password}
Log Out From Terminal Session
Close Focused Window

Change Broker Configuration force_access_check_with_provider true

Open Terminal In Sudo Mode
Log In With Remote User Through CLI: Local Password ${username} ${local_password}


Test second login fails with force_access_check_with_provider enabled offline
[Documentation] Verify that a registered user cannot log in when
... force_access_check_with_provider is enabled and the identity provider is unreachable.

Log In

Open Terminal
Log In With Remote User Through CLI: QR Code ${username} ${local_password}
Log Out From Terminal Session
Close Focused Window

Change Broker Configuration force_access_check_with_provider true

# Block outbound HTTPS to simulate the identity provider being unreachable.
Block Network Access To Identity Provider

Open Terminal In Sudo Mode
Try Log In With Remote User ${username}
Check That Remote User Has No Available Authentication Modes
Loading