This repository was archived by the owner on Dec 6, 2024. It is now read-only.
v4.2.0
4.2.0 (2022-01-19)
Enhanced default authentication method
Starting with the Service Workbench 4.2.0 release, the native Amazon Cognito user pool is the default authentication method, and is reflected accordingly on the application's login page (alongside your external SAML IdP integrations, if any).
Note: As a security enhancement, the internal authentication method used by Service Workbench (the legacy default authentication method) will soon be deprecated.
For more information, read Using native Amazon Cognito user pool for authentication
Customer Impact:
- You will find the default (user-customizable) configurations determining the native Amazon Cognito user pool behavior in the
main/solution/post-deployment/config/settings/.defaults.ymlfile. - If using native Amazon Cognito user pool, users can sign up for a user account, but can not access Service Workbench until they are approved by the application admin. The user addition experience on Service Workbench for native Amazon Cognito user pool is similar to that of an external IdP.
- A new admin user would be created in Service Workbench using the
rootUserEmailvalue as provided by your stage configuration. A temporary password will be available in the installation summary necessary for logging the native admin user in for the first time. - You can still log in using the
internalauthentication method by adding the text/?internalto your Service Workbench URL (for eg.https://<random_string>.cloudfront.net/?internal).
Important
- We suggest creating new users in native Amazon Cognito user pool (or an external IdP, if you use one) corresponding to their internal auth counterparts, and migrating resource permissions over to these new users.