dominik-th / matomo-plugin-LoginOIDC

external authentication services for matomo
https://plugins.matomo.org/LoginOIDC/
GNU General Public License v3.0
41 stars 29 forks source link

Support redirect URI without query string #5

Closed Jamesits closed 5 years ago

Jamesits commented 5 years ago

Azure AD doesn't support query strings in redirect URI. Is there any way to work around this?

dominik-th commented 5 years ago

Hi there,

unfortunately this isn't possible indeed. At least the the module and action parameters in the query string are mandatory for Matomo to properly route the request.

I think your best options are to either use a service such as Auth0 which can handle the communication to Azure AD (Documentation).

Or you try to get around the Azure AD redirect url limitations by letting your webserver parse a custom url such as

http(s)://<YOUR_MATOMO_URL>/LoginOIDC/callback/oidc?code=<RANDOM>&state=<RANDOM>

and forwards it to

http(s)://<YOUR_MATOMO_URL>/index.php?module=LoginOIDC&action=callback&provider=oidc&code=<RANDOM>&state=<RANDOM>

Nginx might be able to do it.

If you succeed, please let me know so I can add it to the FAQ.

Jamesits commented 5 years ago

Auth0 (with Azure AD support) is a paid service while Azure AD is a free service so I guess Auth0 is not an option in my case.

I did some experiments. The biggest problem is that when I click on the button on Matomo login page, it redirects to the OAuth provider with the original callback URL, so the OAuth provider will fail to verify callback URL before I can even do the redirection. Is there any straightforward workaround on this?

dominik-th commented 5 years ago

Oh, I forgot about that part!

For testing purposes you should edit this file https://github.com/dominik-th/matomo-plugin-LoginOIDC/blob/master/Controller.php#L315 and just hardcode the redirect url you want to use.

It is in your ./matomo/plugins/LoginOIDC/Controller.php

If it works, I will add an option to manually override the redirect url in the settings.

Jamesits commented 5 years ago

Now I can correctly redirect but I always get an "Unexpected response from OAuth service." on login page.

dominik-th commented 5 years ago

Try to add a var_dump($response); above these lines and post the output:

https://github.com/dominik-th/matomo-plugin-LoginOIDC/blob/master/Controller.php#L199

https://github.com/dominik-th/matomo-plugin-LoginOIDC/blob/master/Controller.php#L219

Jamesits commented 5 years ago

I got string(212) "{ "error": { "code": "BadRequest", "message": "Invalid request.", "innerError": { "request-id": "f78e375f-f81b-4e06-8593-2e90393efb63", "date": "2019-06-11T15:50:43" } } }"

dominik-th commented 5 years ago

If you are sure the token url and userinfo url are correct (you should be able to find them, in the openid-configuration) I will try to reproduce the problem later tonight!

Jamesits commented 5 years ago

Now I'm getting "User not found. OAuth registrations are not supported.", so I guess OAuth works but the sub claim is not what your plugin expects. Azure AD sends sub claim as a GUID, how can I map this to a user?

dominik-th commented 5 years ago

How did you fix the previous issue? Was it an incorrect url?

You can link your remote account and the local Matomo account in your user settings: https://<YOUR_MATOMO_URL>/index.php?module=UsersManager&action=userSettings&idSite=1&period=range&date=last30

Jamesits commented 5 years ago

The OAuth 2.0 v2 endpoints provided by Azure AD does not work. I used the v1 endpoints and it worked well. The requirement to create user manually then link them to an OAuth identity is strange... but it works for now.

My config for reference:

Nginx config:

server {
    # ...
    rewrite ^/oidc/callback /index.php?module=LoginOIDC&action=callback&provider=oidc redirect;
    # ...
}

And a hardcoded callback URL.

dominik-th commented 5 years ago

Glad to hear it worked.

I will add an option to set the callback url manually in the next release.


About the linking process: I never had the user creation in mind when I created the plugin. I think most Matomo instances aren't public and have a fixed set of users, so it wouldn't make a big difference.

But I see the use of it and there is #4 if anyone wants to help.

Jamesits commented 5 years ago

Yes, Matomo should have a fixed set of users; but what makes OAuth so widely deployed in enterprise is the ability to manage users centrally. (At least when you disable a user in OAuth provider, they won’t be able to login via any other method to any system.) Also current model makes it hard for system admin to pre-bind a user to its OAuth identity – the user have to do it theirselves.

dominik-th commented 5 years ago

In 0.1.3 you can set a custom redirect uri in the plugin settings.

marco27384 commented 5 years ago

In 0.1.3 you can set a custom redirect uri in the plugin settings.

@dominik-th

That is correct, and very glad you worked on this. I can set a custom redirect uri (especially handy when it comes to Azure that doesn't accept query string (for good reasons) in the redirect uri.

Custom Redirect URI https://mymatomourl.com/oidc/callback Redirect configured in Azure App Registration https://mymatomourl.com/oidc/callback

This seems now to work fine. However, the Link Account button doesn't seem to do what is required. After clicking, I get to the page that I have been successfully signed in. Returning to the website brings me back to the settings.

Any clues?

dominik-th commented 5 years ago

Did you configure Nginx to redirect https://mymatomourl.com/oidc/callback properly?

https://github.com/dominik-th/matomo-plugin-LoginOIDC/issues/5#issuecomment-500922979

marco27384 commented 5 years ago

I am running Matomo as a container based on a Bitnami image.

On Jul 30, 2019, at 12:29 AM, Dominik Thiemermann notifications@github.com<mailto:notifications@github.com> wrote:

Did you configure Nginx to redirect https://mymatomourl.com/oidc/callback properly?

5 (comment)https://github.com/dominik-th/matomo-plugin-LoginOIDC/issues/5#issuecomment-500922979

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/dominik-th/matomo-plugin-LoginOIDC/issues/5?email_source=notifications&email_token=ACOYDWNLH6EDEICH35AJFCLQB5VL5A5CNFSM4HVPFVFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3CGCSA#issuecomment-516186440, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACOYDWP5IKUKZRVEHKSGFQLQB5VL5ANCNFSM4HVPFVFA.

This e-mail, including attachments, is intended for the person(s) or company named and may contain confidential and/or legally privileged information. Unauthorized disclosure, copying or use of this information may be unlawful and is prohibited. If you are not the intended recipient, please delete this message and notify the sender. All incoming and outgoing e-mail messages are stored in the Swiss Re Electronic Message Repository. If you do not wish the retention of potentially private e-mails by Swiss Re, we strongly advise you not to use the Swiss Re e-mail account for any private, non-business related communications.

dominik-th commented 5 years ago

It looks like the Bitnami image is using Apache as a webserver which I am not too familiar with.

Maybe you figure out how redirect incoming requests using a .htaccess file. If you do, please let me know so I can add it to the FAQ.

Try something like this

RewriteEngine On
RewriteRule ^/oidc/callback /index.php?module=LoginOIDC&action=callback&provider=oidc [QSA, R]
marco27384 commented 5 years ago

Thanks @dominik-th

With the Bitnami Matomo image, I cannot modify the webserver configuration (if that would be available, it would be simple enough as you outlined also with the nginx url rewrite, of course). Also, I cannot create a custom docker image. Hence I rely on the redirect uri as part of the LoginOIDC Plugin to do the necessary step, e.g. create a folder with an index.php to perform the redirect.

Any other ideas?

dominik-th commented 5 years ago

If you are using a reverse proxy in front of Matomo you might be able to add the redirect there or create an extra nginx container just for this job.