Broadleaf Microservices
  • v1.0.0-latest-prod

Auth Release Notes for 1.8.14

New Features & Notable Changes

  • Added support for resolving Applications by context path.

    • This includes new properties for configuring the redirect URIs for Authorized Clients generated when a new Application is created—note the {identifier} template variable that will be replaced with the application’s identifier.

      Example new properties
      broadleaf:
        auth:
          server-creation-defaults:
            default:
              context-path-default-client-redirect-uri: 'https://localhost:8456/{identifier}'
              context-path-default-redirect-uris:
                - 'https://localhost:8456/{identifier}'
                - 'https://localhost:8456/{identifier}/'
                - 'https://localhost:8456/{identifier}/callback'
                - 'https://localhost:8456/{identifier}/silent-callback.html'
  • Added new property to AuthorizedClient to control whether the URL to redirect from the impersonation endpoint to the consume-token endpoint should be relative (remain on same domain) or redirect through the storefront URL defined in the impersonation request as redirect_url.

    • This is visible in the "Advanced" group on the AuthorizedClient form in the Admin.

  • Added redirectToLogin param to requested redirect_url (to storefront) when the Auth Client is set up to use refresh token rotation so that the frontend app knows to initiate a login-with-redirect request after successful impersonation so that the auth context is initialized in the app correctly.

  • New permissions and scopes added to Cart Operations and Catalog Browse clients to allow communication with Customer Segment Endpoint.

  • Added support for storing additional attributes from the Customer onto the User and including in auth token claims

    • This is to allow additional attributes like phone number to be included since such may be commonly targeted by Customer Segments, and it is more efficient to include them as claims than to make additional calls to Customer Service to retrieve them later.

    • By default, only phone number is included in this additional mapping.

      Example usage
      broadleaf:
        auth:
          user:
            mapping:
              customer-mappings:
                  # the name of the attribute on the User where the value is stored
                - attribute-name: phone_number
                  # the JSON path to the value on the Customer object
                  value-path: phone.phoneNumber
                  # if included as a claim, then the claim uses the attribute name defined in snake case: so if phoneNumber it becomes phone_number
                  include-as-token-claim: true

New Seed Data

Permissions and Scopes for Dynamic Customer Segments

New permissions and scopes have been added and should be inserted into the auth database with the following SQL:

Example 1. Required
-- New scopes and permissions for Cart Ops and Catalog Browse clients

INSERT INTO blc_client_permissions (id, permission) VALUES ('cartopsclient', 'READ_CUSTOMER_SEGMENT');
INSERT INTO blc_client_permissions (id, permission) VALUES ('catalogbrowseclient', 'READ_CUSTOMER_SEGMENT');

INSERT INTO blc_client_scopes (id, scope) VALUES ('cartopsclient', 'CUSTOMER_SEGMENT');
INSERT INTO blc_client_scopes (id, scope) VALUES ('catalogbrowseclient', 'CUSTOMER_SEGMENT');
Example 2. Optional
INSERT INTO blc_security_scope (id, name, open) VALUES ('-91', 'CUSTOMER_SEGMENT_RESOLVER', 'N');
INSERT INTO blc_user_permission (id, archived, last_udpated, name, is_account_perm, user_assignable) VALUES ('-132', 'N', CURRENT_TIMESTAMP, 'READ_CUSTOMER_SEGMENT_RESOLVER', 'N', 'Y');
INSERT INTO blc_permission_scope (id, permission, is_permission_root, scope_id) VALUES ('-137', 'CUSTOMER_SEGMENT_RESOLVER', 'Y', '-91');
INSERT INTO blc_client_scopes (id, scope) VALUES ('openapi', 'CUSTOMER_SEGMENT_RESOLVER');
INSERT INTO blc_client_permissions (id, permission) VALUES ('openapi', 'READ_CUSTOMER_SEGMENT_RESOLVER');

Bug Fixes

  • Fixed response from /user-operations endpoint returning permissions for all accounts for a user rather than just the requested one or its ancestors.

  • Prevented more than one Authorized Client from being assigned to the same application

  • Prevented multiple authorized clients with the same clientId being created. Such a case causes query exceptions that expect a single result.