Say 👋 hello to BusyBee, your AI-powered learning & teaching companion for Buzz. Learn more!
Enable users to sign into Buzz with their school credentials.
Buzz supports the use of Single Sign-on (SSO) features to allow users to sign into one application (for example, a student information system) and be automatically logged into Buzz without needing to re-enter credentials. This feature can help eliminate the need for teachers and students to remember multiple credential sets.
Note: Authentications are not inherited by subdomains and must be configured in any domain that you want them honored.
Configure SSO
- Open the More menu in Domain > Details.
- Select Domain settings.
- Open the authentication Type dropdown under Authentication:
- Provide the CAS Server URL.
- Buzz generates your Buzz hostname for you when you click Update.
- Note: Because Buzz generates this hostname using the domain you are currently signed into, customers with their own Custom URL must be signed in using that URL to correctly set up the single sign-on.
- Provide a Logout redirect URL if you want users to be taken to somewhere other than the Buzz login screen when they sign out.
- Indicate if you want to Logout of CAS when logging out of Buzz.
- Indicate if you want to Prevent users from using Buzz credentials.
- If you don't select this, you have the option to Allow users to create their own accounts rather than requiring they be created for them. You will also be able to set up your password policy.
- Save.
The Domain Authentication Type uses the SSO options and Users of the domain specified in the Domain.
Example
An example district houses all of their users in a single domain; however, they want their users to have different experiences based on which school they attend within the district (e.g., age-appropriate features, branding, landing page). They could create a subdomain for each school and use the Domain Authentication Type pointing to the district domain. Then the students could sign in through their school domain to get the right experience, while all of their user information (and SSO configuration) is centralized on the district domain.
- Choose the Domain Type.
- Provide the Domain ID where the users and SSO configuration you want to use are located.
- Indicate if you want to Allow users to create their own accounts rather than requiring they be created for them.
- Set up your password policy.
- Save.
Note: The Domain Authentication Type does not support SAML v3 configurations. It does support previous SAML versions.
Do not choose the "old version" of SAML
- Click Add identity provider (IdP).
- Provide the Login prompt. This is what appears on the login button. If you have only one IdP, this defaults to Login, if you have more, you can label them appropriately.
- Upload the idp-meta XML file. This is provided by your IdP.
- The Metadata resource path and Provider ID are automatically populated.
- Click Done.
- You can add more IdPs if you want to expand the single sign-on. They are added to the list under Login.
- Click Download metadata to download your current SAML configuration.
- You may need to provide this to your IdP (if they request a URL, use the following with your userspace inserted where requested: https://api.agilixbuzz.com/SAML/[INSERT USERSPACE]/metadata.xml ).
- Buzz generates your Buzz hostname for you.
- Note: Because Buzz generates this hostname using the domain you are currently signed into, customers with their own Custom URL must be signed in using that URL to correctly set up the single sign-on.
- Provide a Logout redirect URL if you want users to be taken to somewhere other than the Buzz login screen when they sign out.
- The Share SAML configuration with subdomains option allows you to let subdomains inherit this configuration, so you don't have to configure each domain individually.
- Note: Usernames in domains that share a SAML configuration must be unique. Users with non-unique usernames cannot authenticate with Single Sign-on (SSO).
- Indicate if you want to Prevent users from using Buzz credentials.
- If you don't select this, you have the option to Allow users to create their own accounts rather than requiring they be created for them. You will also be able to set up your password policy.
- Save.
Local-only email Name ID support
Buzz's SAML SSO supports email address Name ID when the Buzz username is used as the local-part of the associated email address (everything before the @).
For example, if a SAML authentication request comes through with a Name ID format of an email address (nameid-format:emailAddress), then Buzz:
- Looks for the user with the full email address as a Buzz username (e.g., john.student@example.com). If the user is found, they are allowed to access Buzz.
- If Buzz is unable to find the user by the full email address, then Buzz searches for a user with the local-part (everything before the @) of the email address (e.g., john.student). If a user is found with the local-part, the user is allowed to access Buzz.
- If no user is found by the full email address nor the local-part, then Buzz will tell the user that no matching user can be found.
To take advantage of this feature with Google SSO authentication, you may need to update your Service provider details in the Google SAML app settings to use the EMAIL as the Name ID.