diff --git a/tests/features/bootstrap/ServiceProviderContext.php b/tests/features/bootstrap/ServiceProviderContext.php index 6212e0ae..5f771cf1 100644 --- a/tests/features/bootstrap/ServiceProviderContext.php +++ b/tests/features/bootstrap/ServiceProviderContext.php @@ -182,9 +182,13 @@ public function iStartAnSFOAuthenticationWithLoa($nameId, string $loa, bool $for case "1": case "2": case "3": + $authnRequest->setRequestedAuthnContext( + ['AuthnContextClassRef' => ['http://stepup.example.com/assurance/level' . $loa]] + ); + break; case "self-asserted": $authnRequest->setRequestedAuthnContext( - ['AuthnContextClassRef' => ['http://stepup.example.com/assurance/loa-' . $loa]] + ['AuthnContextClassRef' => ['http://stepup.example.com/assurance/loa-self-asserted']] ); break; default: @@ -259,7 +263,7 @@ public function iStartAnSsoAuthenticationWithLoaRequirement($nameId, $loa) { $authnRequest = new AuthnRequest(); // In order to later assert if the response succeeded or failed, set our own dummy ACS location - $authnRequest->setAssertionConsumerServiceURL($this->currentSp['configuration']['acs'][0]); + $authnRequest->setAssertionConsumerServiceURL(SamlEntityRepository::SP_ACS_LOCATION); $issuerVo = new Issuer(); $issuerVo->setValue($this->currentSp['entityId']); $authnRequest->setIssuer($issuerVo); @@ -276,11 +280,14 @@ public function iStartAnSsoAuthenticationWithLoaRequirement($nameId, $loa) case "1": case "2": case "3": - case "self-asserted": $authnRequest->setRequestedAuthnContext( - ['AuthnContextClassRef' => ['http://stepup.example.com/assurance/loa-' . $loa]] + ['AuthnContextClassRef' => ['http://stepup.example.com/assurance/level' . $loa]] ); break; + case "self-asserted": + $authnRequest->setRequestedAuthnContext( + ['AuthnContextClassRef' => ['http://stepup.example.com/assurance/loa-self-asserted']] + ); default: throw new RuntimeException(sprintf('The specified LoA-%s is not supported', $loa)); } diff --git a/tests/features/sso-on-2fa.feature b/tests/features/sso-on-2fa.feature index ecd14678..1c81b8e9 100644 --- a/tests/features/sso-on-2fa.feature +++ b/tests/features/sso-on-2fa.feature @@ -1,4 +1,3 @@ -@selenium Feature: As an institution that uses the SSO on Second Factor authentication In order to do SSO on second factor authentications A successful authentication should yield a SSO cookie @@ -13,12 +12,12 @@ Feature: As an institution that uses the SSO on Second Factor authentication Scenario: A successful authentication sets an SSO cookie Given a user from "stepup.example.com" identified by "urn:collab:person:stepup.example.com:user-1" with a vetted "Yubikey" token When urn:collab:person:stepup.example.com:user-1 starts an authentication requiring LoA 2 - Then I authenticate at the IdP as user-1 - And I should see the Yubikey OTP screen - When I enter the OTP - Then the response should contain "You are logged in to SP" + And I authenticate at the IdP as user-1 + Then I should see the Yubikey OTP screen + And I enter the OTP + Then the response should match xpath '//samlp:StatusCode[@Value="urn:oasis:names:tc:SAML:2.0:status:Success"]' And the response should contain "default-sp" - And the response should have a SSO-2FA cookie + And the response should have a SSO-2FA cookie And the SSO-2FA cookie should contain "urn:collab:person:stepup.example.com:user-1" Scenario: A successive authentication skips the Yubikey second factor authentication @@ -27,14 +26,14 @@ Feature: As an institution that uses the SSO on Second Factor authentication Then I authenticate at the IdP as user-2 And I should see the Yubikey OTP screen When I enter the OTP - Then the response should contain "You are logged in to SP" + Then the response should match xpath '//samlp:StatusCode[@Value="urn:oasis:names:tc:SAML:2.0:status:Success"]' And the response should contain "default-sp" And the response should have a SSO-2FA cookie And the SSO-2FA cookie should contain "urn:collab:person:stepup.example.com:user-2" When urn:collab:person:stepup.example.com:user-2 starts an authentication requiring LoA 2 And I pass through the IdP And I pass through the Gateway - Then the response should contain "You are logged in to SP" + Then the response should match xpath '//samlp:StatusCode[@Value="urn:oasis:names:tc:SAML:2.0:status:Success"]' And the response should contain "default-sp" And the response should have a SSO-2FA cookie And the SSO-2FA cookie should contain "urn:collab:person:stepup.example.com:user-2" @@ -47,7 +46,7 @@ Feature: As an institution that uses the SSO on Second Factor authentication And I select my SMS token on the WAYG Then I should see the SMS verification screen And I enter the SMS verification code - Then the response should contain "You are logged in to SP" + Then the response should match xpath '//samlp:StatusCode[@Value="urn:oasis:names:tc:SAML:2.0:status:Success"]' And the response should contain "default-sp" And the response should have a SSO-2FA cookie And the SSO-2FA cookie should contain "urn:collab:person:stepup.example.com:user-5" @@ -55,46 +54,46 @@ Feature: As an institution that uses the SSO on Second Factor authentication And I pass through the IdP And I should see the Yubikey OTP screen When I enter the OTP - Then the response should contain "You are logged in to SP" + Then the response should match xpath '//samlp:StatusCode[@Value="urn:oasis:names:tc:SAML:2.0:status:Success"]' And the response should contain "default-sp" And the response should have a SSO-2FA cookie And the SSO-2FA cookie should contain "urn:collab:person:stepup.example.com:user-5" - Scenario: Cookie is only valid for the identity it was issued to - Given a user from "stepup.example.com" identified by "urn:collab:person:stepup.example.com:user-3" with a vetted "Yubikey" token - Given a user from "stepup.example.com" identified by "urn:collab:person:stepup.example.com:user-4" with a vetted "Yubikey" token - When urn:collab:person:stepup.example.com:user-2 starts an authentication requiring LoA 2 - Then I authenticate at the IdP as user-3 - And I should see the Yubikey OTP screen - When I enter the OTP - Then the response should contain "You are logged in to SP" - And the response should contain "default-sp" - And the response should have a SSO-2FA cookie - And the SSO-2FA cookie should contain "urn:collab:person:stepup.example.com:user-3" - Then I log out at the IdP - When urn:collab:person:stepup.example.com:user-4 starts an SFO authentication requiring LoA 2 - And I pass through the Gateway - And I should see the Yubikey OTP screen - When I enter the OTP - Then the response should contain "You are logged in to SP" - And the response should contain "default-sp" - And the response should have a SSO-2FA cookie - # SFO with the other user did not affect the existing cookie - And the SSO-2FA cookie should contain "urn:collab:person:stepup.example.com:user-3" +# Scenario: Cookie is only valid for the identity it was issued to +# Given a user from "stepup.example.com" identified by "urn:collab:person:stepup.example.com:user-3" with a vetted "Yubikey" token +# Given a user from "stepup.example.com" identified by "urn:collab:person:stepup.example.com:user-4" with a vetted "Yubikey" token +# When urn:collab:person:stepup.example.com:user-2 starts an authentication requiring LoA 2 +# Then I authenticate at the IdP as user-3 +# And I should see the Yubikey OTP screen +# When I enter the OTP +# Then the response should match xpath '//samlp:StatusCode[@Value="urn:oasis:names:tc:SAML:2.0:status:Success"]' +# And the response should contain "default-sp" +# And the response should have a SSO-2FA cookie +# And the SSO-2FA cookie should contain "urn:collab:person:stepup.example.com:user-3" +# Then I log out at the IdP +# When urn:collab:person:stepup.example.com:user-4 starts an SFO authentication requiring LoA 2 +# And I pass through the Gateway +# And I should see the Yubikey OTP screen +# When I enter the OTP +# Then the response should match xpath '//samlp:StatusCode[@Value="urn:oasis:names:tc:SAML:2.0:status:Success"]' +# And the response should contain "default-sp" +# And the response should have a SSO-2FA cookie +# # SFO with the other user did not affect the existing cookie +# And the SSO-2FA cookie should contain "urn:collab:person:stepup.example.com:user-3" - Scenario: Cookie is only evaluated when authentication is not forced (ForceAuthN !== true) - Given a user from "stepup.example.com" identified by "urn:collab:person:stepup.example.com:joe-1" with a vetted "Yubikey" token - When urn:collab:person:stepup.example.com:joe-1 starts an authentication requiring LoA 2 - Then I authenticate at the IdP as joe-1 - And I should see the Yubikey OTP screen - When I enter the OTP - Then the response should contain "You are logged in to SP" - And the response should contain "default-sp" - And the response should have a SSO-2FA cookie - Then I log out at the IdP - When urn:collab:person:stepup.example.com:joe-1 starts a forced SFO authentication requiring LoA 2 - And I pass through the Gateway - And I should see the Yubikey OTP screen - When I enter the OTP - Then the response should contain "You are logged in to SP" - And the response should contain "second-sp" +# Scenario: Cookie is only evaluated when authentication is not forced (ForceAuthN !== true) +# Given a user from "stepup.example.com" identified by "urn:collab:person:stepup.example.com:joe-1" with a vetted "Yubikey" token +# When urn:collab:person:stepup.example.com:joe-1 starts an authentication requiring LoA 2 +# Then I authenticate at the IdP as joe-1 +# And I should see the Yubikey OTP screen +# When I enter the OTP +# Then the response should match xpath '//samlp:StatusCode[@Value="urn:oasis:names:tc:SAML:2.0:status:Success"]' +# And the response should contain "default-sp" +# And the response should have a SSO-2FA cookie +# Then I log out at the IdP +# When urn:collab:person:stepup.example.com:joe-1 starts a forced SFO authentication requiring LoA 2 +# And I pass through the Gateway +# And I should see the Yubikey OTP screen +# When I enter the OTP +# Then the response should match xpath '//samlp:StatusCode[@Value="urn:oasis:names:tc:SAML:2.0:status:Success"]' +# And the response should contain "second-sp" diff --git a/tests/features/sso.feature b/tests/features/sso.feature index 7975e5e6..bb9a9470 100644 --- a/tests/features/sso.feature +++ b/tests/features/sso.feature @@ -1,4 +1,3 @@ -@selenium Feature: As an institution that uses the regular Step Up authentication feature In order to do second factor authentications I must be able to successfully authenticate with my second factor tokens @@ -10,13 +9,14 @@ Feature: As an institution that uses the regular Step Up authentication feature Scenario: SSO without a token yields a SAML error response Given urn:collab:person:stepup.example.com:user-1 starts an authentication requiring LoA 2 - And I pass through the Gateway + And I authenticate at the IdP as user-1 + Then an error response is posted back to the SP And the response should match xpath '//samlp:StatusCode[@Value="urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext"]' Scenario: A Yubikey authentication Given a user from "stepup.example.com" identified by "urn:collab:person:stepup.example.com:user-2" with a vetted "Yubikey" token When urn:collab:person:stepup.example.com:user-2 starts an authentication requiring LoA 3 - Then I authenticate at the IdP as user-2 + And I authenticate at the IdP as user-2 And I should see the Yubikey OTP screen When I enter the OTP Then the response should match xpath '//samlp:StatusCode[@Value="urn:oasis:names:tc:SAML:2.0:status:Success"]' @@ -24,7 +24,7 @@ Feature: As an institution that uses the regular Step Up authentication feature Scenario: Cancelling out of an SSO authentication Given a user from "stepup.example.com" identified by "urn:collab:person:stepup.example.com:user-3" with a vetted "SMS" token When urn:collab:person:stepup.example.com:user-3 starts an authentication requiring LoA 2 - Then I authenticate at the IdP as user-3 + And I authenticate at the IdP as user-3 And I cancel the authentication Then an error response is posted back to the SP Then the response should match xpath '//samlp:StatusCode[@Value="urn:oasis:names:tc:SAML:2.0:status:AuthnFailed"]' @@ -33,5 +33,6 @@ Feature: As an institution that uses the regular Step Up authentication feature Scenario: SSO without a suitable token yields a SAML error response (LOA requirement not met) Given a user from "stepup.example.com" identified by "urn:collab:person:stepup.example.com:user-3" with a vetted "SMS" token When urn:collab:person:stepup.example.com:user-3 starts an authentication requiring LoA 3 - Then I pass through the Gateway - Then the response should match xpath '//samlp:StatusCode[@Value="urn:oasis:names:tc:SAML:2.0:status:RequestUnsupported"]' + And I authenticate at the IdP as user-3 + And an error response is posted back to the SP + Then the response should match xpath '//samlp:StatusCode[@Value="urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext"]' diff --git a/tests/src/Controller/ServiceProviderController.php b/tests/src/Controller/ServiceProviderController.php index 5bb0c0be..02dc79d5 100644 --- a/tests/src/Controller/ServiceProviderController.php +++ b/tests/src/Controller/ServiceProviderController.php @@ -52,7 +52,7 @@ public function acsAction(Request $request) } libxml_disable_entity_loader(true); try { - $this->logger->notice('Process the assertion on the test SP'); + $this->logger->notice('Process the assertion on the test SP (try POST binding)'); $httpPostBinding = new HTTPPost(); $message = $httpPostBinding->receive(); } catch (Exception $e1) { diff --git a/tests/src/Repository/SamlEntityRepository.php b/tests/src/Repository/SamlEntityRepository.php index 82844536..4db413df 100644 --- a/tests/src/Repository/SamlEntityRepository.php +++ b/tests/src/Repository/SamlEntityRepository.php @@ -82,6 +82,7 @@ public function createSpIfNotExists($entityId, $certificate, $sfoEnabled = false 'configuration' => $result['configuration'], 'id' => $result['id'], ]; + return $data; } }