Index: openacs-4/packages/acs-core-docs/www/ext-auth-requirements.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/ext-auth-requirements.html,v diff -u -r1.45.2.3 -r1.45.2.4 --- openacs-4/packages/acs-core-docs/www/ext-auth-requirements.html 27 Jun 2019 18:22:21 -0000 1.45.2.3 +++ openacs-4/packages/acs-core-docs/www/ext-auth-requirements.html 3 Sep 2021 09:14:59 -0000 1.45.2.4 @@ -1,5 +1,5 @@ -
People have plenty of usernames and passwords already, we +
People have plenty of usernames and passwords already, we don't want them to have yet another. We want people to be able to log in to OpenACS with the same password they use to log in to any other system.
Besides, administrators have better things to do than create @@ -45,7 +45,7 @@ only one implementation of the authentication API, namly the one included in OpenACS Core.
Authentication Driver API: The service contract which authentication drivers implement.
Authentication:
-
Account Management (NO PICTURE YET)
Batch Synchronization (NO PICTURE YET)
Feature | Status | Description |
---|---|---|
New API | ||
EXT-AUTH-01 | A | Extend Authentication/Acct Status API |
EXT-AUTH-03 | A | Account Creation API |
EXT-AUTH-05 | A | Password Management API |
EXT-AUTH-30 | A | Authority Management API |
Feature | Status | Description |
---|---|---|
Login | ||
EXT-AUTH-04 | A | Rewrite login, register, and admin pages to use APIs |
EXT-AUTH-38 | A | ad_form complain feature |
EXT-AUTH-19 | A | Rewrite password recovery to use API |
EXT-AUTH-21 | A | Rewrite email verification with API |
EXT-AUTH-28 | A | Username is email switch |
Users will log in using a username, a authority, and a +
Account Management (NO PICTURE YET)
Batch Synchronization (NO PICTURE YET)
Feature | Status | Description |
---|---|---|
New API | ||
EXT-AUTH-01 | A | Extend Authentication/Acct Status API |
EXT-AUTH-03 | A | Account Creation API |
EXT-AUTH-05 | A | Password Management API |
EXT-AUTH-30 | A | Authority Management API |
Feature | Status | Description |
---|---|---|
Login | ||
EXT-AUTH-04 | A | Rewrite login, register, and admin pages to use APIs |
EXT-AUTH-38 | A | ad_form complain feature |
EXT-AUTH-19 | A | Rewrite password recovery to use API |
EXT-AUTH-21 | A | Rewrite email verification with API |
EXT-AUTH-28 | A | Username is email switch |
Users will log in using a username, an authority, and a password. The authority is the source for user/password verification. OpenACS can be an authority itself.
Each user in OpenACS will belong to exactly one authority, which can either be the "local" OpenACS users table, in which case the @@ -86,8 +86,7 @@ One driver handles authentication, one account creation, and one changing passwords.
Feature | Status | Description |
---|---|---|
create service contract | ||
EXT-AUTH-16 | A | Create service contract for Authentication |
EXT-AUTH-17 | A | Create service contract for Acct. Creation |
EXT-AUTH-29 | A | Create service contract for Passwd Management |
Feature | Status | Description |
---|---|---|
EXT-AUTH-18 | A | Authority configuration data model |
Each authority is defined like this:
Authority pretty-name, e.g. "URZ"
Authentication Driver, e.g. "RADIUS". In practice, this would be a reference to a service contract - implementation.
Authentication Driver configuration settings, e.g. host - name, port, etc., as required by the particular driver. Note that + implementation.
Authentication Driver configuration settings, e.g. hostname, port, etc., as required by the particular driver. Note that this is per authority, not per driver, i.e., you can have multiple authorities with the same driver but different configuration options.
AuthenticationAllowed - true/false, so you can disable @@ -100,8 +99,7 @@ would be a reference to a service contract implementation. The reason we have separate drivers for authentication and account creation is that organizations are likely to have a home-grown - account registration process.
Account Creation Driver configuration settings, e.g. host - name, port, etc., as required by the particular driver. Note that + account registration process.
Account Creation Driver configuration settings, e.g. hostname, port, etc., as required by the particular driver. Note that this is per authority, not per driver, i.e., you can have multiple authorities with the same driver but different configuration options.
RegistrationUrl - instead of registering using OpenACS, @@ -160,7 +158,7 @@ Registration
If a user doesn't have an account, the site-wide configuration can allow the user to register for one, as defined in the configuration discussed above. This section is about normal -account registration through a authority driver.
The account creation service contract implementation will +account registration through an authority driver.
The account creation service contract implementation will need to tell us which information to ask the user for:
Required Fields: A list of fields which are required.
Optional Fields: A list of fields which are optional.
The fields to choose from are these:
Username
First names
Last name
URL
Password
Secret question
Secret answer
It should return the following:
Creation status (OK, Try-Again, Fail)
Creation message: What went wrong, or a welcome @@ -299,7 +297,7 @@ in the sort order.
The relevant code in user-login.tcl would look like this:
if { ![auth::split_username -username_var username -authority_var authority] } { - # bounce back to the form with a message saying that the login wasn't valid. + # bounce back to the form with a message saying that the login was not valid. ad_script_abort }