Integrating a Third Party Application with Stanford SSO

This article describes a very generalized outline of how to integrate a third party application with Stanford Identity using SAML. Since all applications are different, there cannot be a single recipe covering all possibilities. Some of the integration decisions depend on the authentication architecture of an application, specifics of the Stanford environment and the user base of the application.

This article is written for a wide audience and begins with the very basics, avoids most of the special terminology, but gradually gets more technical. If at any point you feel like you need assistance with setting up an integration, feel free to stop reading and submit a HelpSU ticket.

Single Sign-On

Single Sign-On (SSO) is an authentication scheme, which allows a user to login to multiple independent applications using the same set of credentials. At Stanford everyone is familiar with a Web Login page, where one enters his SUNet ID, password and requests a Duo prompt. The same login page shows up no matter which application one is logging into. If you want to use Stanford Web Login for authentication with a third party application or service, keep reading. 

Getting necessary information

The hardest part of the integration with Stanford SSO is often collecting the necessary information and understanding what it is about. Typically application vendors would provide documentation on what their application expects in terms of configuration and what data should be provided by Stanford for successful integration. The next few sections introduce a minimal terminology necessary to understand the vendor’s specifications. Then we will recap everything in a checklist which you can use when setting up an integration.

SAML, IdP and SP

SAML (Security Assertion Markup Language)  is an open standard for exchanging authentication data between parties. The parties in the authentication process are called:

  • Identity Provider, frequently abbreviated as IdP. That’s the party which has all the information about the users, like their unique identifier, real names, emails, affiliation with an organization, etc. 
  • Service Provider, aka Relying Party, frequently referred to as SP. This is an application, that uses Single Sign-On for user logins. When user logs into the application, SP asks IdP to authenticate the user using his user name, password and possibly second factor. If valid credentials are provided, IdP returns a validated user name back to SP as well as any other information which SP requests.

Login to an application integrated with SSO typically happens in one of the two ways:

  • Application offers a button named like “Login with SSO”, “Login with Stanford”, “Corporate Login” or something like that. Pressing this button forwards the user to Stanford web login page. For this functionality to work, an application must provide a separate login URL just for Stanford users.
  • User enters a Stanford email in the login box and an application figures out that it has an existing integration with Stanford SSO and forwards the user to Stanford web login page instead of asking for a password.

Either way generates a request to IdP to authenticate a user, i.e. Authentication Request. In return IdP sends an SP an assertion stating that a user has successfully logged in (or not) and any additional information which SP may require.

Additional information within an assertion originates from Stanford LDAP (Lightweight Directory Access Protocol), which has a lot of information about users. Each piece of information about a user is called an attribute. Think of attributes like email, phone number, first and last names, affiliation with Stanford, etc. Identifying particular attributes to be sent to an SP is an important part of creating an integration.

Authentication and Authorization

While a user logs into an application, two kinds of processes are happening in the background and different parties are responsible for them. 

Authentication is a process of verification of the user identity using his personal credentials like a password and second factor (Duo) authentication. That is basically confirming that the user is who he says he is.

Authorization is a process of granting user access to an application and sometimes only a particular level of access to its features. For instance, some set of users may need administrative rights in an application, the other set of users might have standard rights and the rest should not be able to login to an application at all.

It is an important to remember that entire authentication part is performed by IdP and all authorization is happening on SP side, i.e. within the application. It makes a lot of practical sense since it is an application which knows all about its own types of user accounts, features and access privileges. IdP is not aware of them and only validates user identity and optionally provides the additional information to SP, which would help it make decisions during the authorization. 

One of the frequently asked questions is whether IdP could fail authentication for everyone, but a particular set of users. The act of allowing or denying authentication is an authorization, which IdP does not do, hence the answer to the question is negative.

How SP tells the users apart

The most important piece of data in the authentication process is the user name. That’s how application would tell one user from another. Needless to say that user names must be unique, persistent and every user must have one. What can serve as a user name and what cannot?

The most obvious choice for a user name at Stanford is SUNet ID. It satisfies all the requirements: everyone has it, no users have identical SUNet IDs and they never change, even if a person leaves the University and then gets re-hired. 

Some SPs want something email-like as an identifier. In this case a good candidate is eppn (Education Person Principal Name), which has a format sunet_id@stanford.edu. Also helps with the user name collisions if different organization share the same user namespace within an application. I’d say that this choice is even better then bare SUNet ID.

Email is an example of what should not be used as a user identifier. At Stanford email attribute in LDAP is filled out with the information supplied by the user himself. It can be virtually any email address, be it yahoo mail, gmail, stanford email, departmental email or nothing at all. Email can be updated by a user at any time. Thus email does not satisfy any of the requirements for a user identifier: uniqueness is not guaranteed, can be changed any time and not everyone has it.

User identifier is returned by IdP to SP in two different ways depending on SP’s requirements:

  • As a particular attribute. A vendor may specify a name of an attribute, which their application uses to identify a user. A name of an attribute can be anything, like username, uid, user_name, user, etc.
  • As NameID value. NameID is not an attribute. It is sort of a subject of SAML conversation between IdP and SP: “Let’s talk about a user jdoe!”. NameID can be assigned a value of any attribute. IdP can be configured to pass SUNet ID or eppn in the NameID. Thus what passes as a user identifier can be configured as flexibly as in case of a regular attribute.

Different applications expect one or the other of these ways, not both at once. It is important to find out what is used by SP as a user identifier.

I want to elaborate on the use of email as a user identifier in applications since it is unfortunately so common to assume that it is a good one. Very often a vendor indicates that they use email as a user identifier. As I mentioned above, at Stanford email is not a good way to identify users and it should not be used this way. If you hear that from a vendor, it pays to ask if they use email only to identify users or they use it to send them actual emails as well? If it just a user identifier, then any email-like identifier would work, eppn, for instance. If it is also used to send actual emails, then there is no perfect way to integrate this application with Stanford SSO. Some sort of a common sense compromise must be made:

  • If an application’s audience is entire Stanford, it is probably the best to pick a different application. If it is not possible, the users must be made aware that they won’t be able to login if they don’t have email set in StanfordYou. They should also be told that if they change their email, they may not be able to login to the application under the same account or may not be able to login to the application at all.
  • If an application has a limited audience, it may be easier to enforce the uniform setting for emails.
  • With a very limited audience of university staff or faculty it may not be a problem at all since these groups of users typically do have Stanford mailboxes and they are set as default automatically.

Additional information SP may need

SP may require some additional information, besides user name, to properly authorize one or just to fill out his profile fields within an application. This information can be provided by Stanford IdP as particular user attributes.

It is very common for an application to request things like user’s real name and email. This way an application would nicely display a user’s name and not just an identifier and will be able to send user emails.

If the target audience of an application is not an entire Stanford community, application must know how to distinguish it from everyone else. Because of that it is very important to know who are the users of the application. This distinguishing information must be sent by IdP to SP as a set of attributes and SP then would be able to tell if a user is supposed to be able to login into it or not. For instance, the audience of the application can be defined as:

  • Only Stanford staff should be able to use the application. IdP can send an affiliation attribute, which can have values like staff, student or affiliate. Looking at the value of this attribute for a particular user an application can allow access to staff and deny access to everyone else.
  • Everyone but Stanford affiliates should be able to use the application. Can be done using the same affiliationattribute as above.
  • Only the members of a particular Organization are using this application. IdP can send an attribute suPrimaryOrganizationID containing the organization code within Stanford. An application may grant access based on whether the user has the expected organization code and deny access to everyone else.
  • Only a set of users I want to define should be able to use the application. This is actually the most common case. Workgroup Manager application is widely used for this purpose. Within this application one can define any number of workgroups and use them to control access to the applications integrated with SSO. Often there is no even a need to create any groups, the existing ones are sufficient. IdP can pass a list of workgroups which user is a member of to an application as an attribute eduPersonEntitlement and an application can grant or deny access looking if a user is a member of a particular workgroup. Application can also grant different privileges within itself based on the membership of different workgroups.

In the context of an application set of users having particular level of access is called a role. If an application uses roles, it is said to provide a role-based access, often abbreviated as RBAC, and the vast majority of applications do. Applications supporting RBAC must provide a way to assign roles to groups of users. In some applications these groups can only be created within the application, but in others the groups can be provided by an external source. IdP can be a source of such information. Group membership of a user can be sent to an application in eduPersonEntitlement attribute.

When you plan an SSO integration it is imperative to find out which information application requires about the users and identify which attributes in Stanford LDAP contain this information. For obvious privacy and security reasons we should not send to third party applications any more information than they absolutely need for a successful integration. 

Attribute release and creation

For the attributes to be accessible to an SP, they must be released, i.e. made available. Attribute release policy at Stanford is detailed in a UIT documentation page SAML Attribute Release Policy. A minimal set of attributes is automatically released if an application is a member of InCommon Federation, otherwise you have to submit a request for release either with HelpSU ticket for basic set of attributes or a special form, if any other attributes are needed.

Helpfully release policy page also contains a list of most commonly used attributes and their names as they are sent to SP by default.

It may happen that a particular application you are integrating expects attributes under the different names. Let’s say it expects a user identifier in an attribute username. You decided that the users are to be identified by their SUNet IDs, which are sent by the IdP in an attribute named uid. This name is not what SP would be looking for and SSO would not work. To make it work a username attribute must be created on IdP and released to a particular SP. It is quite a bit of a configuration work, which has to be performed by an IdP administrator. If you need that, please submit a HelpSU ticket and beware that you would also need to provide a PTA since you will be charged for IdP administrator’s work on a custom integration.

Thus when planning SSO integration, pay a special attention to which attributes are required by SP and what are the expected names of these attributes. A list of some attributes is given at the very end of this article.

Security

Communications between IdP and SP happen over HTTPS (SSL) connection, i.e. go through an encrypted channel. Nevertheless, SAML protocol provides additional security measures which create a safety net preventing impersonation of users and entire SPs by potential attackers.

The first such measure is signing. Authentication requests sent by SP and assertions sent back by IdP can be cryptographically signed ensuring that an attacker cannot tamper with the content of the communications. If any signed SAML message does not pass a signature check, either IdP or SP would recognize that it is an attack and fail an authentication. 

Second measure is encryption. Assertions coming from IdP can be entirely encrypted so that only a particular SP would be able to decrypt them. This prevents any other application running in a browser, like a malicious browser plugin, from snooping on the authentication process and protects the integrity of the authentication if any flaw exists in the authentication software itself. 

Assertion encryption is a requirement for applications integrating with Stanford SSO. It is prudent to pick applications which support it. When talking to vendors, be sure to find out if their application supports SAML assertion encryption. If you are stuck with an application, which does not and still need to have an integration, you have to personally take responsibility for potential consequences. You can file SAML Encryption Exception request following the process described in a link. If your exception is granted, IdP administrator would have to configure the IdP to work with your SP without encryption, while it would not do that by default.

Metadata

For SSO to work, IdP and SP must have some information about each other. This information is encapsulated in so-called metadata. SP’s, i.e. application’s metadata must be installed on IdP and vice versa. SAML is an XML-based protocol and the metadata is stored in XML files.

InCommon federated SPs

InCommon federation allows sharing metadata between multiple organizations, primarily in the education and research. If an SP is a member of the federation, it can be configured to accept logins from the users belonging to different institutions. 

To achieve that, the federation has a common store of the SP metadata. If the application you are integrating is a member of InCommon federation, you do not have to upload its metadata to Stanford IdP, as it already has access to it as a member of the federation. All you need to know is the entityID of the application SP.

Configuring an application

All applications are different and you should ask an application vendor for instructions on how to configure the one you are integrating. In the simplest scenario an application would give you an option to install Stanford IdP metadata, so that it would know how to talk to it. Application may give you an option to either upload an XML file with the IdP metadata or specify a URL where this metadata lives.

The latest Stanford IdP metadata can always be downloaded from https://idp.stanford.edu/metadata.xml

Stanford IdP metadata is re-keyed with new encryption keys yearly, so if your application gives you a choice of uploading a metadata file or specifying a URL, always opt for the latter. Otherwise you’ll have to remember to re-upload the metadata every year.

There may be additional configurations for authorization within the application based on the attributes sent by Stanford IdP. You may be asked to map particular attributes SP receives to internal variables used by the application. For instance, an application wants to have a user identifier, real first and last names and email. You would be offered and few input fields, where you can do the mapping similar to this:

ApplicationIdP Attribute
Login Nameuid
First NamegivenName
Last Namesn
Emailmail

It may happen that an application does not provide a way to upload or specify a URL for IdP metadata offering a bunch of fields to fill out instead. What is to be done in such case is discussed further below. Barring this eventuality your application should be configured to work with Stanford’s single sign-on and you can proceed with configuring Stanford IdP.

If an application supports role-based access (RBAC), it can also provide a way to map external groups to application roles, something like this:

RoleGroup
Administratorsstem:application-admins
Financestem:application-finance
Managementstem:application-management
Lab Astem:application-lab-a

Group names on the right can be created in Stanford Workgroup Manager and sent to the application in eduPersonEntitlement attribute for each authenticated user. For instance, user Jane Doe works in the Lab A, and should have a corresponding role with an application. Application administrator would add user Jane Doe to stem:application-lab-a workgroup in the Workgroup Manager. Once this is done, IdP would send the stem:application-lab-a group name in eduPersonEntitlement attribute to the application every time Jane logs into it. When application receives authentication information (SAML assertion) from IdP and sees that Jane is a member of stem:application-lab-a group, it checks with the mapping and assigns Jane a corresponding role Lab A with an application granting her just the right level and scope of access.

If an application expects a different name then eduPersonEntitlement for an attribute containing the list of RBAC groups, it can be created by an IdP administrator per request.

Configuring the IdP

Unless SP is a member of the InCommon federation, IdP must have SP metadata installed for SAML to work. SP’s metadata can be provided by a vendor as an XML file from the outset or you may be asked to login to the application with a local (non-SSO) application account and download it from there. The latter typically happens when enabling the SSO logins to an application is a manual process and all the configuration must be done before it is switched on.

Once you have an XML metadata file from an application, it can be installed on IdP using SPDB application. This web application is available to any Stanford staff and faculty. Students must involve someone who has access in setting up an integration they desire or submit a HelpSU ticket to get TCG’s help.

When logged into SPDB, click Add new SP configuration button. In the large Metadata text area paste SP’s metadata from an XML file you’ve got from the application. Provide a contact email, preferably a mailing list, in the Contact field, where IdP administrators can send notifications and inquiries. Enter a login URL for your application in the Login URL field. Briefly describe what the application does in the Description field. Add one or more Stanford Workgroups to the Owning Workgroup list. Members of these workgroups would be able to edit the configuration of the application on the IdP side.

If an application supports role-based access (RBAC) and together with external groups for it, use the field Send these workgroups to provide a list of Stanford Workgroups corresponding to internal application roles.

Finally click Submit Metadata button and wait for about 15 min until it gets deployed to the IdP. 

Note that Owning Workgroup in the SPDB record is mandatory and it cannot be a workgroup from a personal stem. Every Stanford user with full SUNet ID gets a personal workgroup stem ~sunet_id. Thus the workgroups you create in this stem would look like ~sunet_id:workgroup_name. These groups are meant to be only for personal use and cannot be owning workgroups in SPDB. For more information about workgroups see the UIT documentation.

Note that all the information about SP necessary for the integration is encapsulated in the metadata. The rest of the fields in SPDB are meant only for informational, management or administrative purposes.

Write down the value of EntityId field at the top of the form. This is a unique identifier of your application. If you want to come back and edit the integration in SPDB, you may need it to find your SP record with a search function. 

After 15 min you can go ahead and test if SSO is working. If it does, congratulations, you are done!

It may happen that a vendor would not provide a ready to use XML metadata and give a bunch of instructions of how they expect IdP to be configured. You would also discover that SPDB has none of these fields. What is to be done in this situation is discussed further below.

If an SP is a member of InCommon federation, switch a radio button This SP is already part of the InCommon Federationat the top of the SPDB record page to Yes. When you do, the Metadata box will change to EntityID field. Enter the application’s SP entityID there. Metadata is already available to Stanford IdP as a member of InCommon federation. Fill out the rest of the fields the same way as for non-member SPs.

If you want to see application’s SP InCommon metadata, you can download it using MDQ query using a URL https://mdq.incommon.org/entities/<entityID>, where the element after the last slash is the full entityID of the SP. Note that entityID has to be URL-encoded. 

Sometimes a vendor would provide the metadata failing to mention that their application is a member of InCommon federation. If you try to enter this metadata in SPDB, you would get an error: “The entityID supplied (entityID) is an InCommon entityID; this SP’s metadata is already known to our IdPs.” To fix the error, note the entityID in the parenthesis, switch the record to be a member of InCommon and enter the entityID from the error message into the EntityID field in SPDB.

IdP-initiated authentication

Some applications require IdP-initiated aka “unsolicited” authentication. In such cases application does not offer a login page to the users at all. It expects a user to authenticate to IdP and the result forwarded to the application.

If that is the kind of application you are dealing with, give the users a special login URL:

https://login.stanford.edu/idp/profile/SAML2/Unsolicited/SSO?providerId=<entity ID of the SP>

Going to this URL will trigger authentication on IdP and then users would be forwarded to an application according to a URL provided in application’s (SP’s) metadata. The configuration steps for IdP-initiated authentication are the same as for SP-initiated.

Checklist

Here is a sample checklist you may want to use when planning an SSO integration and when initially discussing it with a vendor.

Considerations

  • Who is the audience of the application? 
  • How many users?
  • Which attribute can identify if a user is authorized to use the application or not? 
  • What would be a good user identifier? SUNet ID? eppn?
  • Obtain documentation on SAML integrations from the vendor, the more detailed the better.

Questions to the vendor

  • Is SP a member of the InCommon federation?
  • What is used by an application as a unique user identifier? How should it look like (string, email, etc.)?
  • How the user identifier is passed to an application, as an attribute or in the NameID?
  • If a user identifier is passed as an attribute, what is the attribute name?
  • If an email is used as a user identifier, is application actually sending email messages to the users using this address? Can email address be configured separately from a user identifier?
  • Any other attributes which are mandatory or optional? What are the expected names of these attributes?
  • How does the application authorize users? Who gets the rights to login? Is this defined within an application or externally?
  • Does the application support role-based access based on external groups, which can be sent by IdP? 
  • Does application support signed and/or encrypted assertions?
  • Would the vendor provide an XML metadata for the application?
  • Any more information is required about Stanford IdP than what is given in the IdP metadata?
  • How to install Stanford IdP metadata in the application? Would a vendor do it himself or is it a self-service?
  • Is authentication SP-initiated or IdP-initiated?

Integration steps

  1. Obtain complete information from the application vendor.
  2. Obtain XML metadata from the vendor or all necessary information to generate it (described below).
  3. Upload XML metadata to Stanford IdP using SPDB.
  4. Request necessary attribute releases submitting a HelpSU ticket. If NameID has to be configured in a certain way, also add it to the ticket.
  5. Configure the application either specifying the metadata URL of the Stanford IdP or filling out a form with the necessary information within an application or just giving it to the vendor if an application configuration is not self-service. 
  6. Test SSO logins. May require a vendor to flip the switch enabling it beforehand. 

These instructions do not apply!

If you got as far as this section then either you found out that the instructions given above do not apply to your case or things just don’t work. I guess it is time to get a little bit more technical, but not too much.

As I mentioned above, it may happen that the vendor would not provide you metadata for the application or would not give you a way to install Stanford metadata into the application or both. In the first case we would have to learn to generate XML metadata files to install them on Stanford IdP, while in the second we’ll have to take a look at Stanford IdP metadata and find out how to fill out the configuration options in the application. Sometimes a vendor would configure the application for SSO themselves, but would ask you for the information about IdP. This is essentially the same case.

The first thing we need to do is to familiarize ourselves with metadata files and what the things in them mean.

Metadata format

There are a following most important bits of information in the metadata, which I should mention.

Entity ID

Each party (aka entity) of a SAML conversation must have a unique identifier to make sure the parties do not misdirect their communications. Entity ID can be any string of characters, but there is a convention to conform to URL-like format. Just beware that if Entity ID looks nothing like a URL, it is still a valid Entity ID.

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="_4f3de0f4eb0ef9b51534fb5b0f729d948b87f22d" entityID="https://application.domain.tld/saml"> ...

SSO Descriptor

Sometimes metadata contains information about what entity expect in terms of security. These expectations are found in SSO Descriptor element:

<SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true"protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

In the example of an SP metadata above you can see that this SP is committed to send only signed authentication requests and expects signed assertions in return. Note that if an entity commits to doing something in its metadata, the other entity takes it up on it. If for some reason in practice this SP would fail to sign an authentication request, this would trigger an error on an IdP and authentication would fail. If SP does not make a commitment to sign in its metadata, IdP would accept both signed and unsigned requests. Mismatch between commitments in the metadata and the actual behavior of the application is a common cause of authentication failures. To fix those either metadata or SP’s behavior have to be changed to match.

SSL Certificates

Metadata can contain one or more SSL certificates. They are needed to encrypt the data going towards the other party. For instance, SP’s metadata installed on IdP contains SP’s certificate, which is used to encrypt the assertions sent to SP. SP would have a private key capable of decrypting the encrypted assertions.

A certificate in a metadata can be associated with intent, i.e. the way it should be used. For instance, metadata may have two certificates, one intended for signing and a different one for encryption. If a certificate does not have an intent, then it can be used for both.

If you look at the SP’s metadata and see the certificates missing, then it is a sign an application does not support encryption. If there is a certificate, you can check if there is an encryption intent associated with it. If a certificate has a specific intent and it is not encryption, then an application does not support encryption either.

...
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>MIICRTCNAaWgGwIBAgIJAPLcIuiZMxVmMA0GC SqGSIb3DQEBCwUAMB4xHDAaBgNUBAMME3VzLWVhc39tMV80QVNOMFBadH cwHhcNMjAwMjExMDQyMzAzWhcNMzAwMjExMDQyMzAzWjAeMRwwGgYDVQQ
...

NameID Format

This is format, which an entity wants NameID to be in.

<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>

Assertion consumers/Single sign-on service

Specifies where assertions are to be sent and how. Each XML element contains at least location and binding. Location is a URL where the browser is redirected during authentication session. Binding specifies which underlying messaging protocol is used for that. Most typical are HTTP-POST and HTTP-Redirect.

Filling out the forms

Armed with the knowledge about the metadata we can take a look at IdP’s metadata, identify the important parts and either provide this information to an application vendor or configure it ourselves if it is a self-service process. Open or download the metadata from the link given above.

  • Entity ID, sometimes called “Audience ID”. Stanford IdP’s entity ID is https://idp.stanford.edu/, exactly as it is written, including the trailing slash.
  • Stanford IdP does not make any commitments to SPs regarding signing or encryption, which makes sense since it has to support all sorts of SPs. Nevertheless, if an SP accepts signed or encrypted assertions, IdP would always sign and encrypt them. IdP would know if they are supported from the SP’s metadata.
  • Certificates. IdP uses a single certificate for both signing and encryption of the assertions. It is the last one in the metadata. Being not formatted conveniently in the metadata, you can download it as a separate file. If an application supports signing and/or encryption may require you to upload this certificate in the process of its configuration.
  • Authentication requests. Metadata has a URL where to send authentication requests. Some applications require you to enter it: 
  • https://login.stanford.edu/idp/profile/Shibboleth/SSO
  • Single sign-on service URLs. Application would most surely require one in the configuration. Depending on what kind of binding the application requires a URL would be different:
  • HTTP-POST: https://login.stanford.edu/idp/profile/SAML2/POST/SSO
  • HTTP-Redirect: https://login.stanford.edu/idp/profile/SAML2/Redirect/SSO
  • Find out from a vendor which one their application uses.

That should cover most of the questions a vendor might ask about Stanford IdP and enough material to fill out the SSO configuration forms in most applications.

Generating the missing metadata

If a vendor provides no ready to use metadata, but only the parameters I mentioned in the Metadata Format section, we have to generate it. There is a handy online tool which would be a big help.

It is easy to guess how to fill this form out:

  • Entity ID. Take an entity ID/audience ID given by an application vendor and put it in this field.
  • Attribute Consumer Service aka ACS. Put the URL given by a vendor here.
  • Single Logout Service Endpoint (HTTP-REDIRECT). Leave blank.
  • NameId Format. Leave default unless specified by a vendor.
  • SP X.509 cert. Paste an SSL certificate provided by the vendor here.
  • AuthnRequestsSigned. If an SP signs authentication requests, then choose True, otherwise False.
  • WantsAssertionsSigned. If an SP supports signed assertions, then pick True and False otherwise.
  • Orgnizational Info. Leave entire section blank.
  • Techical Contact. Given Name. Put the name of your team/group/lab/school there.
  • Technical Contact. Put in an email contact for this integration, preferably a mailing list.
  • Support Contact. Leave entire section blank.

Press Build SP Metadata button, and your application’s metadata would be generated below. Copy and paste it into SPDB as described above.

Select LDAP attributes

The a list of some often used attributes with examples. The attributes in bold type are released to Stanford and InCommon SPs automatically and do not require permission for release from data owners. It is sufficient to submit a HelpSU ticket. The attributes which are not in bold do require permission from data owners to be released to any SP.

Core, InetOrgPerson

  • uid, userid (0.9.2342.19200300.100.1.1) — wmdoe
  • displayName (2.16.840.1.113730.3.1.241) — William Doe
  • givenName, gn (2.5.4.42) — william
  • mail (0.9.2342.19200300.100.1.3) — wmdoe@stanford.edu
  • ou, organizationUnitName (2.5.4.11) — Department of Geophysics – Geophysics
  • sn (2.5.4.4) — doe
  • title (2.5.4.12) — System Administrator
  • telephoneNumber (2.5.4.20) — (650) 799-9999
  • postalAddress — Mitchell 999, Stanford, California 94305-2215

eduPerson

  • eduPersonAffiliation (1.3.6.1.4.1.5923.1.1.1.1) — staff
  • eduPersonNickname (1.3.6.1.4.1.5923.1.1.1.2)
  • eduPersonOrgDN (1.3.6.1.4.1.5923.1.1.1.3)
  • eduPersonOrgUnitDN (1.3.6.1.4.1.5923.1.1.1.4)
  • eduPersonPrimaryAffiliation (1.3.6.1.4.1.5923.1.1.1.5)
  • eduPersonPrincipalName (1.3.6.1.4.1.5923.1.1.1.6)
  • eduPersonEntitlement (1.3.6.1.4.1.5923.1.1.1.7) — list of Stanford Workgroups
  • eduPersonPrimaryOrgUnitDN (1.3.6.1.4.1.5923.1.1.1.8)
  • eduPersonScopedAffiliation (1.3.6.1.4.1.5923.1.1.1.9) — staff@stanford.edu

suPerson

  • suRegID – hexadecimal unique ID of a user in LDAP
  • suRegisteredName — William Michael Doe
  • suRegisteredNameLF — Doe, William Michael
  • suDisplayNameFirst — William
  • suDisplayNameLast — Doe
  • suDisplayNameLF — Doe, William
  • suGivenName — william, bill
  • suSunetID — wmdoe, william.doe (SUNet ID and all aliases)
  • suDisplayAffiliation — Staff
  • suAffiliation — stanford:staff
  • suMailCode — 1234
  • suUnivID — DR123N456
  • suPrivilegeGroup — multiple entries, each is a Stanford Workgroup. Passed as an array in eduPersonEntitlement attribute of eduPerson object class
  • suSN — doe
  • suCN — william m doe, william doe, bill doe
  • suOU — Department of Geophysics – Geophysics
  • suGwAffiliation — University|Staff|Department of Geophysics – Geophysics|System Administrator
  • suPrimaryOrganizationName — Geophysics
  • suPrimaryOrganizationID — TACE