OpenID Connect (OAuth 2.0) authentication Handler for ACT (references #56)

[coudot]

Code made during patch -p2 Hackathon in Lyon. The goal is to be able to log on Act with an external provider like Google.

[maddingue]

While installing Crypt::SSLeay, it printed the following message:

*** THIS IS NOT AN ERROR, JUST A MESSAGE FOR YOUR INFORMATION ***

Do you really need Crypt::SSLeay?

Starting with version 6.02 of LWP, https support was unbundled into
LWP::Protocol::https. This module specifies as one of its prerequisites
IO::Socket::SSL which is automatically used by LWP::UserAgent unless
this preference is overridden separately. IO::Socket::SSL is a more
complete implementation, and, crucially, it allows hostname
verification. Crypt::SSLeay does not support this. At this point,
Crypt::SSLeay is maintained to support existing software that already
depends on it.

However, it is possible that your software does not really depend on
Crypt::SSLeay, only on the ability of LWP::UserAgent class to
communicate with sites over SSL/TLS.

If are using version LWP 6.02 or later, and therefore have installed
LWP::Protocol::https and its dependencies, and do not explicitly use
Net::SSL before loading LWP::UserAgent, or override the default socket
class, you are probably using IO::Socket::SSL and do not really need
Crypt::SSLeay.

Before installing Crypt::SSLeay, you may want to try specifying a
dependency on LWP::Protocol::https.

Is the Crypt::SSQLeay actually required, or should it be IO::Socket::SSL?

[coudot]

I did not have test IO::Socket::SSL but it should also work. You can replace Crypt::SSLeay by it if you need.

[maddingue]

LWP::Protocol::https is a better prerequisite than Crypt::SSLeay, then.
But we can fix that later :)

[maddingue]

Currently configuring an OpenID Connect provider with Google. In the current way auth is handled Act-side, it will impose quite a burden in terms of administration because each conference that will want to use Google will need to be explicitly declared in Google Console. And I guess things will be similar with other providers. It means that, taking patch.pm as an example, I need to declare:

http://patch.pm/p0/OAUTHLOGINCB
http://patch.pm/p1/OAUTHLOGINCB
http://patch.pm/p2/OAUTHLOGINCB

And that's hoping OAUTHLOGIN is always at the root of the conference (/p2/), and not at a lower level.

It would really simplify things if we could redirect to the domain root instead, however, I don't know whether we have enough information to then correctly redirect to the original URL, i.e.:

URL -> auth form -> /OAUTHLOGIN -> Google -> /OAUTHLOGINCB -> URL

[coudot]

Yes, I think we can change this. Maybe this do not require any code change, just adapt the link in the login page, the endpoint in Apache configuration and the configuration of redirecturi in act.ini