Multi-configuration is possibile?

[gfsoluzioni]

Hi, how can I create an additional key with a different access configuration?

[timnolte]

So I think what you really want is to setup role mapping instead of trying to leverage multiple client application configurations.

[timnolte]

What IDP are you using?

[DamChtlv]

I'm in a case where i need multiple configurations also:

• I have an IDP for my frontend (which users gets role "subscriber") and is needed because some posts are required to be logged-in to be viewed.

• I have another IDP for my backend (which users gets role "contributor/editor/administrator") and are only for editor / administration purposes

2 IDP are required because it's 2 different user directory / lists which can't be merged.

For now, i made an option page to register the 2 IDP configs fields (client id, client secret, endpoints urls...) for each
I went with updating the openid-connect-generic-auth-url with the correct client_id & endpoint but how to deal with
the others settings (client secret...)?
Or maybe i can init multiple instances of OpenID_Connect_Generic_Client, the defaut one could be for the frontend, and a additional one for the backend? Would that work?

I'm curious how you would approach that / your recommandations @timnolte :)

[timnolte]

I'll have to do some thinking on this, and reviewing the specs & authentication flow to see how this might be accomplished. My initial thought is if you can setup a new IDP that is a proxy for your other 2 IDPs. I'm pretty sure that both AWS Cognito and Keycloak can be setup as an IDP proxy. That would allow you to setup 1 IDP configuration in the plugin but still keep your separate IDPs & user lists.

https://www.keycloak.org/docs/latest/server_admin/#_identity_broker

https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-oidc-idp.html

[DamChtlv]

IDP proxy is a good idea, but sadly is not possible in my case (would take too much time to arg / setup / be validated in my organisation).

Update:
I managed to make it work like i want but i had to make a new class that is a "slightly edited copy" of OpenID_Connect_Generic_Client_Wrapper, here is what i did (if that can help someone) :

1. Made an option page to register my own fields / settings (because for my 2 IDP, i also have multiple env for each of them: dev, staging, prod...), so i easily need a lot of fields 😅
2. Made a new instance of settings: $frontend_settings = new OpenID_Connect_Generic_Option_Settings(...)
3. Made a new instance of logger: $frontend_logger = new OpenID_Connect_Generic_Option_Logger(...)
4. Made a new instance of client: $frontend_client = new OpenID_Connect_Generic_Client(...)
5. Made a copy of client wrapper class into my own class with few adjustements (extends wasn't possible because of the way $client is grabbed in authentication_request_callback... or maybe i did something wrong, i'm quite annoyed to have to "hardcode" this class which makes it less safe in the future with updates 😕):
   $frontend_client_wrapper = MyPersonal_OpenID_Connect_Client_Wrapper::register( $frontend_client, $frontend_settings, $frontend_logger )
6. The important part to edit for me is this one (because i'm using the same callback / redirect_uri for my 2 IDP):

// INFO: priority 5 because we need to be before the plugin (which is at 10) to be able to handle our logic first
add_action( 'wp_ajax_openid-connect-authorize', array( $client_wrapper, 'authentication_request_callback' ), 5 );
add_action( 'wp_ajax_nopriv_openid-connect-authorize', array( $client_wrapper, 'authentication_request_callback' ), 5 );

6. I also edited public function error_redirect() to use home_url() instead of wp_login_url() (makes more sense in my case since i keep the native WP login only for backend SSO) and i display login error / message inside a banner or modal on frontend (maybe a filter there could be a good idea)

[timnolte]

Yeah, that aspect of modifying URLs is the part that concerns me in how to handle some of that. I think given your ability to leverage the plugin classes to write your own code to get the functionality you need is something I can look at refactoring the plugin to make it easier to do what you want to do.

Often with these types of requests my concerns are trying to bake in some of these advanced usages for people to use it without any development. That turns into a higher maintenance and support overhead as there always seems to be additional edge cases that people want that make the code even harder to maintain and support. I'd much rather provide hooks and functionality so that developers can extend the plugin functionality to suit their specific needs.

[DamChtlv]

@timnolte I can totally understand that advanced requests make the maintenance harder, also i forgot to tell you that you did a great job on this plugin! After looking around and testing a few, it was the one that did stand out because it had enough flexibility (actions, filters) so thanks for that :)