During the summer of 2017, we released a new Buzz UI, giving you the same features and functionality with a cleaner, simpler user experience!
Until all users have switched to the new UI, our Help Center articles will include information for both.
Click the header below that aligns with the Buzz UI version you are using (Old UI or New UI); if you don't know which version you are using, review the differences and/or contact your system admin or Agilix account manager
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.
Configure SSO
- Open Settings in the Domain toolbar.
- Select Integrations.
- Open the Authentication type dropdown under Authentication:
- If you use CAS, provide the CAS server URL.
- If you use Domain, provide the Domain ID and you can use that domain's SSO configuration. For example, if you configured SAML in a district domain, you can point to that school domain to use the district's SAML configuration.
- If you use SAML, choose the signature algorithm you want to use and upload the idp-meta XML file. Your SAML provider can tell you which signature algorithm to use; if you can use either, we recommend SHA-256 as it is more secure.
- Indicate whether you want to prevent users from logging in with Buzz credentials.
- Save.
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.
Configure SSO
- Open the side menu in Domain > Details.
- Select Edit Settings.
- Open the authentication Type dropdown under Authentication:
- If you use Buzz:
- Indicate if you want to Allow users to create their own accounts.
- Indicate if you want to Set password policy.
- If you use CAS:
- Provide the CAS Server URL.
- Indicate if you want to Logout of CAS when logging out of Buzz.
- Indicate if you want to Prevent users from using Buzz credentials.
- Indicate if you want to Open login in a new window.
- If you use Domain, provide the Domain ID and you will use that domain's SSO configuration. For example, if you configured SAML in a district domain, you can point to that school domain to use the district's SAML configuration.
- If you use SAML:
- Choose the signature algorithm you want to use. Your SAML provider can tell you which signature algorithm to use; if you can use either, we recommend SHA-256 as it is more secure.
- Upload the idp-meta XML file.
- Indicate if you want to Prevent users from using Buzz credentials.
- Indicate if you want to Open login in a new window.
- If you use Buzz:
- Save.
Comments (19)
How do you replace the existing xml file with this new one through the IDP? Where do you locate the IDP?
Hello Tami. If you are transitioning from BrainHoney, the IDP file is generally stored in the domain resources (see Manage Resources) in a folder titled IDP.
Brad - Does turning on the SSO always redirect the students to the https:// protocol? We have students go to our SIS - Genius and then login to Buzz using the Single Sign on. They are being directed to the https:// of Buzz and it is causing issues with students not being able to see course content from FYI or CLO (linked through LTI). If they login directly to Buzz they are directed to the http:// protocol and do not have any issues view this content. Is there a way to fix this?
Hey Tami, before I provide you with an answer, I just want to emphasize that we recommend that your content providers become https compliant. While they may not be today, they should work towards it. Google and many other browser technologies penalize these practices and penalize even more in the future (i.e., limit usage without extreme warnings).
To answer your question, your SSO should redirect the user to the protocol that the user accessed Buzz.
For example:
Brad - it seems that something is amiss with my SSO then. My student information system is set up to sign students on at the http:// site. This seems to work for Teachers and Administrators but for students they are taken to the https:// site instead. I have double checked with my SIS company and they confirm that it is set to direct to the http:// for students. Could I have done something wrong in the SSO set up in Buzz?
Thanks for your help.
Hey Tami, that doesn't quite make sense. Buzz should be using the same protocol for all users. I would recommend that you create a Support request to look into it for you. They would be able to help look at your current settings and provide suggestions.
Thanks.
Brad - with the help of my SIS and Jordan we were able to get this issue resolved.
Thanks
I am very happy to hear that. Thank you for letting me know.
Trying to set up this feature using Google SSO. Can you provide me with:
Hey Burt, the Buzz SP metadata can be found at: https://api.agilixbuzz.com/saml/USERSPACE/metadata.xml.
Replace USERSPACE with your domain userspace/login prefix.
Brad,
I checked out the metadata at the URL that you provided. I tried to use the entityID URL for both the ACS URL and Entity ID URL in the Google SSO setup.
Here is the error that I received, when I tried to login as a user:
Am I using an incorrect user ID? Is the attributes mapping for user authentication also in the metadata?
The Entity ID URL in the SP metadata has an attribute of "entityID".
The ACS URL is in a node called "AssertionConsumerService".
Does this help?
Why isn't there descriptions for Domain?
Hey Stephanie, that is an error. We should document Domain and I will communicate this to our documentation team.
The "Domain" feature allows you to point to another domain to use the other domain's SSO configuration. For example, if you configured SAML in a district domain and it is the same SAML to be used for each school (because the users in the SAML is all district users), you can point the school domain to use the district's SAML configuration.
Brad,
Our Google SSO stopped working today, about the time that the new UI was turned on.
Did any settings in the SSO configuration change?
If not, any ideas why the users are seeing a blank screen when they click login. They only see a Close option. When they click on Close, they just return to the login screen.
You'll need to configure your SSO integration (in the Buzz domain settings) to open in a new window. In Buzz, we attempt to load the SSO within the page, but Google does not allow this.
Ok, thanks.
Interesting. I noticed that Buzz opens in a New Window, but then one of the windows closes after successfully logging in.
It is the SSO that is opening in the new window and, yes, it normally closes itself after authenticating.
Brad,
Our team at Chandler USD is discussing the SSO process with Buzz.
We have Infinite Campus as our SIS and I was wondering whether there was a way for these two systems to interact using SSO.
If not, what is the best SSO method to use to implement for AD/Buzz authentication? I see there are 4 different options available. We are also integrated with Clever.
Any information you can provide will be greatly appreciated.
Thank you
John Andrews
Programmer Analyst