Single Sign-On Setup Worksheet – EdVisorly

This article is a worksheet for setting up SAML single sign-on (SSO). The General section applies to any SAML 2.0 identity provider (IdP). If you use Microsoft Entra ID, please also complete the Microsoft Entra ID section below.

The complete domain list (A1), the attribute carrying email (A2), and the NameID format (A3). These are marked Needed first below. If it's easier to send those first and follow up with the rest, please do. We can begin configuration as soon as we have them.

How to complete this worksheet

Fill in the Your answer column for each question. If a question doesn't apply, write "N/A".
Copy the completed tables into a reply to your EdVisorly contact or support ticket, or paste them into a document and attach it.
If you're unsure about a question, send what you have. We'll follow up on anything that's unclear.

Institution
Completed by (name, title, email)
Identity provider (Microsoft Entra ID, Okta, Shibboleth, Google, other)
Date

General (any SAML 2.0 identity provider)

Attributes & Identifiers

#	Question	Why we ask
A1 Needed first	The complete list of email domains your staff use to sign in, including any subdomains, legacy domains, or department-specific domains.	We route users to your IdP by domain, so any domain left off this list will fail to sign in via SSO.
A2 Needed first	Which SAML attribute carries the user's email address, and is it marked verified in your directory? Are `given_name` and `family_name` included in the assertion?	Email is how we match a person to their EdVisorly invitation, and the name claims populate your staff roster.
A3 Needed first	Is the NameID persistent per user, and in what format: `persistent`, `emailAddress`, `unspecified`, or `transient`?	A transient NameID changes on every login, which would prevent us from reliably linking an account to a person.
A4	Do any staff have more than one email address on file (e.g., a directory address plus an alias)? Which one will your IdP assert?	If the asserted address differs from the address your administrator typed when inviting a colleague, that invitation can't be claimed. We normalize case and spacing, but we can't resolve `jdoe@` against `john.doe@`.
A5	Who we should make the first team admin (first name, last name, email)

Protocol & Trust

#	Question	Why we ask
T1	The URL for your IdP's SAML metadata (preferred), or a static metadata file if a URL isn't available. Entra ID customers: see E2 for the specific URL we need.	Reading metadata from a URL lets us pick up certificate changes automatically.
T2	Do you require signed AuthnRequests and/or encrypted assertions?	We configure the connection to match your requirements.
T3	Who owns certificate rotation on your side, on what cadence, and how much advance notice should we expect?	A missed rotation is a full outage for every user at your institution, so we'd like this as a standing contact rather than a one-time answer.

Access Control

Access is controlled by app assignment in your own directory. We'll ask you to require user assignment on the EdVisorly application, then assign the users or groups who should be able to sign in. Your IdP refuses to issue an assertion for anyone not assigned, so the access gate stays in your directory rather than ours.

#	Question	Why we ask	Your answer
C1	Which group or groups will you assign to the application, and approximately how many staff does that cover?	Staff are invited individually, so headcount tells us how to plan invitations with your Team Administrator.
C2	Who maintains that assignment as staff join and leave?	This is who we'll point to when someone can't sign in.

Policy

#	Question	Why we ask	Your answer
P1	Are there any access or sign-on policies (IP allowlists, device-compliance requirements, conditional or adaptive access rules) that could block our connection?	These can block sign-in in ways that look like an EdVisorly problem, so we'd like to know about them up front.

Logistics

#	Question	Why we ask	Your answer
L1	Can you stand up a non-production SAML connection along with a test account, so we can exercise the integration outside your production IdP?	This lets us validate sign-in before go-live without touching your production IdP.
L2	Who is the IdP administrator we should work with directly, and what's their typical change window or freeze calendar?	So we can schedule configuration and testing around your change process.

What this setup covers

No answer needed. Please review these so nothing is a surprise at go-live.

Single Logout is not part of this phase. Signing out ends the EdVisorly session only. It does not end the session at your IdP or sign the user out of other applications. If Single Logout is a hard requirement for your institution, please tell us now rather than at sign-off.
One institution per identity. A single directory identity maps to one institution
Roles are managed in EdVisorly, not derived from your groups. Your group assignment controls whether someone can sign in. Their roles in the product are chosen by your Team Administrator when the invitation is sent, and can be changed later in team settings.
Removing someone from the assigned group blocks their sign-in immediately. It does not remove them from your EdVisorly roster. That is a separate action by your Team Administrator.
IdP-initiated sign-in is disabled by design. All sign-ins begin at EdVisorly, including clicks on an app tile.
Your identity provider is the only place a second factor is applied. Because authentication happens at your IdP, EdVisorly does not add an MFA prompt of its own. Whatever MFA policy you enforce is the policy your staff experience when they sign in.

Microsoft Entra ID

Complete this section only if you use Microsoft Entra ID.

#	Question	Why we ask
E1	Which Microsoft Entra ID edition are you using: Free, P1, or P2?	Assigning groups to an enterprise application, which is how access is controlled (see Access Control), requires P1 or P2.
E2	Entra publishes metadata per application at `https://login.microsoftonline.com/<tenant-id>/federationmetadata/2007-06/federationmetadata.xml?appid=<app-id>`. Please send the per-application URL rather than the tenant-wide one.	Reading it live means a certificate rotation on your side is a non-event. A pasted copy means every user is locked out the moment it rotates, with no warning to us.
E3	Will you publish an app tile for EdVisorly in My Apps? If so, please configure it in Linked SSO mode pointing to `https://app.edvisorly.com/api/auth/login`, rather than as an SSO-initiated app.	IdP-initiated sign-in is disabled, so the tile must send users to Edvisorly to begin sign-in.
E4	Please register the EdVisorly enterprise application with `User assignment required = Yes`, then assign the groups you listed in C1. Can you confirm this setting? Optional: the object IDs of the assigned groups.	This setting is what makes your directory the access gate. We keep object IDs for support reference only (to tell your admin which assignment to check), not for configuration.