#  Harvard Guest Accounts Technical Overview 

 



 ##  

  expand\_more  

 
  

 

## Purpose and scope of Harvard Guest accounts

  
Harvard Guest accounts allow individuals outside Harvard University to access a limited number of secure applications and services. Designed for users with temporary or limited interactions with the University, these accounts allow self-registration without a Harvard University ID (HUID). Access for these Guest accounts is restricted; Guest accounts are not eligible for on-campus access, library resources, or access to sensitive data.

## Harvard Sponsored Roles vs Harvard Guest accounts

  
Harvard Sponsored Roles (HSRs) and Harvard Guest accounts both provide access for individuals in non-traditional roles, but they serve different purposes and offer different levels of access.

HSRs sign in with HarvardKey and are eligible for broader access. Because HarvardKey can grant entry to more sensitive resources, HSRs require stronger oversight and identity assurance. Individuals cannot self-register; each person must be sponsored by a Harvard employee, and roles must be re-attested annually. Access permission varies by role, for example, consultants are authorized to access applications considered L4 risk, while tenants are only authorized up to L2.

In contrast, anyone with an email address can create a Harvard Guest account. However, because relatively little information is collected about these users, Guest accounts are limited to a smaller set of applications and should only be used with data that is personal, public, or paid-for (such as course materials).

**Consider using a Harvard Guest account only if ALL of the following are true:**

- Users do not require a HUID or physical ID card.
- Users do not require access to library resources.
- Users are only eligible to access their own data, data explicitly shared with them (i.e. course data), or data considered public.
- Your application does not require multi-factor authentication (MFA) for additional protection.
- Your application handles authorization locally and does not require group authorization via Grouper.

If any of the factors above are NOT true, enabling access via Harvard Guest will not be a good fit and you will need to consider how best to enable user access via a sponsored role (HSR) or another HarvardKey-eligible role.



 

##  Technical Comparison: HarvardKey vs. Harvard Guest Accounts 

SortAttributeHarvardKeyHarvard GuestAssigned HUID

Yes

No

Attribute set

Comprehensive (username, preferred name, official email, HUID, NetID, role, affiliation, etc.)

Minimal (preferred name, email, NetID)

Identity assurance level

Varies by role

Always low

Registration

Account pre-registered, then claimed by user

Self-service

Application scope

University-wide

Opt-in subset







 

##  Integration Model Options 

Guest authentication is managed separately from HarvardKey and handled by a different vendor; HarvardKey by Okta and Guests by Cirrus. If you want to support Guest sign-ins, you must integrate with the Guest vendor, Cirrus.

Two integration models are available:

- **Integrate with Cirrus Only** ***(most common)*****:** Integrate only with Cirrus (Guest Identity Provider) and rely on Cirrus delegating HarvardKey authentication to Okta (HarvardKey Identity Provider).
    - Pros: Compatible with most SSO-eligible applications; both SAML and OIDC protocols supported.
    - Limitations: Must display Cirrus’s standard discovery page to all users; restricted to standard Okta security settings for HarvardKey users.
- **Integrate with Cirrus and Okta separately** ***(preferred where possible)*****:** Integrate with Cirrus (Guest Identity Provider) as well as Okta (HarvardKey Identity Provider)
    - Pros: allows more flexibility in Okta security settings for HarvardKey users; allows applications to customize how it directs users to the correct authentication system.
    - Limitations: must use SAML protocol, application is responsible for directing users to the correct IdP based on account type, more complex set-up not supported by many applications.
        - Applications must be able to support multiple identity providers and modify the authentication request per Cirrus' documentation: [Bypass proxy discovery](https://blog.cirrusidentity.com/documentation/cirrus-identity-provider-proxy#Using-Cirrus-Identity-Provider-Proxy:~:text=Proxy%E2%80%9D%20example%20configuration.-,Bypass%20Proxy%20discovery,-In%20some%20situations).

Please note that whichever model is chosen, the primary identifier must be NetID.



 

### Standard discovery page 

 

If you choose the Single-IdP model, all users (both HarvardKey and Harvard Guests) will be presented with the following discovery page in order to choose how they will sign in.



 



      ![Screenshot of Harvard Guest discovery page](/sites/g/files/omnuum12676/files/styles/hwp_1_1__480x480/public/2025-09/cirrus_discovery_page.png?itok=0QcJk0dj) 

 

 

  

 



 

 

 

##  Integration Steps 

 



 ### Step 1: Gather essential information

- **New to HarvardKey?** Please review our [HarvardKey Application Integration](https://prod-iam.drupalsites.harvard.edu/get-started/app-integration) article
- **Integrated with HarvardKey?** If you will be changing protocols for your Cirrus integration, you’ll need to gather the protocol specific integration details. This can be found in the **Authentication Protocols & Attribute Release** section of the [HarvardKey Application Integration form](https://prod-iam.drupalsites.harvard.edu/sites/g/files/omnuum11246/files/iam/files/hk_app_integration_form_20250226.docx).



 

 ### Step 2: Determine integration model

- All applications must determine which integration model your application requires: Single-IdP (Cirrus only) or Dual-IdP (Cirrus & Okta).
    - Applications choosing the Duo-IdP model must construct a SAML request per the parameters in the Cirrus documentation: [Bypass proxy discovery](https://blog.cirrusidentity.com/documentation/cirrus-identity-provider-proxy#Using-Cirrus-Identity-Provider-Proxy:~:text=Proxy%E2%80%9D%20example%20configuration.-,Bypass%20Proxy%20discovery,-In%20some%20situations).



 

 ### Step 3: Submit your request

- **New to HarvardKey?** Fill out the [HarvardKey Application Integration form](/node/1638539) and gather any other required materials
- **Integrated with HarvardKey?** Email [iam\_help@harvard.edu](mailto:iam_help@harvard.edu) with the following information:
    - Technical contact
    - Application Name
    - Registration ID
    - Chosen integration model
    - Protocol specific integration details (if different from HarvardKey)



 

 ### Step 4: Registration setup

- You will be notified once your application registration is complete and provided with the details needed to configure the integration on the application side.



 

 ### Step 5: Complete your integration

- Implement Cirrus’s protocol-specific details to configure your application:
    - SAML: Use the [Cirrus metadata file](https://urldefense.proofpoint.com/v2/url?u=https-3A__harvard.proxy.cirrusidentity.com_module.php_saml_sp_metadata.php_harvard-5Fproxy&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=vU1OreTTbXp6lAN65-71HaJC1Hn0jVcG9ognm_I1pmY&m=t-5bmkVFfkhh6WS_Qaon54mh9dpfBgjiJLl7woo0VGrp2xnfqXnXQ840o0FroZFa&s=xgnXTx0K9aY5z5Z8khdVvL-ErOfwebUqa6IgNYNvLuY&e=)
    - OIDC: Use the client ID and secret sent directly by the vendor.
- The IAM team and Cirrus vendor can provide troubleshooting support as needed



 

  

 

 

 

 

 

 

##  Need help? 

Join the weekly Authentication & Authorization Office Hours on Tuesdays from 1-2 PM or email [iam\_help@harvard.edu](mailto:iam_help@harvard.edu). To register for this or for an upcoming office hours session, refer to the following knowledge article: [KB0021507 - Identity and Access Management (IAM) Office Hours](https://harvard.service-now.com/ithelp?id=kb_article&sys_id=a7dd80614719da109f7d957c416d436f) (HarvardKey login required).