Third-Party Service Support

Identity Management services are development in conjunction with Duke's IT and Information Security offices.  Please consult security.duke.edu for guidance on where and how to host, deploy, and secure your application.

The following steps will allow a Duke department to delegate IT access to a contracted third party:

• Sponsored Guest Account(s) - Duke employees may sponsor third-party consultants for NetID access via the Sponsored Accounts page. 
   
• Group Manager Support Group - establish a Group Manager Support Group for your service or IT team.  Ensure key Duke contacts are both owners and members of the group, and sponsored guests are added only as members. 
  
  Members of your Support Group will now be able to complete steps in the following sections on the Duke department's behalf.

Step-by-step documentation for integrating your new service with Duke single-sign on is available at authentication.oit.duke.edu.

Sponsored guests who have been added to a Group Manager Support Group will be able to complete these steps on behalf of the Duke department.

If additional support is needed, please open an integration request at https://authentication.oit.duke.edu/manager/register

All authentication instances are encouraged to implement some form of authorization (eligibility or access controls) rather than simply using NetID authentication as authorization. Common uses are to limit authorization based off affiliations, group membership, or other specific attributes. For more information, please see Options for Retrieving Person Data, Grouper and Group Manager, and Authentication Manager authorization documentation.

There are two ways to allow users to authenticate to SaaS products with Duke login credentials:

• Multilateral federation through InCommon:  Duke supports standards-based SSO for service providers registered with the InCommon federation or another eduGAIN member federation. 
  
  Duke will automatically integrate with Federation-registered service providers that request no user attributes (authentication-only) or who have been approved for the REFEDS Research&Scholarship (R&S) entity designation.  For other configurations, request support via the Duke Authentication page.
   
• Bilateral federation via metadata exchange: For service providers who cannot support federated authentication through InCommon, the Duke department responsible for the SaaS product may register the application directly with Duke's Shibboleth (SAML2) identity provider.  Instructions for doing this (or sponsoring a third party to do it on the Duke department's behalf) can be found on the Duke Authentication page.

There are two approaches to ensuring that Duke users have an account with a SaaS provider partner:

• Just in time (preferred): with this method, accounts are created for users at the time they first attempt to use the service.  Duke only sends user information to the provider at the time of login, and the provider uses information from the authentication transaction to determine eligibility and match or create a user account.
  
  With just in time provisioning, all user information needed for account creation is transmitted through the SSO configuration, and no additional integration work is required.
   
• Just in case: with this method, user accounts are created ahead of time based on a manual or automated process.  If a SaaS provider cannot support just in time user creation and needs (for example) an automated file containing user account information, additional work will be required to retrieve account information via other means.

To support SaaS providers servicing higher education, Duke Identity Management adheres to the eduPerson schema for user data.  For more, please see Options for Retrieving Person Data.