#647 support proxy-auth as an authentication mechanism

[Dominik Meyer]

Hi there,

I have been using Wikindx in the past and even created a container image for running it. But unfortunatly because Wikindx only supports its own authentication and LDAP I had to stop using it as myself and the university I am working for totally rely on Open ID Connect and Oauth authentication today. There is no LDAP server accessible anymore. OIDC and Oauth2 servers in general provide a simple process for user management and Multi Factor authentication.

I am trying to reevaluate using Wikindx for a new project of mine but I need centralized authentication.

I totally understand that implementing oauth2 or ODIC might disrupt your authentication process. Other projects have the same problem, They provide "proxy-auth" authentication in which the authentication process is done by a proxy server in front of the application. The proxy server is
providing the username of the authenticated user in an HTTP Variable like HTTP_REMOTE_USER to the application.
A typical proxy server for suche setups is for example oauth2-proxy. I am already using it for authenticating other applications.
There is one small security problem with proxy-auth as there is a gap between the application and the
proxy server in which attackers might inject false authentication. But in general when application and proxyserver running on the same server or within the same container environment or within kubernetes the risk is very small.

Would it be feasible and easy to implement such authentication within Wikindx?
Unfortunatly I am an VHDL and C++ developer and I have no experience with PHP otherwise
I would try to come up with a module or plugin.

Thanks for the great work

best regards
Dominik

[Stéphane Aulery]

Hi Dominik,

Thanks for your feedback.

We implement the methods when they are requested by users and if we have the means. Thanks to a user (who is also a system administrator) we were able to develop the LDAP connector.

With the current architecture this is not possible in the form of a plugin. You have to do it in the core. I don't have experience with oauth2 and ODIC but I don't see why this wouldn't be feasible.

oauth2 authentication shouldn't be difficult. The trickiest part is the cooperation of all the authentication modes.

If you would like to participate in the implementation of this feature, you are welcome.

Regards,

[Dominik Meyer]

Hi Stéphane,
for proxy-auth you do not need any experience with oauth2 or OIDC. In general proxy-auth uses the feature of http-auth. If you are using http-auth of any webserver the logged in user will be provided within the http response header for example just as HTTP_REMOTE_USER.
If you run a wikindx instance on apache or nginx and add http-auth to the location of wikindx you will get such an http repsonse header. So for testing purposes that is enough. I can provide an oauth2-proxy instance for testing purposes if that is helpful and also a keycloak realm which is providing OIDC to that oauth-proxy instance. providing you access to a running wikindx in this setup is a bit harder for me as I am deploying everything in my kubernetes cluster. But I can find a solution for that.

best regards
Dominik

[Stéphane Aulery]

So I didn't quite understand. You would want authentication with proxy-auth instead of direct OIDC/Oauth2.

To give me inspiration, what other Open Source application (in PHP if possible) do you use with proxy-auth?

[Dominik Meyer]

Well, that was my suggestion, as you already denied a request for oauth support and I wanted to find a solution which is easy and fast to implement.

I use e.g. https://github.com/grocy/grocy behind proxy-auth

[Stéphane Aulery]

Are you referring to ticket [#261]?

I was waiting for a request to arise so I could put my efforts elsewhere in the meantime.

I propose to reopen the original ticket and will consider implementing both methods.

---

proxy-auth is very simple to use but it is just a flag or indicator for the software. I have to think about the behavior that the software should adopt when this flag appears and disappears depending on the current connection state.

I hope to find this in other software to get an idea of the behavior adopted in general.

Maybe you can give me some information on that?

Am I wrong in thinking this is like SSO? User does not need to enter password?

[Dominik Meyer]

Hi,

yes I was referring to that ticket.

---

oauth and OIDC are both used for SSO because they provide an authentication cookie to the applications. In case of proxy-auth it is not a cookie but an http header field.

I think, that when not having the flag or the information that the authentication has already been made, Wikindx can just display its normal authentication page or,
depending if you want to make it configurable, can just present access denied.
If the flag or the information about an already logged in user is available it can just think of it as authenticated. Perhaps, depending on your implementation, you have to create a "local" user on the first login. I think grocy is doing the later.
After login through proxy-auth there is a local user I can give access rights to or create an API token for. It it obvious that there are limitations with proxy-auth. There is no means to provide group information and such things, so that has to still be managed by Wikindx. That would be not the case if you directly implement OIDC as you get all user, group, and role information within the authentication cookie.

A good practise of others projects have been:
- to make the HTTP Header Field, holding the username, configurable
- provide a username which is made administrator on first login (perhaps this can be intregrated into your installation flow)

best regards
Dominik

[Stéphane Aulery]

ODIC is totally different from oauth?

[Dominik Meyer]

I think they are similar but OIDC is the more modern protocol.

[Stéphane Aulery]

I'm asking this because I'm surprised that OIDC specifies the group and role.

We could implement the 3 methods starting with proxy-auth. We are finalizing the next version so we will not make progress on this ticket before February/March.

If it's urgent I can DIY a proxy-auth patch for the current version (6.7.2). So you can wait until a future version is released.

Beyond that. Would you like to contribute one of these three connectors yourself, or help me implement and test it (contributing will not commit you to maintaining the functionality forever!!!)?

---

Are you https://github.com/byterazor?

I'm not a docker user but I know the general interest in containers. Would you be interested in building an official image for the project? An image that can be published with each release.

[Dominik Meyer]

Hi there,

sorry for my very late reply but I had family issues to solve and two research projects to get new funding for so my time for administrative projects has been very limitted.

At the moment it is not that urgant to get it running as I have to ensure continous funding of some of my team members. But I can help you test.
My PHP programming skills are very very rusty as I am more into VHDL and Assembler coding these days.

Yeah that is my github account and there is already a docker image published on docker.io (https://hub.docker.com/repository/docker/byterazor/wikindx/general) .

Being repsonsible for an official image is a huge responsibility and I do not know if I will find the time. I have a nearly two year old daughter at home and my priorities are set for the next years :D

[Stéphane Aulery]

Hi Dominik,

You are welcome. This is a free project and there is no obligation for you or us. Contribute to your immediate satisfaction or needs.

For the docker, can we reuse your recipe under a more permissive license (ISC)?

As the functionality you are requesting concerns a sensitive part I would like to add it if you help me test it in real conditions when it is ready. I don't want to open a security hole.

Regarding OIDC and Oauth2 I found a good PHP library. However, after evaluating the protocol in depth I noticed that it is very poorly standardized. In practice this means that the library requires an additional module per authentication provider that we cannot maintain ourselves (the WIKINDX developers) because it will be specific to each university, network, etc.

The effort required for this system to be programmable by a user is considerable while the code has every chance of not being maintained correctly.

However, you could test the connection on your private network with the league/oauth2-client library and the Auth0 generic riskio/oauth2-auth0 module.

If this works, I'll be willing to provide the configuration screen for this module for a generic OAuth method.

If you cannot test it yourself and your server is public or you can give me access via VPN with an access account in my name, then I will do the tests myself.

Regards,

[Dominik Meyer]

Hi,

I thought that MIT and ISC have no difference in their permissivness ? You can do what ever you want with MIT ...

I do not understand what kind of additional module would need to be maintained by a university? I am using OIDC at home for most of my self hosted infrastructure and I am not maintaining any code for doing that.
I just set up an OIDC provider like Keycloak and configure the OIDC enabled applications to use the keycloak provided https API.
I am not so used to oauth2 but my understanding has been that OIDC is about authentication and oath2 about authorization?

My keycloak server is accessible from the internet and I can also spin up a wikindx server within minutes and provide external access.

best regards
Dominik

[Stéphane Aulery]

I thought that MIT and ISC have no difference in their permissivness ? You can do what ever you want with MIT ...

On https://github.com/byterazor/docker-wikindx it's GPL 2.0.

[Stéphane Aulery]

I do not understand what kind of additional module would need to be maintained by a university?

I can't guess if you operate an infrastructure on your own, if you use a provider such as Google or Github or if you integrate WIKINDX into the infrastructure of an organization (University, company, ...). In any case when I consider things I must take both scenarios into account.

By consulting the pages https://oauth2-client.thephpleague.com/providers/league/ and https://oauth2-client.thephpleague.com/providers/thirdparty/ I see that there are modules for each provider, and a generic Auth0.

These modules are extensions (in PHP code) of the league/oauth2-client library. Perhaps for your case a general module and configuration will be enough but if another user asks to interface with Github I must offer a way for the administrator to configure this provider and for users to use it.

In the case of an organization with a private network I do not know how I should implement the writing of a PHP module for additional providers or if I can make this configurable.

If for example you authorize a user on your WIKINDx and they have a personal Keycloak like you. Is it legitimate to allow him to configure a method of access to his Keycloak himself?

My keycloak server is accessible from the internet and I can also spin up a wikindx server within minutes and provide external access.

I also discovered Keycloak during my research and it interests me a lot. At one point I was planning to set up my own public authentication server for WIKINDX users and Keycloak seems a good option.

If you can provide me with an account on your Keycloak to do some testing I would be happy to explore the subject.

[Mark Grimshaw]

Thanks Dominik,

Always good to get feedback from WIKINDX users and we're obviously keen to have you start using it again! I second what Stéphane says (and leave it in his hands as the one of the two of us who knows more about authentication and security)—please do take up his offer to collaborate on implementation.

Mark

[Stéphane Aulery]

Hi Dominik,

Which OAuth 2.0 provider do you plan to use?

Regards,

--
Stéphane Aulery