Return to Domain_Configuration_Self_Creation.tex CVS log

Up to [LON-CAPA] / loncom / html / adm / help / tex

Annotation of loncom/html/adm/help/tex/Domain_Configuration_Self_Creation.tex, revision 1.4

1.1       raeburn     1: \label{Domain_Configuration_Self_Creation}
                      2: 
                      3: Domain-wide settings are available to set whether users may create their own accounts, and
                      4: if so, which types of users may do so, and what types of user information a user self-creating
                      5: an account will provide.
                      6: 
                      7: In the case of an institutional login, or single sign on (SSO), a user must first authenticate
                      8: with an insititutional username and password.  If user information is available from an
                      9: institutional data source via a query using the username (mediated via a customized routine in 
                     10: localenroll.pm), then that is used to populate appropriate data fields in the user's new LON-CAPA 
                     11: account.  A domain configuration is available to specify which fields the user may self-report,
                     12: if the corresponding institutional data are unavailable.
                     13: 
                     14: Which types of institutional log-in may self-create accounts can be restricted,
                     15: institutional status (e.g., Faculty, Staff etc.). The institutional status types are set in the
1.2       raeburn    16: ``Default authentication, language, timezone, portal, types'' item in the domain configuration
1.1       raeburn    17: (this is a change from 2.10 and earlier, which used custom routines in localenroll.pm for that).
                     18: 
                     19: For Shibboleth SSO users, mapping of Shibboleth environment variable names to user data fields 
                     20: can be set, so that the appropriate user information is stored at account creation time.
                     21: 
                     22: Self-creation of user accounts may also be enabled for non-institutional login.  In this case
                     23: the user will provide an e-mail address as a username, and will also set a password.  The user must
                     24: have access to e-mail sent to that address, as completion of the account creation process requires 
                     25: submission of a link (containing a token), sent to the e-mail address.
                     26: 
                     27: In order to discourage creation of multiple accounts by a single user when self-creation is
                     28: available in a domain for both insitutional log-in and e-mail address as username, a domain
                     29: may want to consider implementing format rules which prohibit self-created accounts 
                     30: from using certain types of e-mail address as the username.
                     31: 
                     32: If a user attempts to self-create an account employing a username with an e-mail address
                     33: in a format which matches a defined rule, the action does not proceed, and
                     34: the user is directed to create an account with the corresponding institutional
                     35: log-in. In this case, account creation can only occur once the user has authenticated using that 
                     36: log-in.
                     37: 
                     38: Self-created accounts with an e-mail address as username can be set to be queued for approval 
                     39: or created automatically. Institutional status types can be set to be self-reported for e-mail
1.3       raeburn    40: type usernames -- set in the ``Default authentication/language/timezone/portal/types'' area -- 
1.4     ! raeburn    41: and processing (queued or automated) can be set, based on status.  Note: self-reported status
        !            42: is collected from the query string in the original call to /adm/createaccount, from the type
        !            43: item (e.g., /adm/createaccount?type=student).  One way to gather this data would be to disable
        !            44: display of the ``New User?'' link on the log-in page, but instead create a separate portal page
        !            45: (e.g., replace the default /home/httpd/html/index.html) which would prompt new users to push a
        !            46: different button, depending on whether they were a student or an instructor, with the corresponding
        !            47: actions pointing at /adm/createaccount?type=$<$status type$>$, with $<$status type$>$ replaced with
        !            48: student or instructor.
1.1       raeburn    49: 
                     50: User information (in addition to e-mail address and password) can be set to be required, optional
                     51: or not requested.
                     52: 
                     53: A Captcha mechanism can be used to validate that the user requesting a self-created account is
                     54: a person, not a script.  There are two types of CAPTCHA to choose from -- the ``original'' CAPTCHA, 
1.4     ! raeburn    55: which uses a self-contained perl module included with the LONCAPA prerequisites, 
1.1       raeburn    56: or ReCAPTCHA, which uses an external web service -- https://google.com/recaptcha --
                     57: and requires you to create an account and generate public and private keys which will be entered
                     58: in the LON-CAPA domain configuration form.  If you have more than one server in your domain, 
                     59: you should request ``global'' keys on the google.com/recaptcha site, as the same keys will be
1.4     ! raeburn    60: used by the Account creation form's ReCAPTCHA on all servers in your domain. If using ReCAPTCHA, you
        !            61: can indicate whether version 1 or 2 should be used.
1.1       raeburn    62: