SSO Guide

Stellic integrates with your institution’s single sign-on (SSO) system to provide a seamless login/logout workflow for end users. Stellic does not maintain a backdoor into your institution’s instance, so SSO is the only means for access to your institution’s instance. This ensures that you have full control of access through your own directory structure. (Stellic will ask you to provide and manage user accounts for Stellic admins.)

In addition, it may be helpful to note that Stellic will not load any student data into your institution’s Stellic instance until SSO is established for security purposes. This, along with the user accounts that you will create for the Stellic team to use, ensures that you retain control of access to your institutional data at all times through your own institutional access policies.

Integration Options

Stellic already supports integration with a number of SSO systems. If your current system is not listed below, please contact us and we will be happy to work with you to support your specific SSO solution.

Stellic also honors MFA wherever applicable.

Shibboleth

Stellic is a member of the InCommon Federation. You can find Stellic’s Metadata from http://md.incommon.org/InCommon/InCommon-metadata.xml. If you are not a member of InCommon, Stellic will provide our metadata directly to your institution.

Other SAML-based Solutions

In addition to Shibboleth, Stellic can work with any SAML-based authentication system. We currently support the following systems:

• ADFS

• Azure AD

• Okta

• Ping Identity/PingFederate

• Google SAML

• Populi

CAS

Stellic supports institutions that use the Central Authentication Service (CAS) for their SSO protocol.

LDAPS

Stellic supports but does not recommend the use of LDAPS (Secure LDAP or LDAP over SSL).

Integration Mechanism

The SSO integration matches the institution’s chosen attribute with the user identifiers to log in the appropriate user. Typically, the user identifiers are either the username or the ID from the student and non-student user feeds. More information around the data feeds can be found in our full data integration guide (which will be shared with your institution once we begin the implementation process).

SSO provides the first level of authentication to access the Stellic platform. Use of Stellic and access to data within Stellic are based on other factors as determined by the institution, such as user type, activation status, and advisor relationships from SIS. Stellic supports user activation/deactivation and permission provisioning, either within the platform itself or via SSO attributes that can drive user authorizations upon login.

Account for the Stellic Team

One additional requirement for Stellic to operate within your SSO environment is the need for a “break glass” account within your institutional directory for the Stellic team to use to access the platform. While the Stellic team can access the platform through our own SSO infrastructure, we need one account that you create for our team to use to validate SSO is operational.

Stellic is happy for this account to be a standard vendor account and it can also be a named account (associated with a specific Stellic team member). Your Stellic implementation team will provide the name and credential (phone number, etc.) for this account. We require that this account is persistent since we will need access throughout your use of the Stellic platform. If you have specific password change policies, we will also need to ensure appropriate communication is sent to this individual so the password can be changed in a timely manner and there is no support disruption.

When this account is provided, you will also need to ensure that it includes the same attribute that will be used for all other accounts (students and other users) so it can be identified in the SSO response. This may necessitate the addition of an ID number or other username in your institutional systems to operate properly.

Platform URL

Stellic automatically creates a URL at [institutionID].stellic.com but we recommend that you also choose a URL that matches a subdomain of your own institutional .edu site (e.g., stellic.[institution].edu). You will enter your preferred URL in the configuration sheet and we will use the preferred URL when creating your Stellic instance. Once the URL is finalized, we will send you a metadata file for your instance (since the metadata is dependent on the URL) with the platform URL as an ACS URL in the file.

CNAME Setup (Optional)

Institutions that desire a .edu address for their Stellic site will need to complete additional steps to enable Stellic to “redirect” users to your URL. This is a relatively simple process that requires your DNS team to add a CNAME record for the desired subdomain and points to the server URL ([institutionID].stellic.com as noted above).

In addition to this basic CNAME record, the Stellic implementation team will provide to you another CNAME name and value pair to add to your DNS settings. Stellic uses the AWS certificate manager and these settings will allow us to correctly connect your CNAME values to our site for the selected URL. Examples of this CNAME pair are included below

CNAME name: _9236c5cb96da7bee992eda0d7f9c88.stellic.abc.edu.

CNAME value: _39fa8d672ea4dd2894cd0b6ff6.mhbtsbpdnt.acm-validations.aws.

Setup Process

SSO setup can begin after we have used your institution’s configuration data to create the instance for your institution. Once that is done, we will work with you to complete the SSO setup so that users can access your Stellic instance.

Next Steps (SAML Types, including Shibboleth)

Once you have determined the URL, Stellic will send you a metadata file (including our entityID) that you can load into your system for configuration from your end. We will then ask you for the following:

1. IdP metadata file. This is ideally a public link, such as may be available with InCommon, but we can also work with a static file; a static link will be need to be updated occasionally.

2. One (1) named user account in your directory service (e.g., Active Directory; as noted above). This account is for the Stellic team to use to login to your platform (see below) and test that SSO is functioning as expected with the specific attribute that is being requested.

3. The details of the principal SAML attribute (name, friendly name) that will be released to us to log in the appropriate user. This attribute cannot be the NameID in the SAML response and “nameformat” must be "uri”. These details must also match what is sent in the username column in the student and non-student user data files, along with any other secondary attributes that you plan to send to us (name, email, etc.).

4. Logout URL. This is the link to which we will redirect users once they press logout within Stellic to log them out of SSO completely (aka, “kill” the user’s session)..

5. If you intend to use a subdomain of your .edu site for your Stellic instance, you will also need to create a CNAME record to your institution’s stellic.com URL. Stellic will provide you with the details needed to complete this setup. This will take place after Stellic has created your instance so you can point to it in your DNS settings.

Next Steps (CAS)

To setup access via CAS to your Stellic platform, we need you to send us the following:

1. CAS Protocol Version

2. URL for CAS service

3. Logout URL

4. One (1) named user account in your directory service (as noted above). This account is for the Stellic team to use as a “break glass” to login to your platform and test that SSO is functioning as expected with the specific attribute that is being requested.

5. You should also whitelist the domain (for example, stellic.[institution].edu as noted above)

Next Steps (LDAPS)

Stellic will require the following from the institution to set up an LDAPS (Secure LDAP) integration:

1. Host name

2. Port

3. Username/bindDN

4. Base DN

5. One (1) test account in your directory service (Active Directory).