Annotation of loncom/html/adm/help/tex/Domain_Configuration_Self_Creation.tex, revision 1.1
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
! 16: ``Default authentication/language/timezone/portal/types'' item in the domain configuration
! 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
! 40: type usernames -- set in the ''Default authentication/language/timezone/portal/types'' area --
! 41: and processing (queued or automated) can be set, based on status.
! 42:
! 43: User information (in addition to e-mail address and password) can be set to be required, optional
! 44: or not requested.
! 45:
! 46: A Captcha mechanism can be used to validate that the user requesting a self-created account is
! 47: a person, not a script. There are two types of CAPTCHA to choose from -- the ``original'' CAPTCHA,
! 48: which uses a self-contained perl module included with the LONCAPA prerequisites, or ReCAPTCHA,
! 49: or ReCAPTCHA, which uses an external web service -- https://google.com/recaptcha --
! 50: and requires you to create an account and generate public and private keys which will be entered
! 51: in the LON-CAPA domain configuration form. If you have more than one server in your domain,
! 52: you should request ``global'' keys on the google.com/recaptcha site, as the same keys will be
! 53: used by the Account creation form's ReCAPTCHA on all servers in your domain.
! 54:
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>