The storage service has been removed, and replaced by a simple injected Map.

As per , we can remove the storage service and just inject the map directly into the strategy.

As pointed out, having another resolver service for this was unnecessary, instead, adding the logic via a strategy to the profile configuration (which is already a reloadable service). This is now done using the following logic:

• By default, the client identifier lookup strategy constructs a client_id value from that provided in the oidc properties file. This allows quick configuration if there is only a single client.

• If there is more than one client e.g. some kind of discovery flow is used to choose the OP, the client_id property value can be commented out, and the strategy will use a further embedded strategy to lookup the client identifier from the given issuer_id of the chosen OP.

  • The default strategy for this is backed by a storage service. Currently, an in-memory service is constructed from the same map as shown in . This would need to be added to the relying party XML by the deployer.

• This can also be overridden by specifying a client_id in a RelyingPartyOverrides profile bean for an OP. This is arguably better than having to add the map into the relying-party.xml. Although it would mean adding an override for every OP if you are dealing with more than one.

As with the client authentication resolver, a single mapping could be taken from the properties file for easier configuration.

Moving to commons project

Created a client_id resolver and started a reloadable service implementation. Uses a Storage Service backend, which by default is a simple map loaded from a user space XML file that maps between issuers and client_ids e.g.

This could be consolidated with the client authentication resolver, but as they are used in different parts of the flow, I have separated them for now. This is added to a OAuth2ClientContext which is then authoritative for the identifier of the client to use and key off in other lookups.