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 @@ -External Authentication Requirements

External Authentication Requirements

Vision

People have plenty of usernames and passwords already, we +External Authentication Requirements

External Authentication Requirements

Vision

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.

  • Conceptual Pictures

    Authentication:

    -

    Account Management (NO PICTURE YET)

    Batch Synchronization (NO PICTURE YET)

    Requirements

    New API

    FeatureStatusDescription
    New API
    EXT-AUTH-01AExtend Authentication/Acct Status API
    EXT-AUTH-03AAccount Creation API
    EXT-AUTH-05APassword Management API
    EXT-AUTH-30AAuthority Management API

    Login

    FeatureStatusDescription
    Login
    EXT-AUTH-04ARewrite login, register, and admin pages to use APIs
    EXT-AUTH-38Aad_form complain feature
    EXT-AUTH-19ARewrite password recovery to use API
    EXT-AUTH-21ARewrite email verification with API
    EXT-AUTH-28AUsername is email switch

    Users will log in using a username, a authority, and a +

    Account Management (NO PICTURE YET)

    Batch Synchronization (NO PICTURE YET)

    Requirements

    New API

    FeatureStatusDescription
    New API
    EXT-AUTH-01AExtend Authentication/Acct Status API
    EXT-AUTH-03AAccount Creation API
    EXT-AUTH-05APassword Management API
    EXT-AUTH-30AAuthority Management API

    Login

    FeatureStatusDescription
    Login
    EXT-AUTH-04ARewrite login, register, and admin pages to use APIs
    EXT-AUTH-38Aad_form complain feature
    EXT-AUTH-19ARewrite password recovery to use API
    EXT-AUTH-21ARewrite email verification with API
    EXT-AUTH-28AUsername 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.

    FeatureStatusDescription
    create service contract
    EXT-AUTH-16ACreate service contract for Authentication
    EXT-AUTH-17ACreate service contract for Acct. Creation
    EXT-AUTH-29ACreate service contract for Passwd Management
    FeatureStatusDescription
    EXT-AUTH-18AAuthority 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

    • Email

    • 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
     }