Authentication Process
User authentication is a process that verifies the identity of someone connecting to your network and data. There are different methods of user authentication your district or school can use for your Community Engagement products – Mass Notifications, Teacher Communications, Mobile Communications App, and Social Media Manager. Many districts and schools want a secure authentication process with single-source sign-in names and passwords.
With all authentication processes, the Community Engagement products require the Student Information System (SIS) data to be available. This information can be uploaded.
* There is a paid add-on, because must turn on the configuration options for SAML. Please have your administrator contact our sales team to get started.
* You can use multiple authentication processes. If the user is not listed in one process, it will be compared against another authentication process you have set.
Here are some of the authentication processes you can use for Mass Notifications, Teacher Communications, Mobile Communications App, and Social Media Manager.
Google Authentication Process
To use the Google authentication process, your district or school must Enable Google on the Authentication page in Global Settings.
When user clicks Sign In using Google, the Community Engagement product will display the Google Account sign-in page. The user will need to type their Email or Phone number and select Next. Then, the user will Enter your password and select Next to sign into Google.
If the login information is correct, the Google API will pass the email and Google ID to the Community Engagement product. If this is the first time the user is signing in with Google, support will then verify that the email address is available to a user account. If it is, the Google ID will be saved for the user and support will authenticate the user and the user will be logged into the product. If the email does not exist in a user account, the user will be checked against the Web Community Manager user database, if available. If there is no connection to WCM, the user will not be authenticated and will not be logged in.
The next time the user signs in using Google, as long as the login is correct, Google API will pass the email and Google ID to the Community Engagement product. Since the Google ID is already stored, the user will be authenticated and will be logged into the product without having to recheck the email address connection.
Facebook Authentication Process
To use the Facebook authentication process, your district or school must Enable Facebook on the Authentication page in Global Settings.
When a user chooses Facebook for their login, Facebook shares information about the user including the profile and email address. When user clicks Sign In using Facebook, the Community Engagement product will display the Facebook Account sign-in page. The user will need to type their Email or Phone number and Password and select Login to sign into Facebook.
If the login information is correct, the Facebook does allow the user to edit what can be sent to support. If the user clicks Edit This, the only information they can remove is the email, which support requires. If the user selects, Continue as (their name), Facebook will send the profile information to the Community Engagement product. If this is the first time the user is signing in with Facebook, support will then verify that the email address is available to a user account. If it is, the Facebook profile will be saved for the user and support will authenticate the user and the user will be logged into the product. If the email does not exist in a user account, the user will not be authenticated and will not be logged in.
The next time the user signs in using Facebook, as long as the login is correct, Facebook will pass the email and profile to the Community Engagement product. Since the profile is already stored, the user will be authenticated and will be logged into the product without having to recheck the email address connection.
Student ID/Birthdate Authentication Process
To use the Student ID/Birthdate authentication process, your district or school must enable Student ID/Birthdate Sign Up on the Authentication page in Global Settings.
Unlike the Google and Facebook authentication process, the Student ID/Birthdate authentication does not connect to a third-party application. The SIS must include the student identification number and birthdate information. As a result, this method is only opened to students and parents.
When user clicks Sign In using Student ID and Birthdate, the Community Engagement product will display the Sign Up box. The user will need to type the Student ID number the Student Birthdate and select Next. If all accounts have already been claimed for the student, then authentication will fail, and the user will be requested to select Forgot Password. If a user account is available for that student, then Sign Up box will display the create login and password information. The user will need to select their name and agree to terms and conditions. Then they will need to type a new Login ID, Password, and Re-type Password. Then when they select Sign Up, the Login ID will display their new information, and they will need to type their Password and select Sign In.
Lightweight Directory Access Protocol (LDAP) Authentication Process
To use the LDAP authentication process, your district or school must enable LDAP on the Authentication page in Global Settings, and set the server and certificate information.
Using your LDAP directory server allows your district or school to provide single sign-in where one user name and password is shared between many different services, including Community Engagement products. The information from your LDAP server will be used to authenticate the user. Users will not be able to update their user names or passwords through the platform.
When a user attempts to sign in to a Community Engagement product, that user is authenticated. The user types their sign-in name and password in the standard fields. When a user first logs in, if the information is not found in the system, the information is checked against the LDAP Directory. If found there and the sign in name and password are correct, the LDAP sign in information is passed back to support and the user is authenticated. If the user is not found on LDAP, or the name and password is not correct, the user will not be logged in, unless the information is found in one of the other authentication processes.
Security Assertion Markup Language (SAML)
Some districts and schools use a third-party identity provider for user authentication. The district or school is in charge of their own identity management and provide support with the details on how to connect using Security Assertion Markup Language (SAML). This feature was designed for staff members, such as teachers, to sign in with their standard credentials.
The district or school supplies support with the sign-on button feature. When user clicks Sign In using <School>, the Community Engagement product will display the district or school's account sign-in page. The user will need to type their information.
The SAML code will send that information to the third-party identity provider. The identity provider will provide the user authentication to via SAML. If the identity provider authenticates the user, the Community Engagement product will display. If the information is not correct, the user will not have access.