Description
In previous run (April/2020) with Open Liberty Operator and SSO providers, the oidc and oauth2 clients were configured with the redirect URI respectively as follows:
Recently re-running the same configuration, the respective failure appeared:
- oauth2:
[ERROR ] CWWKS5434E: The social login feature encountered an error while processing the redirect request. CWWKS5433E: The request directed to [https://acme-ola-test.apps.hemmers.os.fyre.ibm.com/ibm/api/social-login/redirect/oauth2Login] does not have a social login configuration with which it can be associated.
- oidc: (didn't have the same error msg as in above oauth2, but the browser displayed msg pointing to invalid parm in redirect URI)
After comparing the sso-oauth.xml vs. sso-oauth2.xml, and sso-oidc.xml (earlier vs. recent), it's realized the "id" has been changed without using 'Login' string (e.g, oidcLogin, oauth2Login):
<oidcLogin
id="oidc"
<oauth2Login
id="oauth2"
clientId="${SEC_SSO_OAUTH2_CLIENTID}"
old:
<oidcLogin
id="oidcLogin"
clientId="${sec_sso_oidc_clientId}"
<oauth2Login
id="oauth2Login"
clientId="${sec_sso_oauth2_clientId}"
After updating the new id in the client apps' redirect URI, the problem went away.
But would like to know why "oidc" and "oauth2" do not use the id format as rest of the sso providers:,
e.g.
https://acme-ola-test.apps.hemmers.os.fyre.ibm.com/ibm/api/social-login/redirect/facebookLogin
https://acme-ola-test.apps.hemmers.os.fyre.ibm.com/ibm/api/social-login/redirect/googleLogin
https://acme-ola-test.apps.hemmers.os.fyre.ibm.com/ibm/api/social-login/redirect/githubLogin
https://acme-ola-test.apps.hemmers.os.fyre.ibm.com/ibm/api/social-login/redirect/linkedinLogin
https://acme-ola-test.apps.hemmers.os.fyre.ibm.com/ibm/api/social-login/redirect/twitterLogin
If there is a reason "odic" and "oauth2" have to use the current id format, then hope the doc can give a little explanation or reminder to prevent the regression as seen here:
https://github.com/OpenLiberty/open-liberty-operator/blob/master/doc/user-guide.adoc
