University of Maine System (UMS) staff and faculty who are evaluating or purchasing software can use this reference to understand which single sign-on (SSO) protocols UMS supports, which user attributes UMS releases to vendors, and what to ask a service provider before committing to a product.
Detailed Information
Product evaluation questions
When evaluating a product, ask the vendor these four questions early:
- Do you support SAML 2.0 or OpenID Connect (OIDC) with Microsoft Entra ID?
- Do you support SCIM (System for Cross-domain Identity Management) for automated account provisioning?
- Can you accept an opaque, non-email identifier as the unique user ID?
- What is the minimum set of user attributes your product requires?
UMS centralizes authentication on Microsoft Entra ID. All new SSO integrations should target Entra ID directly. Legacy protocols and platforms (CAS, direct Shibboleth integrations outside of InCommon) are being retired and are not available for new integrations.
To begin an integration, submit an SSO Integration Request. Include the vendor's SSO documentation and the list of attributes the product requires.
Supported protocols, in order of preference
| Preference |
Protocol |
When it applies |
| 1 — Preferred |
Microsoft Entra SAML 2.0 (Security Assertion Markup Language) |
The default choice for most enterprise and software-as-a-service (SaaS) applications. Mature, widely supported, and allows UMS to release a rich set of user attributes. |
| 2 — Preferred |
Microsoft Entra OpenID Connect (OIDC) |
A modern protocol built on OAuth 2.0. A strong choice for newer cloud-native applications, mobile apps, and applications that also need API authorization. Note that fewer UMS attributes are available over OIDC than over SAML (see attribute table below). |
| 3 — By exception |
InCommon federation (Shibboleth) |
Only for service providers involved in research and scholarship that specifically require InCommon federation membership. UMS maintains its Shibboleth identity provider solely to serve InCommon integrations. |
Protocols and integration patterns UMS does not accept for new integrations: CAS protocol, SAML 1.1, direct Lightweight Directory Access Protocol (LDAP) binds from vendor systems, and password-based ("credential vaulting") sign-in.
Account provisioning: SCIM preferred
UMS prefers service providers that support SCIM 2.0 for automated account creation, update, and deactivation. SCIM allows the Microsoft Entra provisioning service to manage vendor accounts automatically, which means faster access for new users and — critically — prompt deactivation when someone leaves the University. Vendors whose products only support just-in-time (JIT) provisioning from the SAML assertion, manual account creation, or flat-file imports will be asked to explain their account deactivation story.
INFO: In April 2026, Microsoft announced generally available SCIM 2.0 APIs that also allow Microsoft Entra ID to act as a SCIM service provider (accepting inbound SCIM requests), in addition to its long-standing role as a SCIM client that pushes accounts to vendor applications. For vendor integrations, the relevant requirement is still that the vendor expose a SCIM 2.0 endpoint compatible with the Microsoft Entra provisioning service. See the links under Additional resources.
Unique user identifier: do not use email address
UMS prefers that service providers accept eduPersonUniqueID as the unique identifier for each user. It is a long-lived, non-reassignable, omnidirectional identifier unique to each individual (example format: TFHOTK5CZ2MH...KRAS7A@maine.edu). Because it never changes and is never reassigned to another person, it is the safest key for a vendor to store.
WARNING: UMS strongly discourages using email address (mail) or the sign-in name as the unique identifier in a vendor's system. Email addresses at UMS change frequently (name changes, preferred name updates, campus changes). When a vendor keys accounts on email address, a routine name change breaks the user's access and orphans their data. Vendors should treat email as a contact attribute only, subject to change at any time.
Attributes UMS releases to service providers
UMS follows a data minimization practice: a service provider receives only the attributes its product genuinely requires to function, and no more. Requests for additional attributes must include a justification. The following attributes are available for release, depending on the protocol used.
Available via Microsoft Entra integrations:
| Attribute |
Description |
Entra SAML 2.0 |
Entra OIDC |
eduPersonUniqueID |
Preferred unique identifier. Long-lived, non-reassignable, omnidirectional identifier unique to each individual. |
Yes (available) |
No (not available) |
givenName |
First name |
Yes (available) |
Yes (available) |
sn |
Surname (last name) |
Yes (available) |
Yes (available) |
displayName |
Preferred display name |
Yes (available) |
Yes (available) |
mail |
Email address — contact use only; subject to change; not a unique identifier |
Yes (available) |
Yes (available) |
mainePersonPrefGivenName / mainePersonPrefMiddleName / mainePersonPrefSurName |
Preferred first, middle, and last names |
Yes (available) |
No (not available) |
eduPersonAffiliation / eduPersonPrimaryAffiliation |
Relationship(s) to the institution (faculty, student, staff, employee, retired, affiliate, member) |
Yes (available) |
No (not available) |
eduPersonScopedAffiliation |
Affiliation qualified by security domain (for example, staff@maine.edu) |
Yes (available) |
No (not available) |
departmentNumber |
Department code(s) |
Yes (available) |
No (not available) |
mainePersonSID |
Student/employee ID number — released only with strong justification (elevated PII sensitivity) |
Yes (available) |
No (not available) |
mainePersonType |
Account type (for example, primary) |
Yes (available) |
No (not available) |
mainePersonLogonStatus |
Logon status (for example, active) |
Yes (available) |
No (not available) |
| Group membership |
Filtered group memberships are synchronized as Entra group claims and can be released where authorization requires them |
Yes (available) |
Yes (available, as group claims) |
Available via InCommon (Shibboleth SAML) integrations only:
eduPersonPrincipalName — the institutional "NetID" in user@scope form (newer configurations release eduPersonUniqueID instead)eduPersonUniqueID, eduPersonScopedAffiliation, givenName, sn, mail, and preferred name attributesisMemberOf — group membership identifiersemployeeNumber — released only with strong justificationeduPersonAssurance — identity assurance URIs, per federation requirements
Minimizing personally identifiable information (PII)
Every attribute released to a vendor increases the impact of a vendor-side data breach. When negotiating with a service provider, UMS applies these principles:
- Least data necessary: the default attribute release is the preferred unique identifier plus name and, where genuinely needed, email. Anything beyond that requires a documented functional need.
- Opaque identifiers over meaningful ones:
eduPersonUniqueID reveals nothing about the person; identifiers such as email address or student ID do. Vendors should key on the opaque value.
- Sensitive attributes are restricted: student/employee ID numbers (
mainePersonSID, employeeNumber) and similar high-sensitivity values are released only when the product cannot function without them.
- Affiliation over enumeration: where a vendor only needs to know "is this person faculty/staff/student," release an affiliation value or group claim rather than personal detail.
Ready to move forward? Submit an SSO Integration Request and the identity team will review the product's protocol support, provisioning options, and attribute requirements with you.
Additional resources
Environment
- Microsoft Entra ID
- SAML 2.0 / OpenID Connect (OIDC) service provider integrations
- SCIM 2.0 provisioning
- InCommon federation (Shibboleth)