Roster: Define Login Options

We allow flexibility in how you plan to define your username fields for students and teachers. While a district username or email are most common, some districts may need to set {username} + “mydistrict.com” or some combination of a field and a string to meet their needs.  

For OneRoster API or CSV, you can use any of the following commonly used fields in defining a custom formula (fields are case sensitive).

sourcedId

username

email

identifier

 

If needed, additional username fields are allowed. Click to view.

 

To use any of these fields, it needs to be placed in curly brackets.  

Example:  {username}.  

Anything added to the formula that is NOT inside the curly brackets will be treated like a string text constant if using a combination of multiple fields and/or string text

Example:  {username}  - 2020-2021

 

*Note:

–      A common CUSTOM formula if using SSO could be: {username} @mydistrict.com  

–      These are the only fields we support at this time. We do not support metadata fields, custom fields, or partial fields of existing values.  

●      What type of log in options do users have?

You can use the standard Platform Login Page or setup a single sign on (SSO) option, such as Google or SAML. If you have an alternate IDP need (such as OpenID Connect), we suggest Clever or ClassLink as an SSO Partner until we can provide you with self-service tools to complete this work in a future release.

 

●      Does HMH Support Alternate Solutions for logins such as ClassLink or Clever?

If you are in need of rostering assistance or centralized login, you can work with one of our rostering partners—ClassLink or Clever. (Click links for more information on each.)

 

●      Why should my organization specify usernames?

The default for student and teacher username = {username}. We recommend a global username, such as {email}, be set to make those systems compliant. If you decide to use {email}, be sure it is populated for your user base; often this field is empty, which will lead to errors in creating accounts.

 

●        Can I print out or see passwords for my students?  

We follow industry standards security solutions when it comes to the storing and handling of any account credentials and as such they are not displayable in our database nor our platforms.  

For example: If your password could be printed and left on a desk or if the database was hacked or stolen, anyone who got access to this information would be able to reverse engineer the field or get the passwords in plain text. These passwords might also be the same password for a users' bank account, Amazon account, PayPal, or Sony PlayStation. While customers should keep passwords separate across hosted platforms, many do not, as they cannot remember all of them. In addition to teaching core content, teaching best practices in a digital world is paramount as a core learning need. For these reasons, passwords cannot be shown in plain text on a report. We strongly recommend using a single sign on (SSO) connection to enhance security while keeping login easy for end user or purchasing enhanced login solutions with ClassLink where you can use Face ID, QR Codes, or Badge to get access into our software.

 

●        If I use OneRoster API, how do I know what the passwords are?

We strongly recommend using an SSO connection or working with your data provider to populate the password field of the OneRoster API data feed and then communicate the correct login path to your end users. If this data is not populated, teachers will need to follow the forgot your password workflow and then change the password for each student in their class.

If you are interested in Face ID, QR Codes, Badges, and other offerings, you can purchase an SSO plan through ClassLink .  

 

To define your login options:

 

This option allows all users to interact with the Platform Login page instead of using SSO. The format you select for rostering determines the username and password options that are allowed. If using OneRoster, we strongly recommend using SSO.

To learn more about authentication options when using OneRoster, see the OneRoster Authentication Considerations topic.

 

1.    Type an object in the Teacher Username and Student Username fields.

–      It is critical that this username be unique across all users and all locations within your district.

–      It is recommended that you implement globally unique usernames, such as {username}@mydistrict.com or customusername + @mydistrict.com.

–      If you operate as an independent school, do not have a SIS, or are a private/Catholic school, consider these recommendations. (Click for details.)

–      If you are using Simple File Format, the SFF import file requires the use of the default {username} field, so you cannot customize this field.

–      The default for student and teacher username = {username}. If you use OneRoster, however, we allow you to configure which field or formula in your import you want to use for teacher or student usernames.

 

2.    Click Next to continue.

To define your Google Workspace SSO login options:

 

1.    Type an object in the Teacher Username and Student Username fields.

–      It is critical that this username be unique across all users and all locations within your district.

–      If you operate as an independent school, do not have a SIS, or are a private/Catholic school, consider these recommendations. (Click for details.)

–      If you are using Simple File Format, the SFF import file requires the use of the default {username} field, so you cannot customize this field.

–      The default for student and teacher username = {username}. If you use OneRoster, however, we allow you to configure which field or formula in your import you want to use for teacher or student usernames.

–      If you are using SSO, the value entered here MUST match the SSO username you are importing. If you are certain that all users have {email} populated in the data being sent and that is the value being sent for your SSO Identity Provider username, then you can simply apply that field. If your students do not have emails populated in the data files, then we suggest that you add a custom entry here, such as {username} + @mydistrict.com; for example: "{username}@SSOdistrict1.com".

Google SSO is the most common due to Chromebooks.

See SSO Considerations for password set up recommendations.

 

2.    Select the Add Google Workspace button.

This option is common for districts using Chromebooks, Google Classroom, and Google SSO. The key factor in a successful setup with Google SSO is that you roster your users with their Google Username because that is the key linking field between systems. If using OneRoster API, fields are provided to help align your usernames.

To learn more about authentication when using OneRoster, see the OneRoster Authentication Considerations topic.

If using other formats, be sure the username in the import file with matches the Google SSO Username.

 

3.    In the Name field, type a name for the connection. we allow you to enter a custom display name for one or many SSO connections. Popular names include "Student SSO" vs. "Teacher SSO".

 

4.    Enter your Client ID and Client Secret. To obtain this data from Google, follow these steps:

a.    Open the Google API Console Credentials page.

b.    From the project drop-down list, select an existing project or create a new one.

c.    On the Credentials page, select Create credentials, and then select OAuth client ID.

d.    Under Application type, choose Web application.

e.    Click Create.

 

5.    Depending on your preferences, move up to the Global SSO Settings area and select to enable either of the following:

–      Redirect users to login using SSO – forces all users to login through SSO, rather than logging in through the Platform login page

–      Redirect HMH Player users to login using SSO – forces all users to login through SSO, rather than logging in through the HMH Player® login page

Most districts should select these check boxes (turn ON the option) because most districts want all their users to be forced to go through SSO to log in rather than logging in using the platform page.

 

6.    Click the Add button. The system will provide you SSO endpoints for all supported systems such as Ed, Heinemann, ThinkCentral, Holt McDougal Online, and more, which you will need to update your portal page for your end users. If you do not use these other systems, you can ignore the URL. Copy the URLs you plan to use and update your portal page for all users.

Important: Be sure to copy these URLs for future use.

 

7.    Copy the redirect URL.  

Note: If you do not get the redirect URL and if you use an endpoint from the previous step, you might get an error. Click to view example of error.       To resolve this issue, be sure to open the request details area, copy the redirect URL at the bottom, and follow Google for correct placement of this information: https://console.developers.google.com/apis/credentials   Be sure to highlight the web application on this page: Setting up OAuth 2.0

 

8.    If needed, add another SSO method or click Next to continue.

To define your OpenID Connect login options:

 

1.    Type an object in the Teacher Username and Student Username fields.

–      It is critical that this username be unique across all users and all locations within your district.

–      If you operate as an independent school, do not have a SIS, or are a private/Catholic school, consider these recommendations. (Click for details.)

–      If you are using Simple File Format, the SFF import file requires the use of the default {username} field, so you cannot customize this field.

–      The default for student and teacher username = {username}. If you use OneRoster, however, we allow you to configure which field or formula in your import you want to use for teacher or student usernames.

–      If you are using SSO, the value entered here MUST match the SSO username you are importing. If you are certain that all users have {email} populated in the data being sent and that is the value being sent for your SSO Identity Provider username, then you can simply apply that field. If your students do not have emails populated in the data files, then we suggest that you add a custom entry here, such as {username} + @mydistrict.com; for example: "{username}@SSOdistrict1.com".

See SSO Considerations for password set up recommendations.

 

2.    Select the Add OpenID button.

This option is common for districts using OpenId Connect based SSO authentication. The key factor in a successful setup is that you roster your users to HMH systems with their OpenId Connect Username because that is the key linking field between systems. If using OneRoster API, fields are provided to help align your usernames.   

To learn more about Authentication when using OneRoster, see the OneRoster Authentication Considerations topic.

If using other import formats, be sure the username in the import file with matches the OpenId Connect Username.

 

3.    In the Name field, type a name for the connection. We allow you to enter a custom display name for one or many SSO connections. Popular names include "Student SSO" vs. "Teacher SSO".

 

4.    Type your Tenant Domain URL.

 

5.    Type your Client ID.

 

6.    Type your Client Secret.

 

7.    Depending on your preferences, move up to the Global SSO Settings area and select to enable either of the following:

–      Redirect users to login using SSO – forces all users to login through SSO, which disables the ability to login via the HMH Platform login page

–      Redirect HMH Player users to login using SSO – allows the centralized user store login credentials to be used with HMH Player®

Most districts should select these check boxes (turn ON the option) because most districts want all their users to be forced to go through SSO to log in rather than logging in using the platform page.

 

8.    Click the Add button. The output URLs to your portal page are displayed.

Note: Be sure to copy these URLs for future use.

 

9.    If needed, add another SSO method or click Next to continue.

To define your SAML login options:

 

1.    Type an object in the Teacher Username and Student Username fields.

–      It is critical that this username be unique across all users and all locations within your district.

–      If you operate as an independent school, do not have a SIS, or are a private/Catholic school, consider these recommendations. (Click for details.)

–      If you are using Simple File Format, the SFF import file requires the use of the default {username} field, so you cannot customize this field.

–      The default for student and teacher username = {username}. If you use OneRoster, however, we allow you to configure which field or formula in your import you want to use for teacher or student usernames.

–      If you are using SSO, the value entered here MUST match the SSO username you are importing. If you are certain that all users have {email} populated in the data being sent and that is the value being sent for your SSO Identity Provider username, then you can simply apply that field. If your students do not have emails populated in the data files, then we suggest that you add a custom entry here, such as {username} + @mydistrict.com; for example: "{username}@SSOdistrict1.com".

See SSO Considerations for password set up recommendations.

 

2.    Select the Add SAML button.

This option is common for districts using SAML based SSO authentication. The key factor in a successful setup is that you roster your users to our systems with their SAML Username because that is the key linking field between systems. If using OneRoster API, fields are provided to help align your usernames.

To learn more about authentication when using OneRoster, see the OneRoster Authentication Considerations topic.

If using other import formats, be sure the username in the import file matches the SAML Username.

 

3.    Type your SAML Metadata URL.

 

4.    In the Name field, type a name for the connection. We allow you to enter a custom display name for one or many SSO connections. Popular names include "Student SSO" vs. "Teacher SSO".

 

5.    Depending on your preferences, move up to the Global SSO Settings area and select to enable either of the following:

–      Redirect Ed users to login using SSO – forces all users to login through SSO, which disables the ability to login to Ed through the Platform login page

–      Redirect HMH Player users to login using SSO – allows the login credentials to be used with HMH Player®

Most districts should select these check boxes (turn ON the option) because most districts want all their users to be forced to go through SSO to log in rather than logging in using the platform page.

 

6.    Click the Add button. The output URLs to your portal page are displayed.

Note: Be sure to copy these URLs for future use.

 

7.    If needed, add another SSO method or click Next to continue.

Warning: If using SAML/ADFS, which requires certificates, be sure that you have a plan to manage expirations annually or you may run into login issues.