Refactor authentication plugin interface leveraging Authentication Working Group design

[jasoncoposky]

A new authentication plugin interface has been created via the AWG. This new mechanism will be ported to the main iRODS repository.

Consider backwards compatibility with older clients as well as federation.

• Native
• PAM
• Kerberos

The following will not be carried forward into 4.3.x (see https://groups.google.com/g/iROD-Chat/c/sSlBMvI-21o):

• OS Auth
• GSI

[alanking]

Just leaving a note here for tracking progress...

• Pulled all code from AWG into irods/irods
• Code builds
• Wired native authentication plugin into clientLogin so that iCommands use new authentication method

Now I'm experiencing SYS_UNMATCHED_API_NUM when attempting to start a catalog consumer server.

[trel]

That's... allow list?

[alanking]

No, this is just not finding the API number for the new API plugin. I have confirmed that I'm running the same SHA on the provider, which works, and the API plugin exists in the expected location on the consumer. I think this may point to another spot in our logic where the API table is not being loaded in all the places it should. Current guess is that the API table which loads plugins is being initialized on agent startup, not on server startup.

[trel]

ah.

aka, too late.

[trel]

but also, so that it's dynamic... hmm...

[alanking]

The issue with CSC servers has been resolved. The client API table needs to be loaded when standing up the server in order to use the authentication plugins when querying the CSP for information.

Now investigating server authentication failures across federation.

[alanking]

I broke the following unit tests as they are not loading the client API plugins:

==== begin test run results ====
-----
results for [ubuntu-1804-postgres-1012_irods-catalog-provider_1]
        test list:
                [irods_client_connection]
                [irods_connection_pool]
                [irods_query_builder]
                [irods_resource_administration]
                [irods_user_administration]
                [irods_zone_report]
        failed tests:
                [irods_client_connection]
                [irods_connection_pool]
                [irods_query_builder]
                [irods_resource_administration]
                [irods_user_administration]
                [irods_zone_report]
        return code:[1]
-----
List of failed tests:
        irods_connection_pool irods_query_builder irods_resource_administration irods_user_administration irods_zone_report
Return code:[1]
==== end of test run results ====

[alanking]

At the most recent AWG meeting (https://github.com/irods-contrib/irods_working_group_authentication/blob/main/20220125-minutes.md), we discussed implementing the legacy PAM auth plugin using the new plugin framework. This is now done.

Presently, the PAM plugin is very closely tied to the native authentication plugin, to the point where certain database operations only used in the native authentication plugin are PAM-aware. The flow goes something like this:

1. The PAM user must run iinit. An initial call to clientLogin initiates the PAM flow wherein the PAM password is prompted and used to generate a password which is stored in the catalog. This is the only place where the PAM plugin operations are actually invoked. At this point, we are dealing only in PAM credentials and authentication with the server has not occurred. Furthermore, the RcComm is not marked as loggedIn by the plugin upon completion.
2. iinit continues on and authenticates with the server with a second clientLogin call using native authentication with the generated password.
3. The client is then authenticated and all other iCommands use native authentication to authenticate with the server until the password expires according to the TTL parameter, at which time the user must run iinit again.

There is now a fork in the road here as to how we choose to support this:

1. We keep things as they are now and the PAM plugin has to "override" the scheme provided in the environment with native.
2. The PAM authentication plugin absorbs the native authentication plugin. This can be done by simply copying and pasting the operations from the native plugin into the PAM plugin.
3. The PAM authentication plugin can attempt to initiate the native plugin flow FROM the PAM plugin (i.e. load the native plugin and call the start operation from there).

After the legacy PAM authentication plugin is completed using one of the 3 options above, we can start talking about how we would like to implement a new PAM plugin that makes more sense :)

[alanking]

From the "fork in the road" options above, I have successfully demonstrated implementations for 1 and 3. I am leaning toward option 3 at this point because I really don't like the partial authentication implementation provided by the legacy PAM plugin. Thoughts?

[trel]

3 feels... the most robust, if only because of a single source of truth for 'how to native'.

[alanking]

All that's left is taking a pass at iinit to remove the plugin-specific references. This can also be done at a later time, potentially

[alanking]

Okay, I lied. There is one last task: renaming the new pam plugin to pam_password. I have this change in a branch and will open a PR once I confirm that tests are passing.