openid-connect-generic icon indicating copy to clipboard operation
openid-connect-generic copied to clipboard

Experiencing issues using Azure AD with this plugin

Open haneef95 opened this issue 4 years ago • 6 comments

Hi,

Firstly, I have to say... This is a great plugin! Really appreciate it.

However, I'm facing some issues at present.

Desired operation

  1. Only allow users who are already on WordPress to login, as we would like to add users to WordPress manually. (link_existing_users)
  2. The common identifier should be the email address as the username in WordPress is not the same as any of the attributes in the OpenID Connect Server (Azure AD (AAD) in this case).
  3. The linking unique identifier between WordPress and AAD should be user_id and oid attributes respectively.
  4. Make use of id_token or code id_token as response_type instead of code.

Copy of the current openid_connect_generic_settings

a:25:{s:10:"login_type";s:6:"button";s:9:"client_id";s:36:"{ClientIDHere}";s:13:"client_secret";s:34:"{ClientSecretHere}";s:5:"scope";s:6:"openid";s:14:"endpoint_login";s:57:"https://login.microsoftonline.com/common/oauth2/authorize";s:17:"endpoint_userinfo";s:41:"https://graph.microsoft.com/oidc/userinfo";s:14:"endpoint_token";s:58:"https://login.microsoftonline.com/common/oauth2/v2.0/token";s:20:"endpoint_end_session";s:0:"";s:12:"identity_key";s:3:"oid";s:12:"no_sslverify";s:1:"0";s:20:"http_request_timeout";s:1:"5";s:15:"enforce_privacy";s:1:"0";s:22:"alternate_redirect_uri";s:1:"1";s:12:"nickname_key";s:4:"name";s:12:"email_format";s:7:"{email}";s:18:"displayname_format";s:6:"{name}";s:22:"identify_with_username";s:1:"0";s:16:"state_time_limit";s:0:"";s:20:"token_refresh_enable";s:1:"1";s:19:"link_existing_users";s:1:"1";s:24:"create_if_does_not_exist";s:1:"0";s:18:"redirect_user_back";s:1:"1";s:18:"redirect_on_logout";s:1:"1";s:14:"enable_logging";s:1:"1";s:9:"log_limit";s:4:"1000";}

Issues

  1. When existing users login with an email address that is in their profile, I get the identity-not-map-existing-user error. However, when create_if_does_not_exist is enabled, linking of existing users works, based on email address.

  2. The oid that can be obtained by decoding the access_token in the openid-connect-generic-last-token-response is not available in the openid-connect-generic-last-id-token-claim to be used as a linking identifier as per desire 3 above. The openid-connect-generic-subject-identity always uses the value from the sub attribute.

Could you kindly advise on how to proceed in resolving this? The first thing is more of an issue than the second.

Many thanks,

haneef95 avatar Sep 05 '20 01:09 haneef95

@haneef95 so the very first thing I see is that you are using inconsistent endpoint versions. You are using v2 of the token endpoint, and the user info endpoint, but the older version endpoint for your authorization. I'm also not seeing your tenant ID in the endpoints so it seems like you are attempting to simply authenticate via O365 and not your true Azure AD service. If you truly don't have an Azure AD tenant then you can get all of the correct configuration information for the v1 service here:

  • https://login.microsoftonline.com/common/.well-known/openid-configuration

or you can get the v2 configuration information here:

  • https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration

I have successfully configured both versions with WordPress but the identity keys are different depending on which version of the endpoints your are using, which is also why you are having problems since you are using 2 different versions. If you do have your tenant ID then the configuration information would be found like one of the following:

  • v1: https://login.microsoftonline.com/<tenant ID>/.well-known/openid-configuration
  • v2: https://login.microsoftonline.com/<tenant ID>/v2.0/.well-known/openid-configuration

Here is a working v2 example I am using with Azure AD for the user field mappings:

  • OpenID Scope: openid profile email
  • Identity Key: email
  • Nickname Key: name
  • Email Formatting: {email}
  • Display Name Formatting: {name}

timnolte avatar Sep 05 '20 02:09 timnolte

Update on issues

  1. This issue still exists

  2. I've managed to get the oid onto openid-connect-generic-last-id-token-claim now, by adding profile to the scope.

    • However, the plugin is still not treating the oid as the openid-connect-generic-subject-identity, to link with the WP user_id.
    • I tried removing the endpoint_userinfo URI, that results in openid-connect-generic-last-user-claim being a duplicate of openid-connect-generic-last-id-token-claim, as opposed to the decoded access_token from openid-connect-generic-last-token-response.
    • Since there are 3 different sets of data (access_token, id_token and userInfo), my assumption is that there needs to be an additional openid-connect-generic-last-access-token-claim WordPress meta_key to store the decoded access_token.

Thanks

haneef95 avatar Sep 05 '20 02:09 haneef95

@haneef95 what endpoints are you now using?

timnolte avatar Sep 05 '20 02:09 timnolte

@haneef95 what endpoints are you now using?

Thanks for your swift responses @timnolte.

Apologies, didn't see your first response by the time I had submitted my 2nd comment.

I have now changed my configuration as per your recommendation (I hadn't realised the v1 and v2 mismatch). Additionally, I have also changed the identity_key to email

Current config openid_connect_generic_settings

a:25:{s:10:"login_type";s:6:"button";s:9:"client_id";s:36:"xyz";s:13:"client_secret";s:34:"xyz";s:5:"scope";s:20:"openid profile email";s:14:"endpoint_login";s:62:"https://login.microsoftonline.com/common/oauth2/v2.0/authorize";s:17:"endpoint_userinfo";s:41:"https://graph.microsoft.com/oidc/userinfo";s:14:"endpoint_token";s:58:"https://login.microsoftonline.com/common/oauth2/v2.0/token";s:20:"endpoint_end_session";s:0:"";s:12:"identity_key";s:5:"email";s:12:"no_sslverify";s:1:"0";s:20:"http_request_timeout";s:1:"5";s:15:"enforce_privacy";s:1:"0";s:22:"alternate_redirect_uri";s:1:"1";s:12:"nickname_key";s:4:"name";s:12:"email_format";s:7:"{email}";s:18:"displayname_format";s:6:"{name}";s:22:"identify_with_username";s:1:"0";s:16:"state_time_limit";s:0:"";s:20:"token_refresh_enable";s:1:"1";s:19:"link_existing_users";s:1:"1";s:24:"create_if_does_not_exist";s:1:"0";s:18:"redirect_user_back";s:1:"1";s:18:"redirect_on_logout";s:1:"1";s:14:"enable_logging";s:1:"1";s:9:"log_limit";s:4:"1000";}

Update on issues

  1. This issue still exists, so, this plugin is unable to link existing WP users with the same email address (user_email) as the AzureAD email attribute in the id_token, unless create_if_does_not_exist option is enabled.

  2. openid-connect-generic-subject-identity still uses the sub attribute from the user claim, as opposed to the oid from the id_token claim or even the email from either the id_token or user claim, as that's what I've specified as the identity_key.

Thanks,

haneef95 avatar Sep 05 '20 09:09 haneef95

@haneef95 I'm going to do some testing on this. It's possible this might be related to #212

timnolte avatar Sep 06 '20 03:09 timnolte

The subject identity seems to have been hard-coded here, as opposed to it being identified based on the id key that we provide in the user interface.

I guess, sub can be the fallback if the identity_key is empty.

https://github.com/oidc-wp/openid-connect-generic/blob/f7b74892d04cafcc42368e95b80624cfa149e205/includes/openid-connect-generic-client.php#L530

haneef95 avatar Sep 09 '20 21:09 haneef95