SPDB FAQs

SPDB (Service Provider Database) Frequently Asked Questions

Q1. Why can't I make updates to SPDB anymore? 

A. Per data owners' approval, the default attribute policy covers users who have "stanford:faculty" , "stanford:student" or "stanford:staff" affiliations. For all other affiliations, explicit data owners approval is required. Please ask your manager who has "stanford:faculty" or "stanford:staff" affiliation to submit a request via ServiceNow on your behalf. The submitter needs to provide a good detailed justification as why the data custodians should trust the individual to safeguard Stanford user data. The final decision to approve these request lies with the data owners and is subject to their discretion.

Q2. What do I put in for "Contact Email" and why is it important?

A. Each registered Service Provider must be associated with one or more Technical Contacts. A Technical Contact is someone at your organization who

• can verify that the Service Provider is working and authenticating properly,
• can act on communications about Stanford IdP updates, outages, and issues,
• is responsible for making any necessary changes to the registered Service Provider metadata (e.g., updating the certificates).

Thus, it is very important that you provide a group email address for the Contact Email field and that this group email forward to people at your organization who can act as Technical Contacts. This address should be a Stanford address, not an external address.

Due to the large number of Service Providers registered with our IdP, and the fact that the Stanford SAML IdP Team cannot login to most sites, the IdP Team cannot do thorough testing of every Service Provider. When there are changes to IdP service it is your Technical Contacts who need to test your application. Hence, it is crucial that your contact email address deliver these important service notifications to those in your organization that can respond to them.

Important: The address you enter in the Contact Email team must be configured to allow the receipt of emails from saml-announce@lists.stanford.edu.

Q3. How can I test that my SP metadata is working properly?

A. Rather than starting at the SP's login URL, you can do an "IdP-initiated" authentication by pointing your browser at this URL:
https://login.stanford.edu/idp/profile/SAML2/Unsolicited/SSO?providerId=<entityID>

where you replace <entityID> with your SP's entityID. If your SP is pointing at our UAT Identity Provider, use this URL:
https://login-uat.stanford.edu/idp/profile/SAML2/Unsolicited/SSO?providerId=<entityID>

If you see your usual WebLogin screen and your authentication is accepted, then you know that Stanford's IdP has your SP metadata installed properly. Note: If your SP requires signed Authentication Requests (this is not common), then you cannot use "IdP-initiated" authentication. This will happen if your SP's Authentication Requests contain the string AuthnRequestSigned=true.

Q4. How is the validUntil attribute used?

A. The validUntil attribute is a date-time stamp in the ISO 8601 format (e.g., 2028-01-21T18:12:29.287Z). This attribute is optional and when present appears in the EntityDescriptor element of your SP metadata. The attribute acts as an "expiration date": if the attribute is present and is in the past, your SP metadata will not be consumed by Stanford's IdP effectively disabling authentication for your application. Our systems will send out e-mail notifications when your validUntil date is getting close to expiring. We encourage you to use this attribute for a couple of reasons: (1) it supports lifecycle management for SP configurations, and (2) helps to ensure that the contact e-mail address is still current. We recommend you set the validUntil date for between one and two years in the future.

Q6. How do I add an alias?

A. An alias is used to protect other URL's with the same SAML configuration. For example, you may have more than one application running on the same server under different URLs. To protect a new URL you simply add a new ACS endpoint to your existing metadata. To do this, look for the AssertionConsumerService element with the largest index attribute. Add a new AssertionConsumerService element replacing the Location URL with your new URL and with an index attribute one larger than your previous largest.

For example, assume that you want to protect this new URL: https://app-dev1.stanford.edu/Shibboleth.sso/SAML2/POST

Here is the before-and-after:

<!-- BEFORE -->
<md:AssertionConsumerService
  Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
  Location="https://shib-dev1.stanford.edu/Shibboleth.sso/SAML2/POST" index="1"/>
<md:AssertionConsumerService
  Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"
  Location="https://shib-dev1.stanford.edu/Shibboleth.sso/SAML2/POST-SimpleSign" index="2"/>

<!-- AFTER -->
<md:AssertionConsumerService
  Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
  Location="https://shib-dev1.stanford.edu/Shibboleth.sso/SAML2/POST" index="1"/>
<md:AssertionConsumerService
  Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"
  Location="https://shib-dev1.stanford.edu/Shibboleth.sso/SAML2/POST-SimpleSign" index="2"/>
<md:AssertionConsumerService
  Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
  Location="https://app-dev1.stanford.edu/Shibboleth.sso/SAML2/POST" index="3"/>

Q7. What do I put in the Owner and Owning Workgroup(s) field?

A. We restrict changes to an SP metadata configuration to the user who originally submitted the configuration and to any users listed in Stanford Workgroups entered in the Owner and Owning Workgroup field. Thus, it is very important that you put in at least one Stanford Workgroup in this field.

Q8. What do I put in the LoginURL field?

A. Put a link to the page that users should go to when logging into your SP's application. While optional, this information is very helpful when troubleshooting and testing your SP. Without this information, the SAML IdP administrators will not be able to effectively test your SP's configuration.

Q9. What happens when my certificate expires?

A. The short answer: nothing. Here is a longer answer. Certificates are embedded in an SP's metadata to allow the IdP to encrypt the assertions it sends back to the SP. The Shibboleth IdP ignores these certificates' expiration date and any possible revocation status. However, it is possible that your SP software may care about expired or revoked certificates. Our recommendation is to set an expiration date at least five years in the future and then create a new certificate once that certificate expires.

Q10. How do I renew a certificate in my metadata?

A. Create a new self-signed certificate (instructions here) and replace the expired certificate in your metadata with this new certificate, and save the new metadata.

Q11. Why the warning if my metadata does not use a self-signed certificate?

A. We recommend that certificates used in SP metadata last a minimum of five years. Certificates issued by a third-party Certificate Authority such as InCommon will last a maximum of three years. Furthermore, there is no need for the certificate to be signed by a widely-trusted third party as the only parties that use the certificate are your SP and Stanford's Identity Provider.

Q12. Which attributes are released to my SP?

A. By default, we release several attributes to all SPs; see the Attribute Release Policy page for more information.

Q13. How do I get other attributes released?

A. If the default attributes released are not sufficient for your application please submit a request at the Directory Access Request web form. Note that these requests require the permission of the Data Owners so can take several days to fulfill.

Q14. How long does it take for my metadata to "go live?"

A. Between 10 and 20 minutes.

Q15. How do I ask IdPs to release certain workgroups to my Service Provider (SP)?

A. In the Service Provider Database (SPDB), under editing your SP, look for “Add Entitlement” (send these workgroups(s)). Click on the ‘+’ sign to add any public workgroup. Only non-private workgroups can be released directly from SPDB. There is a maximum of 20 workgroups per entity. If you need more, please submit a Help request via SP's page at SPDB.

​

Q16. What is the difference between “Add Entitlement/Send these workgroup(s)” and “Owning Workgroups"?

A. “Add Entitlement/Send these workgroup(s)” is to communicate with Stanford IdPs regarding which workgroup information to release to the SP.

"Owning workgroups" is an access control mechanism for SPDB; members of the “Owning workgroups” can update relevant information about the entity, ex: metadata, contact information, and updating “Add Entitlement”.

Q17. How to configure NameID Format?

A. NameID is the unique identifier assigned by the Identity Provider (IdP) for a user logging in. By default, Stanford IdPs release a "transient" NameID to protect user privacy. However, third-party vendors often request specific NameID formats and values.

You can set a specific NameID format using SPDB. On your Service Provider's (SP) landing page in SPDB, check the "Override NameID format" option. Then, select the supported format and its source attribute. Noted, the privileged attributes (e.g., suUnivID) require data owner approval before they can be set as the source in the NameID.