Editing Archive:Webserver authentication (section)

== Conceptual overview ==
Here's how this integration works conceptually (not in order of steps performed). Filenames in parentheses refer to the files from http://files.eprints.org/738/
# Enable [[HTTPS]] for your webserver and the EPrints instance.
# Configure EPrints to send requests requiring authentication to a specific resource/URL, we'll assume <tt>/shibboleth/login</tt> below but this could be any string of your choice. (<tt>auth.pl</tt>)
# Make EPrints proper ignore these requests (<tt>archives/[repo_id]/cfg/cfg.d/[[20_baseurls.pl]]</tt>)
# Require authentication (and possibly also authorization) in the webserver for access to this resource (<tt>eprints-httpd-auth.conf</tt>)
# Add code to the installation which handles those pre-authenticated requests, creates new users and sessions, and returns to the originally requested resource. (<tt>login</tt>)

Note that the recipe below does '''not''' provide a parallel authentication method for EPrints -- it completely replaces the default authentication method and login prompt. You can disable the new authentication method to change the user type of some (possibly newly created) user account to "repository administrator" afterwards (when logging in as eprints admin with local/database authentication). Alternatively make sure that a user account already exists within EPrints that is of user type "repository adminstrator" and has a username that can authenticate to the external authentication system (with Shibboleth you'd also need to make sure that this username is returned from the SAML Identity Provider and that the correct, i.e., matching username is being mapped to httpd's <tt>REMOTE_USER</tt> variable).

A consequence of external authentication is that no self-registration of user accounts within EPrints is possible (or necessary, as many would see it) anymore, unless the system providing external authentication itself offers self-registration.

A word of warning: Don't enable this in a production EPrints instance unless either all existing users have matching usernames in your external authentication system, or you can live with the consequences of any and all users being auto-created (again) with different usernames (thereby possibly losing access to all their data, roles, etc.). Updating usernames in EPrints or other migration strategies are ''not'' considered below. Conversely make sure that none of the external usernames ''unintendedly'' match any local EPrints accounts with admin or "repository administrator" or "editor" privileges -- unless you expressly want them to have those privileges.