Skip to content Skip to site navigation Skip to service navigation

A Quick Guide to Onboard Service Provider for SingleSignOn at Stanford


The process of integrating web applications, also known as Service Providers, with Stanford’s Single Sign-On (SSO) system is a self-guided task that can be accomplished through the use of Stanford’s Service Provider Database (SPDB). This database is available to Stanford faculty, students, and staff and serves as the primary resource for onboarding Service Providers to the Stanford SSO system.

SP Information To Collect Before You Start

Service Provider Checklist
SP EntityID
SP’s Metadata
Stanford contact email
Stanford workgroup name
Does SP support encrypted assertion


  • Service Provider’s EntityID

    • The Service Provider’s (SP) EntityID is a unique identifier that is typically provided by either your web application developer or vendor.
    • See "Guideline on entityID" for naming convention.
  • Service Provider’s metadata

  • Contact email

    • We would use the contact email for notification of Stanford IdP related upgrades and/or questions/issues related to the SP.
    • It needs to be a Stanford email (not a vendor email). mailman list is preferred (ex: )
  • A Stanford workgroup to associate with the SP

    • You would also need to have a Stanford workgroup to link to the SP; and the members of the workgroup(s) can update the SP’s metadata or workgroup release. To create a workgroup, visit Stanford Workgroup Manager.

IdP Information for SP Configuration

  • For Non-InCommon SP (most of SPs)

    • Stanford Production IdP
      • entityID :
      • Metadata :
      • SAML cert:
  • For InCommon SP

    • Stanford IdP’s entityID:
    • Stanford IdP’s metadata: via InCommon MDQ
  • If the Service Provider (SP) is unable to directly consume Identity Provider (IdP) metadata, the following information may be useful.

    • AuthnRequest endpoints
      • For HTTP-GET,
      • For HTTP-POST,
    • Single Logout,

Subject NameID

  • Stanford IdP supports both transient (default) and persistent nameid formats.
    • urn:oasis:names:tc:SAML:2.0:nameid-format:transient
    • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
  • If you prefer persistent nameid with a specific value (ex: eduPersonPricipalName), you can file SNOW from SPDB on your SP’s landing page.

Attribute Releases


Q: How often does Stanford IdP metadata expire?
The metadata of Stanford IdP is published weekly and is valid for one year. To ensure uninterrupted service, Service Providers (SPs) are strongly encouraged to download the metadata on a regular basis, and especially before it expires.
Q: What if my SP does not support encrypted assertions?
Stanford Policy requires all SP to support encrypted assertions; if you are working with SPs that do not support encrypted assertions, you need to file a SP encryption exception request before you can register the SP.
Q: Why cannot I write to SPDB?
Per Stanford Registry Data Owners approval, only users who are affiliated with Stanford directly can receive the default attribute releases automatically; sponsored-affilates would need explicit approvals from the data owners. See #Q1 for more details.
Q: Is there any non-prod IdP that we can test?
Yes, you can use IdP-UAT instance for your uat/dev instance. Onboarding procedure is the same; ex: register the SP with SPDB first. For details on idp-uat please see identity providers for more details.
Last modified May 21, 2024