- v1.0.0-latest-prod
|
Important
|
This is technically a breaking change, as some methods and fields are removed/replaced.
However, most clients will not be affected - from an external perspective, API consumers will feel no difference.
Those who did extend DefaultUserOperationService will find the new implementation much more straightforward to extend and migrate to as compared to the prior version.
|
Added new /user-operations/resource endpoint that accepts a Bearer token authentication and a client ID request parameter.
This is useful in cross-domain scenarios where session cookies cannot be sent to /user-operations.
broadleaf.resource.security.oauth2.matchers now includes /user-operations/resource/** by default
Updated UserOperationService method contracts to now accept (optional) clientId parameter to support bearer token authentication case
Refactored DefaultUserOperationService
The implementation now performs its own queries for User instead of delegating to AccountIdTokenEnhancer
Deleted all references to AccountIdTokenEnhancer
Added a direct dependency on UserService
Refactored much of the code into reusable methods
Added flexibility to support both Bearer token and session token authentication when fetching user operation information
OAuth2AuthorizedClient implementation reworkThis is relevant for clients using OAuth2 login functionality (ex: 'Login with Google').
Thus far, AuthenticationServices implemented OAuth2AuthorizedClientRepository by storing the OAuth2AuthorizedClient in a BL-ACS-* cookie.
This approach had limitations that could cause issues - for example, if the token values from the provider were too large, the cookie would be rejected by the browser.
To fix this, the implementation has been fully reworked to now persist OAuth2AuthorizedClient in the AuthenticationServices database.
Here are the key changes involved:
|
Important
|
Some of these will be breaking changes from a code perspective (particularly in DefaultOAuth2AuthorizedClientRepository), but overall it should be a straightforward migration.
|
Rename AuthorizedClientService<AuthorizedClient> bean to authorizedClientEntityService, preventing a bean name clash with org.springframework.boot.autoconfigure.security.oauth2.client.servlet.OAuth2WebSecurityConfiguration.authorizedClientService
Remove OAuth2AuthorizedClientService bean definition now that bean name clash is resolved
Introduce new TenantAwareOAuth2AuthorizedClient extension of OAuth2AuthorizedClient
Introduce new OAuth2AuthorizedClientEntity (and corresponding CRUD components) to support persistence of data related to OAuth2AuthorizedClient.
|
Important
|
The new table name is The steps to create this table are automatically included in the updated
|
Rewrite existing DefaultOAuth2AuthorizedClientRepository implementation to work based off of the new DB-based persistence instead of the Cookie-based approach
Remove OAuth2AuthorizedClientRepositoryProperties (broadleaf.auth.auth-client-repository) as the properties within were only applicable to a cookie-based implementation
Update DefaultSessionAuthenticationStrategy to set new session token claim keys 3pidp_principal_name and 3pidp_client_registration_id to enable removal of the authorized client on logout
Update AuthenticationLogoutHandler to parse the new session token claim keys and use them to delete the existing OAuth2AuthorizedCient.
Introduce functionality to clean up outdated OAuth2AuthorizedClientEntity instances from the datastore
Introduce new DefaultOAuth2AuthorizedClientEntityCleanupServices component that periodically runs cleanup processes against OAuth2AuthorizedClientEntity
Introduce new OAuth2AuthorizedClientCleanupProperties under prefix broadleaf.auth.user.web.authorization.authorized-client-entity-cleanup to configure cleanup behavior
Introduce new cleanupOutdatedEntities() method in OAuth2AuthorizedClientEntityService/OAuth2AuthorizedClientEntityRepository to support pruning expired access tokens older than a particular threshold
Add seed data in auth.starter.required.data.changelog.xml to add the client-credentials grant type to the OpenAPI client
Fix a bug where the randomly generated password in an OAuth login auto-registration flow could fail password validation
Introduce a new dedicated PasswordGenerator component for generating random password values that are compliant with PasswordRequestValidator.
All implementations of AbstractAuthenticationStrategyDelegate should now use this component rather than relying on PasscodeService to generate passwords.
Fail GitHub registration attempts missing an email attribute, and default name value to email
Remove previous behavior which defaulted email to a unique string value when one was unavailable. Instead, immediately throw an error since a valid email is always required for communication with the user.
If a name value is not available from GitHub, default to using the email value.
Fixed bug where a deleted customer cannot register with the same email address
Hard delete the auth user if the corresponding customer is archived
IMPORTANT: In 2.0.0, the user is archived/soft deleted instead of hard deleted since the unique email and username constraints were also removed. However, the user must be hard deleted in 1.8.15 since the unique constraint removal cannot be back-ported into 1.8.x.
Update StatelessUtilImpl and AuthServerEntityValidator to ensure cookie names based on Auth Server name meet cookie spec requirements with respect to spaces
Introduced resource lock mechanism for the User entity to prevent race conditions between different message handlers and overwriting each other
Updated AccountMemberRoleChangeRequestHandler, CustomerPersistenceHandler, and AdminUserPersistenceHandler to lock the user entity before processing the message
The User resource lock time-to-live can be configured via broadleaf.auth.resource.lock.user-lock-ttl, which is 5 seconds by default