Return to Domain_Configuration_Self_Creation.tex CVS log

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

- Document how to acquire a user's self-reported institutional status from
  a course request.

\label{Domain_Configuration_Self_Creation}

Domain-wide settings are available to set whether users may create their own accounts, and
if so, which types of users may do so, and what types of user information a user self-creating
an account will provide.

In the case of an institutional login, or single sign on (SSO), a user must first authenticate
with an insititutional username and password.  If user information is available from an
institutional data source via a query using the username (mediated via a customized routine in 
localenroll.pm), then that is used to populate appropriate data fields in the user's new LON-CAPA 
account.  A domain configuration is available to specify which fields the user may self-report,
if the corresponding institutional data are unavailable.

Which types of institutional log-in may self-create accounts can be restricted,
institutional status (e.g., Faculty, Staff etc.). The institutional status types are set in the
``Default authentication, language, timezone, portal, types'' item in the domain configuration
(this is a change from 2.10 and earlier, which used custom routines in localenroll.pm for that).

For Shibboleth SSO users, mapping of Shibboleth environment variable names to user data fields 
can be set, so that the appropriate user information is stored at account creation time.

Self-creation of user accounts may also be enabled for non-institutional login.  In this case
the user will provide an e-mail address as a username, and will also set a password.  The user must
have access to e-mail sent to that address, as completion of the account creation process requires 
submission of a link (containing a token), sent to the e-mail address.

In order to discourage creation of multiple accounts by a single user when self-creation is
available in a domain for both insitutional log-in and e-mail address as username, a domain
may want to consider implementing format rules which prohibit self-created accounts 
from using certain types of e-mail address as the username.

If a user attempts to self-create an account employing a username with an e-mail address
in a format which matches a defined rule, the action does not proceed, and
the user is directed to create an account with the corresponding institutional
log-in. In this case, account creation can only occur once the user has authenticated using that 
log-in.

Self-created accounts with an e-mail address as username can be set to be queued for approval 
or created automatically. Institutional status types can be set to be self-reported for e-mail
type usernames -- set in the ``Default authentication/language/timezone/portal/types'' area -- 
and processing (queued or automated) can be set, based on status.  Note: self-reported status
is collected from the query string in the original call to /adm/createaccount, from the type
item (e.g., /adm/createaccount?type=student).  One way to gather this data would be to disable
display of the ``New User?'' link on the log-in page, but instead create a separate portal page
(e.g., replace the default /home/httpd/html/index.html) which would prompt new users to push a
different button, depending on whether they were a student or an instructor, with the corresponding
actions pointing at /adm/createaccount?type=$<$status type$>$, with $<$status type$>$ replaced with
student or instructor.

User information (in addition to e-mail address and password) can be set to be required, optional
or not requested.

A Captcha mechanism can be used to validate that the user requesting a self-created account is
a person, not a script.  There are two types of CAPTCHA to choose from -- the ``original'' CAPTCHA, 
which uses a self-contained perl module included with the LONCAPA prerequisites, 
or ReCAPTCHA, which uses an external web service -- https://google.com/recaptcha --
and requires you to create an account and generate public and private keys which will be entered
in the LON-CAPA domain configuration form.  If you have more than one server in your domain, 
you should request ``global'' keys on the google.com/recaptcha site, as the same keys will be
used by the Account creation form's ReCAPTCHA on all servers in your domain. If using ReCAPTCHA, you
can indicate whether version 1 or 2 should be used.