The Guest Accounts system provides Stanford-supported authenticators for the extended Stanford Community. It is not limited to official University affiliates, and includes visitors to the University, those with short-term or infrequent business with the university, or parties with an informal relationships to the University. Guest Accounts are intended for use on University applications and computing resources where a strong affiliation to the University is not required. Applications where the administrator must be absolutely sure that the authenticating account represents a single, unchanging person are also not appropriate for the Guest Accounts service.
From an application provider's point of view, the components of the Guest Accounts system are:
- The Guest Accounts web pages: Allow invitations to be sent and facilitates password creation and changes.
- The Authentication System: A separate directory, domain, and a MySQL database that stores the information about a guest account and supports an authentication mechanism.
- The Workgroup Manager: Allows providers to add guest account IDs to predefined groups of users. Groups can then be assigned to specific applications and web pages.
- Shibboleth: A software component that obtains the relevant guest group association and other information about the guest account. It passes this information to the authentication system to allow access to specific applications and web pages.
This is a general service open to the public. All Guest Account holders must have an email address to which they can respond. No privileges are conferred by default to a Guest Account; all must be added by application, system, or network administrators who are solely responsible for the vetting of identity for any group membership.
Users of the Guest Accounts system may be invited by a member of the Stanford community (a person eligible for a SUNet ID) or can sign up and request an account via a web page and email interaction. Members of the Stanford community can then add Guest Account holders to workgroups which may be used by downstream systems to confer privileges (e.g., application, system, or network access).
Users have 30 days to respond to any invitation from the Guest Accounts system. If that time expires, any group memberships that were created for that account will be deleted.
Unused accounts will be deleted after 13 months, along with all associated group memberships.
Authentication methods involve presenting both a public identifier (either an email address or login name) and private authentication information (a password). These accounts are associated with an email address and anyone with access to email sent to that address could have access to that Guest Account.
Users are strongly encouraged to change their password regularly to limit possible abuse of passwords that may have been compromised without the user's knowledge.
The Guest Account system provides a lower level of security than the SUNet ID system. It is not intended to be a replacement for a SUNet ID. In particular, Guest Accounts may not be used for applications that have HIPAA, Human Subjects, Research, or Stanford-identified Restricted Data with other legal restrictions.
System administrator responsibilities
Systems Administrators who leverage the Guest Accounts system to authenticate users to their accounts are responsible for actively maintaining the groups to which those Guest Accounts belong, and for vetting to the appropriate level of assurance the identities of people using those Guest Accounts.