Put auth in the Hive

[Altreus]

Note: I don't like the names of these services. I want login to be auth, but I can't think of a better name for auth.

This is gonna be a fun one. I had a good talk with Nick and we figured out a potentially decent way of getting auth into the Hive.

The way we do it is we separate auth into two services: auth itself, and login.

This is somewhat inspired by the way Catalyst::Plugin::Authentication already does it, which is to provide an interface set_authenticated, which simply tells the auth plugin that the user is authenticated.

Auth service handles session-type storage

The auth service would provide a very simple interface:

• Is anyone logged in? (is this token valid?)
• Log this person in
• Log this person out

How the service stores this information is largely irrelevant. The only necessary interface is that the "log in" function returns a token, and the other functions accept it (or something like that).

Login service performs authentication

The login service provides the other half of the behaviour. This would be the first instance of a truly swappable Hive service. This would provide all the behaviour necessary to authenticate user information against arbitrary input data.

Here's how it would, very broadly, work:

my $h = OpusVL::FB11::Hive;
$h->service('auth')->set_logged_in(
  $h->service('login')->authenticate( $auth_info )
);

Clearly missing from this code is the source of $auth_info, and this is the bit we have to fill in. The idea here is that this would be provided by various interfaces into the same system.

Login service can signal what data it needs

The way we collect $auth_info would be another module (or set of modules) that support the login Brain. The login Brain is literally only concerned with getting the data to the source of auth data, and then signalling to the auth service that somebody is logged in.

This is basically a view on the login service. In HTML mode, we would direct the user through one or more forms, while on the CLI we can direct them through one or more prompts.

The idea would be that the login service could be quizzed for its behaviour. I don't propose that we make a generic view that can handle all login services (although, with an OpenAPI format of hashrefs we could certainly try), but rather that each login style ships with multiple views.

An obvious example is to take the current auth system and turn it into a Hive auth system:

• The auth service is always the same
• The login service requires a username and password to authenticate
• If this returns a true value, we tell auth that somebody is logged in.
• auth gives us a token that we can keep

Around this:

• An FB11X component for user-pass login is provided with FB11 core
• This renders a user/pass form
• On submit, runs the above behaviour
• Stores the auth token in user session

Around that:

• FB11 requires login
• If there's no login token in the session, nobody is logged in
• If there is, asks auth service if it's valid
• If not, nobody is logged in
• If nobody is logged in, direct to /login
• This is provided by FB11X component.

[Altreus]

I've added the "breaking change" label even though it might not actually be a breaking change. We could in theory update everything at once (i.e. the Catalyst auth process) so the migration is seamless.