What is the desired functionality that you are missing?

In Optimize, we fetch user group data from its connected engines. This is done both as a scheduled job to populate Optimize's cache, and also on demand. In both cases, it serves for authorization purposes and largely in the context of managing access to collections within Optimize.

However, in some cases, this might not be possible or necessary to fetch this data. Instead, Optimize could extract this information from the token. A user would then only be able to access collections for which a group they belong to (according to the information in the token) has been granted access. This would remove the requirement for fetching groups from the engine.

As a side note, we would also need to, in this case, remove the direct fetching of a given group based on user input into the field (if the item is not in Optimize's cache). Essentially this would remove group validation. Instead, Optimize would accept any input, and grant access according to whether or not a given user has access to the specified group.

Similarly, user information is not displayed if an SSO plugin is used for authentication and the user profile request cannot be served. Likewise, this wouldn't be necessary if the same information could be extracted from the token.

Currently, the interface for the SSO plugin is limited and only allows setting of the authentication user's ID. For additional information, we may need to change the interface of the plugin

The linked support ticket contains more information.

There's also a related community forum request here where migrating Optimize to a spring boot application could be valuable (OPT-4331)
Which problem are you going to solve with this functionality?

1. User information cannot be displayed correctly in Optimize
2. Optimize doesn't know which groups the current user is a member of, preventing group-based authorization

Hints:

• We might be able to drop the cache entirely if this token based group/user profile setting is configured
• If we change the interface of the SSO plugin to deliver new fields (user name, groups etc.), we should ensure that this is either a new plugin or that existing plugins aren't broken by the changes
• We should check whether or requests to the engine for group information can be removed
• This might need to be enabled/disabled via configuration, as simply having an SSO plugin configured alone isn't enough to tell Optimize whether or group membership should depend on the token or whether the connected engines should be used
• The user groups and user name can be added as claims in the JWT
• We should investigate as to whether any other fields are required/useful
• If we change the interface (or possible behaviours) of the SSO plugin, we should document these changes too