A Quick Guide to Onboard Service Provider for SingleSignOn at Stanford

Introduction

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

Details

• 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

  • The SP’s metadata is an XML document that describes the SP’s EntityID, SAML signing/encryption certificates, and endpoints where the Identity Provider (IdP) will redirect after successful authentication.

  • If your SP is an InCommon or eduGAIN SP, the metadata exchange will occur automatically, and you can skip this step.

  • Modern SAML SPs can generate metadata automatically.

    • Shibboleth SP’s metadata might be available at https://www.example.com/Shibboleth.sso/Metadata
    • Simplesamlphp default SP’s metadata might be available via https://www.example.com/simplesaml/module.php/saml/sp/metadata.php/default-sp?outout=xml
    • ( Replace www.example.com with your own host/entity.)

  • Ask your vendor to provide the metadata; or have them use any online tool to create one.

• 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: group-name@lists.stanford.edu )

• 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 : https://idp.stanford.edu/
    • Metadata : https://login.stanford.edu/metadata.xml
    • SAML cert: https://login.stanford.edu/idp.crt

• For InCommon SP

  • Stanford IdP’s entityID: urn:mace:incommon:stanford.edu
  • 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, https://login.stanford.edu/idp/profile/SAML2/Redirect/SSO
    • For HTTP-POST, https://login.stanford.edu/idp/profile/SAML2/POST/SSO
  • Single Logout, https://login.stanford.edu/idp/profile/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

• See Attribute Release Policy
• Once you have registered your SP, you can also do your own workgroup/entitlement release from SP’s landing page on SPDB.
• To verify the attribute release, you would go to the SP landing page and click on “show your attributes”.

FAQ

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.