<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=9393386&amp;fmt=gif">
Skip to content
English
  • There are no suggestions because the search field is empty.

Connecting Your Single Sign-On (SSO) to CampusGroups

Configure your identity provider so students and staff can sign in to CampusGroups with their institution credentials

CampusGroups (CG) can connect to your institution's Identity Provider (IdP) to authenticate users through Single Sign-On (SSO).

We support two SSO protocols, CAS and SAML, configured as Service Provider (SP)–initiated connections. We support InCommon Federated services and most standard identity providers, including Shibboleth, ADFS, Microsoft Entra ID (formerly Azure AD), and Okta.

Who should do this: Your institution's IT team, working with Ready Education's teams.

The SSO setup process

Setting up SSO is a conversation between your CampusGroups platform administrator, your IAM team, and our Client Experience teams. A typical flow follows this path:

  1. Your team configures a new Service/Application connection in your IdP for CampusGroups. This creates the connection point your IdP will use to authenticate CampusGroups users
  2. Your team sends us your Service/Application connection information. We need these details to configure the matching connection on our end
  3. Our team creates the connection for your chosen SSO protocol
  4. Our team sends back testing and verification instructions, so you can confirm the connection before anyone relies on it
  5. Your team runs through testing and reports the results back to us. This catches configuration issues before students and staff depend on SSO to log in
  6. Once testing confirms everything works, our team activates the live SSO login button, enabling users to sign in through SSO

SSO identifiers

CampusGroups matches the identifying attribute(s) released from your IdP system against profile information for active users in your CampusGroups system. A mismatch in identifiers can cause users to fail to log in, or be logged into an incorrect profile. If you're unsure what fields will be configured for users in CampusGroups, connect with your platform administration to discuss what information will be provided with user provisioning.

For CAS-based IdPs

For CAS-based IdPs, all we need is the CAS Base URL from your IdP server. We'll then send you the information to complete the Service setup and test your login.

ℹ️ Note: Check what your CAS IdP releases as the cas:user value. If it doesn't match user email addresses, matching cas:user values need to exist in each CampusGroups profile for anyone signing in through SSO.

  1. Send our team the CAS Base URL for your CAS IdP server. This typically looks like https://login.example.com/cas/ or https://login.example.com/idp/profile/cas/
  2. We configure the CAS connection using the Base URL you provided
  3. We send back a Service URL for you to register in your CAS IdP's service registry
  4. Register the Service URL, then test your connection (see SSO login testing, below)
  5. Confirm with our team once testing is verified
  6. Our team activates the SSO login button in your platform

For SAML-based IdPs

💡 Tip: If your institution is a member of the InCommon Federation, configure your IdP to retrieve CampusGroups' metadata directly from InCommon using our Entity ID (listed below). Then just send us:

  • Your Entity ID
  • Confirmation of your institution's InCommon Federation membership

⚠️Caution: If your Application-scoped Metadata includes the <ContactPerson> element, every child element you define must contain text. Empty child elements (e.g., <EmailAddress/>) will cause your entire metadata file to fail validation, blocking login. To prevent this, any <ContactPerson> child element must be populated with text, the empty <ContactPerson> child element removed, or the <ContactPerson> element omitted entirely.

To create a new Application for the CampusGroups connection, use the information below.

  1. Configure a new Application (or Service Provider connection) in your IdP for CampusGroups. If your institution is a member of the InCommon Federation, you can skip most of this as noted above
  2. Add our Service Provider as a trusted party. If your IdP has a setting to verify certificates, set this to No
  3. Enter the CampusGroups SAML Service Provider information into your Application:
  1. Release at least one Attribute to validate against CG User Profile identifiers. CampusGroups can accept up to three Attribute values (eppn, mail, and uid). Claims/Attributes must use the standard urn:oid namespace as their Name/Attribute ID, with the release value set to the corresponding field in your IdP:
    • eppn values should be named urn:oid:1.3.6.1.4.1.5923.1.1.1.6. Best choice if you've already configured the eduPerson schema in your IdP
    • mail values should be named urn:oid:0.9.2342.19200300.100.1.3. Best choice if the primary identifier you're releasing also serves as a valid email address for the user
    • uid values should be named urn:oid:0.9.2342.19200300.100.1.1. Best choice if the primary identifier you're releasing is a unique, non-email or non-scoped identifier
  2. Send us your IdP Entity ID, your metadata URL, and the Attribute values you've configured for release (see SSO login testing, below, for what happens next)

⚠️Caution: Application-scoped SSO configurations (for example, Microsoft Entra ID, Google Workspace, or Okta) must use the application-specific metadata URL, not the generic domain or tenant metadata endpoint. Depending on the platform, the application identifier may appear as a query parameter (Entra ID's ?appid=) or as part of the URL path (Okta's /app/<name>/<app-id>/..., Google's /samlrp/<app-id>).

SSO login testing

Once we receive your IdP information, our team creates the connection in your CampusGroups platform and sends you a testing URL.

Testing your SSO connection

  1. In an incognito window (or a browser not actively used to authenticate through SSO), paste the testing URL our team provided
  2. Your institution’s authentication screen should appear
  3. Enter the credentials of a test user authorized to use the connection

If you're testing a CAS connection

  • If authentication succeeds, you're loaded into your CampusGroups system. Confirm with our team, and we'll activate your SSO login button
  • If authentication doesn't succeed, verify that the test user has permission to authenticate to the configured Service connection, and that their CampusGroups profile includes matching data released from cas:user

If the error continues, send our team:

  • A full-screen screenshot of the error page, with the address bar visible
  • The full URL of the error screen
  • If you see a CampusGroups "We've run into a problem…" error screen, click Alert Support to send the error report to our team
  • The approximate time of the error and the test user's email address as it appears in your CampusGroups systems

If you're testing a SAML connection

  • If you're brought to your platform's Home Page, login works. Confirm with our team, and we'll activate your SSO login button and send you instructions for updating your login button and labels.
  • If you're returned to the CampusGroups Sign In page with a message that a profile wasn't found, authentication succeeded, but we couldn't find a matching profile for your released attribute values.
    1. Verify that the user account you authenticated with has a profile in CampusGroups
    2. If there's no profile, contact a platform admin for help creating one
    3. Verify that the profile has values matching what your IdP releases
    4. Once you've confirmed a matching, active profile, test the login again from the beginning
  • If you're returned to the Sign In page with no message, authentication succeeded, but this usually means no attributes are being released for verification. To confirm this, we need a capture of your released session attributes.
    1. Start again in a new incognito window or browser, fully closing any previous window used for a login test
    2. Authenticate as before
    3. When you're returned to the Sign In page, go to https://www.campusgroups.com/Shibboleth.sso/Session in the same tab. This screen shows which attributes are being released. If the attribute section is blank, no values are being released in a format our system expects
    4. Copy the text on that screen (or take a screenshot) and send it to our team so we can identify which attributes are missing

ℹ️ Note: If you're on Microsoft Entra ID or ADFS, double-check that your urn:oid value is entered in the Name field not the Namespace field. This is a common cause of no attributes releasing (see also the note in Releasing Attributes, above).

SSO go-live

Once your SSO testing is confirmed as working, our team activates your SSO login button. This lets users reach SSO login directly from your platform's login screen, at https://[yourPlatformDomain]/webapp/auth/login.