Finish work on the SSO on 2FA feature #288
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Ignore the /app and /web folders. /app is used by ansible to deploy some certificates. And the /web folder is used to store the u2f app ID
The sso cookie: - name - type - lifetime Can be configured in the parameters.yaml They are then validated in the DI Configuration component. As they are part of the `surfnet_stepup_gateway_gateway` bundle configuration. See: https://www.pivotaltracker.com/story/show/183402574
This object contains all data we need to store SSO on the Second Factor authentication. The cookie value is used to recognize an identity, it's second factor used and the associated LoA.
The authentication, verification, encryption and decryption is implemented in this helper class. The helper in turn uses the Paragon Halite library to actually perform the crypto actions.
This is a helper class that: 1. reads and decrypts, encrypted cookie data from the configured sso cookie 2. writes encrypted data to the configured sso on 2fa cookie Goal is to limit access to the actual creation of the Cookie in the application. We use this helper to configure sane, industry standard settings for the cookie.
In order to get them to work, a host of changes where required. Most notable changes required was that the SSO authentications did not yet utilize the mock gateway remote IdP setup. It visited the SSP mock idp that is not available in this container. Trololo Next up was to configure the certificates correctly. Finally the new sso-on-2fa.feature itself could be constructed.
The cookie is created in the renderSamlResponse method of GatewayController. Serveral information is required to determine if the cookie may be created. The institution must support sso-on-2fa
That makes sure we need little/no code duplication between the SFO and SSO implementations of the Gateway auth modes.
1. By using a real SP/IdP, we can more realistically track the different authentication varieties. 2. A new SSP container is added to the docker-compose (ci) that runs the SP/IdP 3. The scenarios have been updated to authenticat on the SSP debug sp
Todo: test all preconditions are met See: https://www.pivotaltracker.com/story/show/183402734
In the process a lot of the webpack configuration was modernized. Chief amongst which was to replace TS lint with ES lint
Don't store the SSO cookie when a RA vetting procedure is handled by Gateway. Or any of the other SP's that have this explicitly configured in the middleware config. Don't try to give SSO on 2FA when one of the SPs which are configured to not evaluate the SSO cookie. This is also configured in the MW config. See: https://www.pivotaltracker.com/story/show/183511012 See: OpenConext/Stepup-Middleware#391
Don't store the SSO cookie when a RA vetting procedure is handled by Gateway. Don't try to give SSO on 2FA when one of the `gssp_allowed_sps` is used during authentication. See: https://www.pivotaltracker.com/story/show/183511012
To get the correct data into the log message. Some additional stowing of data was required on the context (state handler). See: https://www.pivotaltracker.com/story/show/183511341
1. Remove the ra_vetting_procedure_sp_metadata_url_regex config option
The required (required by SP) LoA was stored in the SSO cookie. That is not rigth, we want to store the LoA of the SF used to authenticate the rquired LoA. That LoA might be higher. An might assist the end user in not having to give another 2FA when another SP requires a higher LoA. See: https://www.pivotaltracker.com/story/show/184060757 See: https://www.pivotaltracker.com/story/show/183402542
Add the now included Utf8 encoding to the expected xml messages defined in the tests
The Adfs feature saw the ligth of some behat test improvements. Rebasing those changes into the SSO on 2FA branch caused some issues. This commit merges those changes
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is mainly used to incorporate and test all the intermediate release 4.0 and 4.1 changes with these changes.