Shibboleth User Verification Customer Implementation Guide Version 3.5

Transcription

1 Shibboleth User Verification Customer Implementation Guide Version 3.5

2 TABLE OF CONTENTS Introduction... 1 Purpose and Target Audience... 1 Commonly Used Terms... 1 Overview of Shibboleth User Verification... 3 What is User Verification?... 3 What is Shibboleth?... 3 Shibboleth Federations... 4 How Shibboleth Works... 5 Customer Experience Diagram... 6 Shibboleth Implementation at a Glance... 6 Configuring your IdP... 7 Metadata and Kivuto Entity IDs... 7 Attributes... 7 Configuring Shibboleth on your ELMS WebStore Setting up Shibboleth as a WebStore Verification Type Configuring Shibboleth Verification Details Tab Settings Tab Diagnostics Tab Post-Implementation Procedures Testing your Integration Testing the Workflow Validation Troubleshooting Restoring Administrative Roles Shibboleth Implementation Scenarios Scenario 1: Organizational ELMS WebStore for a Single Federation Member Scenario 2: Departmental ELMS WebStore for a Single Federation Member Scenario 3: Integrated ELMS WebStore for a Single Federation Member Scenario 4: ELMS WebStore for ALL Members of a Federation Shibboleth User Verification: Customer Implementation Guide

3 Support Shibboleth User Verification: Customer Implementation Guide

4 Introduction This section covers the following areas: Purpose and Target Audience Commonly Used Terms PURPOSE AND TARGET AUDIENCE This document gives you detailed instructions for establishing a single sign-on mechanism between a Kivuto customer s existing Shibboleth IdP and a Kivuto ELMS WebStore. This document is aimed primarily at ELMS Administrators and technical staff who manage identity services for their organization. Read this document in conjunction with the online help available in the e5 Administration website. COMMONLY USED TERMS Term ELMS / e5 Definition/description Electronic License Management System Customer Shopper An organization that is using Shibboleth to authenticate shoppers to use an ELMS WebStore. In the ELMS Administration website, a customer is defined as an Organization. User that is being signed in to an ELMS WebStore. WebStore Organizational WebStore Departmental WebStore A Kivuto ELMS e-commerce website that provides products for sale on behalf of the customer. A WebStore associated with an organization-wide software-distribution agreement (e.g. DreamSpark Standard). All members of an entire organization are eligible to order software through WebStores of this type. A WebStore associated with a departmental software-distribution agreement (e.g. DreamSpark Premium). Only members of a specific department within an organization are eligible to order software through WebStores of this type. Shibboleth User Verification: Customer Implementation Guide

5 Term Integrated WebStore ELMS Administration Shibboleth IdP SP EntityID Definition/description An ELMS WebStore associated with multiple software-distribution agreements, both organization-wide and departmental. All members of an entire organization can sign on to WebStores of this type and will be eligible to order software offered through the organization-wide agreement(s). Members of eligible departments will have access to software offered through the departmental agreement(s). Secure administration module in ELMS that contains functions to manage a WebStore as well as set up user verification. This module is accessible by authorized users only. From The Shibboleth System is a standards based, open source software package for web single sign-on across or within organizational boundaries. It allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner. Identity Provider. The software used by an organization with users who want to access a restricted service. Service Provider. The software run by the provider managing the restricted service (for example, Kivuto). Unique name of an IdP or an SP within a Shibboleth deployment. Kivuto s EntityID value is: Metadata Configuration data used by IdPs and SPs to communicate with each other. Attributes External Organization Code WAYF Assertions made by an IdP about a person, such as an address or a unique identifier. Code supplied by an organization or its parent organization to identify it during communications with a Single Sign-On verification service like Shibboleth. For departmental WebStores, an attribute matching this code must be passed to limit access to members of the eligible department. Where Are You From discovery services Shibboleth User Verification: Customer Implementation Guide

6 Overview of Shibboleth User Verification This section covers the following areas: What is User Verification? What is Shibboleth? How Shibboleth Works o Customer Experience Diagram Shibboleth Implementation at a Glance WHAT IS USER VERIFICATION? User verification is the method by which a WebStore user s eligibility to order software is authenticated. Only authenticated users can order software in your WebStore. The ELMS Administrator must define how their users are authenticated. This is referred to as methods of verification. There are many verification methods that can be used to authenticate users, including domain, user import, Integrated User Verification (IUV) and Shibboleth (from a Federated Identity Program). WHAT IS SHIBBOLETH? Shibboleth is a single sign-on (SSO) method of verification that has achieved widespread adoption worldwide. Reasons for this range from its open-source origins to its model of privacy protection that gives individuals and organizations a great deal of control over what personal information is released to external parties. Shibboleth is often used by a federation or group of organizations. For example, InCommon is a federation of organizations in the United States. The Canadian Access Federation is a group offering Shibboleth services to Canadian educational institutions. For those requiring background information about Shibboleth, refer to the project s website at Step-by-step demos of the sign on process are available at Shibboleth User Verification: Customer Implementation Guide

7 SHIBBOLETH FEDERATIONS Customers using Shibboleth with ELMS must be members of a federation of which Kivuto is an SP. See Table 1 for a list of federations supported by Kivuto. Table 1: Federation List Federation SWITCH InCommon Canadian Access Federation (CAF) UK Federation WAYFDK SWAMID Haka Belnet Edugate DFN IDEM RENATER ACO GRNET GakuNin AAF Country Switzerland United States Canada United Kingdom Denmark Sweden Finland Belgium Ireland Germany Italy France Austria Greece Japan Australia Shibboleth User Verification: Customer Implementation Guide

8 HOW SHIBBOLETH WORKS The following are typical steps in a Shibboleth sign-on to an ELMS WebStore: Shopper arrives at ELMS WebStore: When the shopper clicks the link to sign in or performs an action that requires authentication (for example, adding an item to a shopping cart), the Shibboleth SP software integrated with the ELMS WebStore redirects the shopper to the customer s Shibboleth IdP sign-in page, or to a remote discovery service (WAYF) if necessary. Shopper chooses home organization: This step is not usually necessary, but is available for cases when more than one member of a federation accesses the same ELMS WebStore. The discovery service provides the shopper with a list of organizations from which the shopper chooses his or her home organization and subsequently redirects the shopper to the customer s site. Customer site authenticates shopper: The customer s site prompts the shopper for his or her credentials, and authenticates the user. This authentication is coordinated by the customer s Shibboleth IdP software. The IdP builds a minimal set of attributes for the shopper that are required by Kivuto. The site then redirects the shopper back to the ELMS WebStore. ELMS WebStore authenticates shopper: The attributes released by the customer s IdP are used to create a set of credentials on the ELMS WebStore (user account). This action completes the verification process and the original page requested by the shopper is displayed. Shibboleth User Verification: Customer Implementation Guide

9 CUSTOMER EXPERIENCE DIAGRAM ELMS Discovery (WAYF) Customer IdP Shopper clicks Sign In link Shopper chooses home organization (if required) Shopper enters username and password ELMS processes shopper attributes Shopper begins shopping! SHIBBOLETH IMPLEMENTATION AT A GLANCE + + TEST YOUR INTEGRATION Configure your IdP Release attributes to Kivuto Entity IDs Configure ELMS to communicate with your IdP Shibboleth User Verification: Customer Implementation Guide

10 Configuring your IdP This section covers the following areas: Metadata and Kivuto Entity IDs Attributes METADATA AND KIVUTO ENTITY IDS If your organization is an IdP in a federation that has accepted Kivuto as an SP, then both will be found in the metadata published by the federation. The Entity ID used by Kivuto is: ATTRIBUTES The minimum set of identity assertions required by Kivuto is the following: a unique identifier for a shopper o This allows the shopper to be identified across multiple logins. a list of group affiliations o This gives the shopper access to products that are restricted to members of specific user groups. For example, a product may only be available to faculty or staff members. Further identity assertions may be made (passed during integration) to further personalize the ELMS WebStore for your users. For a list of attributes, see Table 2: Attributes below. Note: Which attributes must be passed depends on the implementation scenario. See Shibboleth Implementation Scenarios to determine which attributes are required for your implementation. Shibboleth User Verification: Customer Implementation Guide

11 Table 2: Attributes Attribute edupersontargetedid urn:mace:dir:attribute-def:edupersontargetedid: urn:oid: Description Unique identifier for a user. If opaque, it may be desirable to use the Hide Username setting (see Table 3: Settings). persistent ID (SAML 2.0) urn:oasis:names:tc:saml:2.0:nameid-format:persistent uid urn:mace:dir:attribute-def:uid urn:oid: SwissEP_UniqueID urn:mace:switch.ch:attribute-def:swissedupersonuniqueid urn:oid: edupersonprincipalname urn:mace:dir:attribute-def:edupersonprincipalname urn:oid: Unique identifier for a user. Unique identifier for a user. Unique identifier for a user (SWITCHaai). Unique identifier for a user. Can be used in combination with other unique IDs in which case edupersonprincipalname will be a user s username, and the other ID will be captured as the member identifier on a user verification. edupersonscopedaffiliation urn:mace:dir:attribute-def:edupersonscopedaffiliation urn:oid: Grants eligibility to a user through user group membership. Attribute value maps to user group as follows: Important: This attribute and the default values available are intended to be passed by academic organizations. Corporate organizations may need to pass different parameters to indicate the eligibility of their users. Consult your account manager for details. student -> Students faculty -> Faculty staff -> Staff employee -> Faculty/Staff member -> Students/Faculty/Staff edupersonaffiliation urn:mace:dir:attribute-def:edupersonaffiliation urn:oid: edupersonprimaryaffiliation urn:mace:dir:attribute-def:edupersonprimaryaffiliation urn:oid: Grants eligibility to a user. Same mapping as scoped attribute. Grants eligibility to a user. Same mapping as scoped attribute. Shibboleth User Verification: Customer Implementation Guide

12 Attribute ismemberof urn:mace:dir:attribute-def:ismemberof urn:oid: Description Used for custom user group or organization mapping. Multivalue, use comma or semi-colon delimiters. Values may be qualified, for example, urn:mace:example.edu:groups:groupcode. The last portion of the qualified values are used when matching against system codes. For user groups, values will be matched against User Group Code fields found in the e5 Administration website under Users» User Groups section. When matched, the user will be granted membership in the corresponding group. For organizations, values will be matched against the External Organization Code (which can be found on the Organization page of the ELMS Administration website once it has been provided to Kivuto) for the WebStore organization or any of its affiliated organizations. When a match is made, a user verification will be created for the user linking them to the organization with any corresponding user groups. This can be used, for example, to specify that a user is a member of a specific department. Note: Organizations with departmental WebStores must pass an attribute used for organization mapping that matches their External Organization Code. edupersonentitlement urn:mace:dir:attribute-def:edupersonentitlement SAML2: urn:oid: Used for custom user group or organization mapping. See ismemberof for details on how values are mapped. Values are URIs, either URNs or URLs. Any valid URNs may be used (e.g. urn:mace:school.edu:exampleresource)both the whole URN value (urn:mace:school.edu:exampleresource) and the namespace-specific string portion (exampleresource) will be matched against group and organization mappings. Only URLs of the form can be used. These are not meant to be resolvable. The value portion ([code]) will be matched against group and organization mappings. Note: Organizations with departmental WebStores must pass an attribute used for organization mapping that matches their External Organization Code. Shibboleth User Verification: Customer Implementation Guide

13 Attribute ou urn:mace:dir:attribute-def:ou urn:oid: Description Used for organization mapping. Multi-valued, comma or semi-colon delimiters are expected. Values will be matched against the External Organization Code (which can be found on the Organization page of the ELMS Administration website once it has been provided to Kivuto). When a match is made, a user verification will be created for the user linking them to the organization with any corresponding user groups. This can be used, for example, to specify that a user is a member of a specific department. Note: Organizations with departmental WebStores must pass an attribute used for organization mapping that matches their External Organization Code. edupersonorgunitdn urn:mace:dir:attribute-def:edupersonorgunitdn urn:oid: Used for organization mapping. The distinguished name(s) of the directory entries representing the user s organizational unit. Multi-valued, pipe ( ) characters are expected as delimiters. Values are expected in the DN form, e.g. ou=potions, o=hogwarts, dc=hsww, dc=wiz. In the example case, Potions would be the parsed value and would be matched against External Organization Code fields (see ou). Note: Organizations with departmental WebStores must pass an attribute used for organization mapping that matches their External Organization code. Surname urn:mace:dir:attribute-def:sn urn:oid: User s surname. givenname urn:mace:dir:attribute-def:givenname urn:oid: User s given name. mail urn:mace:dir:attribute-def:mail urn:oid: homeorganization urn:mace:switch.ch:attribute-def:swissedupersonhomeorganization urn:oid: User s address. The organization the user belongs to (SWITCHaai). Shibboleth User Verification: Customer Implementation Guide

14 Attribute homeorganizationtype urn:mace:switch.ch:attributedef:swissedupersonhomeorganizationtype urn:oid: Description The type of organization the user belongs to. A value of university or uas is required for the user to be granted academic eligibility (SWITCHaai). Shibboleth User Verification: Customer Implementation Guide

15 Configuring Shibboleth on your ELMS WebStore This section covers the following areas: Setting up Shibboleth as a WebStore Verification Type Configuring Shibboleth Verification o Details o Settings o Diagnostics Important: All tasks described in this section must be performed by a registered and active ELMS administrator while signed in to the ELMS Administration site ( You will need your organization s account number and a valid username and password to sign in. SETTING UP SHIBBOLETH AS A WEBSTORE VERIFICATION TYPE Before you can configure Shibboleth to work with your ELMS WebStore, you must define Shibboleth as a verification type. To set up Shibboleth as a verification type: 1. On the e5 Administration site, click: WebStore. 2. Click the Verification tab. The list of currently configured verification types is displayed. By default, User Import or a different verification type may have been configured for your WebStore when it was deployed. 3. Click the check box beside any verification type that is not Shibboleth and then click the Delete button (or click the Deactivate link in the Actions column next to any verification type that is not Shibboleth). 4. Click the Add button. A new window opens. 5. Click the check box beside Shibboleth. 6. Click the OK button to save your selection. CONFIGURING SHIBBOLETH VERIFICATION Once Shibboleth has been defined as a verification type for your organization, you need to configure it. Shibboleth User Verification: Customer Implementation Guide

16 To configure Shibboleth: 1. On the Main menu, go to WebStore. 2. Click the Verification tab. 3. Click the Shibboleth link. A new window opens with two tabs: Details and Settings. DETAILS TAB It is not generally necessary, or advisable, to change the default values of the fields on this tab. Use care if you want to change the default values for Sector and Verifications Expire In. Changing these values could break your implementation, resulting in your end-users not being able to sign into the ELMS WebStore. SETTINGS TAB The Settings page defines all of the customer (organization) information that is required by Kivuto. See Table 3: Settings. Note: Which settings are required depends on the implementation scenario. See Shibboleth Implementation Scenarios to determine which settings are required for your implementation. Table 3: Settings Information Relying Party Description List of federations that Kivuto is a member of (for example, InCommon, SWITCHaai). Identity Provider EntityID Federation discovery services (WAYF) can be bypassed by providing a value for this setting. If the WebStore is specific to a single IdP, then this value should be considered as required. The value should be exactly as it is found in metadata. For example: urn:mace:incommon:myorg.edu or IUV Administrator Address address of individual (or distribution list) who will receive error messages from ELMS. Shibboleth User Verification: Customer Implementation Guide

17 Information Hide Username Description When checked, this setting prevents a user's unique identifier from being shown in several places in the WebStore user interface. This is useful when a screen-friendly username is not provided (e.g. a GUID) as part of the set of released attributes from the IdP. Logout Redirect URL The URL where a user will be redirected to when they sign out from the WebStore and the Shibboleth SP. If left empty, on signing out the user will remain on the WebStore and will be shown a message similar to the following: You have been signed out of this website, but remain signed in to your Single Sign On system. If you want to log out completely, you MUST close your browser. Enable Diagnostics Mode Restrict Eligibility Scope When enabled, server state data is captured for every sign-in attempt, and the most recent of these may be viewed on the Diagnostics tab. See the Troubleshooting section under Testing your Integration. If checked, eligibility attributes (e.g. edupersonscopedaffiliation) will only be processed for users with accompanying attributes containing organization mapping information (ou, edupersonorgunitdn, ismemberof, edupersonentitlement). If unchecked, eligibility attributes will be processed for all users. If accompanying organization mapping attributes are present, users will be given membership in the corresponding organizations. Otherwise, users will be given membership in the WebStore organization. This data can be seen, post-login, by examining the corresponding user verification records (Users» [select user]» Verifications). Note: This option must be selected if you are configuring Shibboleth for a purely departmental WebStore so that only members of the appropriate department are granted eligibility. This is the only time this option should be selected. Shibboleth User Verification: Customer Implementation Guide

18 DIAGNOSTICS TAB The Diagnostics page displays data captured during recent sign-in attempts. Nothing will be shown unless Diagnostics Mode is enabled through the Settings page (see Table 3: Settings). For details on what is displayed, see the Troubleshooting section under Testing your Integration. Shibboleth User Verification: Customer Implementation Guide

19 Post-Implementation Procedures This section describes steps that must be performed after your integration is complete. These include: Testing your Integration Restoring Administrative Roles TESTING YOUR INTEGRATION TESTING THE WORKFLOW Below are the common steps required for testing your implementation. 1. Configure your IdP. 2. Configure your ELMS WebStore. 3. Trigger the authentication process from your ELMS WebStore. If you are already signed in to the administration site, you will have to sign out first or use a different browser. If the Shibboleth verification type is in Testing status, you will have to use the testing URL found in WebStore» Verification that enables test verification methods when accessing your WebStore. 4. Authenticate with your IdP and ensure that you are then successfully signed in to your ELMS WebStore. 5. Validate the data created for the user in your ELMS WebStore as described in the next section. 6. When everything works as expected, contact Kivuto to proceed. VALIDATION After successful authentication, it is helpful to view a user s profile to ensure that all expected eligibility groups and personalization information has been set correctly. From the ELMS WebStore: 1. Click the Your Account/Orders link above the page banner. 2. Click the Account Details link. Any personalization information that was passed is displayed. 3. Return to the Your Account/Orders page and click the Your Eligibility link to view the eligibility groups that your account has been assigned to. Shibboleth User Verification: Customer Implementation Guide

20 From the ELMS Administration site: 1. On the Main menu, go to Users. 2. Search for the desired user and click the Username to navigate to the details page. Any personalization information passed is displayed. 3. Click the Verifications tab. For each successful authentication there will be an entry that contains the expected list of eligibility groups. TROUBLESHOOTING Should you run into problems during authentication, or if the personalization or eligibility information was not created as expected for your users, then it may be helpful to enable Diagnostics Mode (see Table 3). Data captured during recent sign-in attempts, whether successful or not, will then be displayed on the Shibboleth Diagnostics tab. Clicking on an individual sign-in attempt brings up a Details page with the following sections: User o Username, first and last names, address. Empty for failed attempts. User Verifications o For each organization the user was mapped to (via ou, ismemberof, etc.), the corresponding user verification, along with the unique member identifier, the verification expiry date, and user group memberships. Empty for failed attempts. Shibboleth Server Variables o The IIS server variables that were part of the Shibboleth session active during the sign-in attempt. If expected attributes are not shown here, then the Shibboleth server has discarded them due to an unsupported mapping or value formatting. For a breakdown of how entries in the Shibboleth Server Variables section map to Shibboleth attributes, see Table 4: Shibboleth Server Variables. Other Server Variables o Other IIS server variables active during the sign-in attempt. Not likely useful, but presented in case a variable was not classified correctly, and included in the Shibboleth section above. Shibboleth User Verification: Customer Implementation Guide

21 Table 4: Shibboleth Server Variables Variable Name HTTP_TARGETEDID HTTP_PERSISTENTID HTTP_AFFILIATION HTTP_ISMEMBEROF HTTP_ACADEMICCAREER HTTP_PRINCIPALNAME HTTP_GIVENNAME HTTP_MAIL HTTP_SURNAME HTTP_UID HTTP_ENTITLEMENT HTTP_OU HTTP_ORGUNITDN Attribute Name(s) edupersontargetedid urn:oid: urn:oasis:names:tc:saml:2.0:nameid-format:persistent urn:mace:dir:attribute-def:edupersonaffiliation urn:oid: urn:mace:dir:attribute-def:edupersonscopedaffiliation urn:oid: urn:mace:dir:attribute-def:edupersonprimaryaffiliation urn:oid: urn:mace:dir:attribute-def:ismemberof urn:oid: urn:mace:dir:attribute-def:academiccareer rn:oid: urn:mace:dir:attribute-def:edupersonprincipalname urn:oid: urn:mace:dir:attribute-def:givenname urn:oid: urn:mace:dir:attribute-def:mail urn:oid: urn:mace:dir:attribute-def:sn urn:oid: urn:mace:dir:attribute-def:uid urn:oid: urn:mace:dir:attribute-def:employeenumber urn:oid: urn:mace:dir:attribute-def:edupersonentitlement urn:oid: urn:mace:dir:attribute-def:ou urn:oid: urn:mace:dir:attribute-def:edupersonorgunitdn urn:oid: Shibboleth User Verification: Customer Implementation Guide

22 Variable Name HTTP_UNIQUEID HTTP_HOMEORGANIZATION HTTP_HOMEORGANIZATIONTYPE HTTP_STUDYBRANCH1 HTTP_STUDYBRANCH2 Attribute Name(s) urn:mace:switch.ch:attribute-def:swissedupersonuniqueid urn:oid: urn:mace:switch.ch:attribute-def:swissedupersonhomeorganization urn:oid: urn:mace:switch.ch:attribute-def:swissedupersonhomeorganizationtype urn:oid: urn:mace:switch.ch:attribute-def:swissedupersonstudybranch1 urn:oid: urn:mace:switch.ch:attribute-def:swissedupersonstudybranch2 1. urn:oid: HTTP_STUDYBRANCH3 HTTP_STUDYLEVEL urn:mace:switch.ch:attribute-def:swissedupersonstudybranch3 urn:oid: urn:mace:switch.ch:attribute-def:swissedupersonstudylevel urn:oid: RESTORING ADMINISTRATIVE ROLES Shibboleth implementation creates a new account for each user of your WebStore. When a user s new username does not match their old username, administrative roles are not passed from the old account to the new. As a result, some of your WebStore s administrators may find that they cannot access the ELMS administration site when they sign in with their new Shibboleth account. Affected administrators have two options if they wish to continue acting in their previous administrative capacity. 1. Contact Kivuto s DreamSpark Support Team and request that the administrative roles associated with their old account be assigned to their new account. Note: Depending on the role being requested, the request may have to come from the primary administrator of your WebStore (i.e. the individual under whose name your organization s DreamSpark subscription was issued). 2. Continue to sign in using their old account credentials rather than through Shibboleth. This can be done through the admin sign-in portal at: e5.onthehub.com/admin. Shibboleth User Verification: Customer Implementation Guide

23 Shibboleth Implementation Scenarios The nature of your organization, WebStore and software-distribution agreement determine which of the attributes described in Table 2 are required by Kivuto and which of the settings described in Table 3 must be configured in order to successfully implement Shibboleth verification. This section describes the most common Shibboleth implementation scenarios and summarizes the unique implementation requirements of each. Scenario 1: Organizational ELMS WebStore for a single federation member Scenario 2: Departmental ELMS WebStore for a single federation member Scenario 3: Integrated ELMS WebStore for a single federation member Scenario 4: ELMS WebStore for ALL members of a federation SCENARIO 1: ORGANIZATIONAL ELMS WEBSTORE FOR A SINGLE FEDERATION MEMBER In this scenario, an ELMS WebStore is deployed for a single federation member (organization) under an organization-wide agreement (e.g. DreamSpark Standard). The organization is directly integrated to the federation without users having to choose their organization through the use of discovery services (WAYF). The implementation requirements for Scenario 1 are as follows. See Table 2 and Table 3 for a description of each attribute and setting listed, and for optional additional attributes/settings. Attribute Requirements: Unique identifier for a user. For example: edupersontargetedid Persistent ID UID edupersonprincipalname Eligibility (user group) identifier for a user. For example: edupersonscopedaffiliation edupersonaffiliation edupersonprimaryaffiliation ismemberof (for custom user groups) edupersonentitlement (for custom user groups) ELMS Configuration Requirements: On the e5 WebStore Verification Settings page: Select your federation from the Relying Party dropdown list. Identify your discovery services provider in the Identity Provider EntityID field. Provide an IUV Administrator Address. Shibboleth User Verification: Customer Implementation Guide

24 SCENARIO 2: DEPARTMENTAL ELMS WEBSTORE FOR A SINGLE FEDERATION MEMBER In this scenario, an ELMS WebStore is deployed for a specific department of a federation member (organization) under a departmental agreement (e.g. DreamSpark Premium). Important: A parameter matching the department s External Organization Code must be provided in this scenario so that access is restricted to members of the eligible department. The implementation requirements for Scenario 2 are as follows. See Table 2 and Table 3 for a description of each attribute and setting listed, and for optional additional attributes/settings. Attribute Requirements: Unique identifier for a user. For example: edupersontargetedid Persistent ID UID edupersonprincipalname Eligibility (user group) identifier for a user. For example: edupersonscopedaffiliation edupersonaffiliation edupersonprimaryaffiliation ismemberof (for custom user groups) edupersonentitlement (for custom user groups) Organization (department) identifier configured to match the appropriate External Organization Code. For example: ismemberof edupersonorgunitdn ou ELMS Configuration Requirements: On the e5 WebStore Verification Settings page: Select your federation from the Relying Party dropdown list. Identify your discovery services provider in the Identity Provider EntityID field. Provide an IUV Administrator Address. Select the Restrict Eligibility Scope option to restrict eligibility to members of the appropriate department. (Note: This is the only scenario in which this option is selected.) SCENARIO 3: INTEGRATED ELMS WEBSTORE FOR A SINGLE FEDERATION MEMBER In this scenario, an integrated ELMS WebStore (i.e. a WebStore that combines organizational and departmental agreements, so that some users are eligible to access all offerings while others are only eligible to access some offerings) is deployed for a single federation member (organization). The implementation requirements for Scenario 3 are as follows. See Table 2 and Table 3 for a description of each attribute and setting listed, and for optional additional attributes/settings. Shibboleth User Verification: Customer Implementation Guide

25 Attribute Requirements: Unique identifier for a user. For example: edupersontargetedid Persistent ID UID edupersonprincipalname Eligibility (user group) identifier for a user. For example: edupersonscopedaffiliation edupersonaffiliation edupersonprimaryaffiliation ismemberof (for custom user groups) edupersonentitlement (for custom user groups) Organization (department) identifier configured to match the appropriate External Organization Code.** For example: ismemberof edupersonorgunitdn ou ELMS Configuration Requirements: On the e5 WebStore Verification Settings page: Select your federation from the Relying Party dropdown list. Identify your discovery services provider in the Identity Provider EntityID field. Provide an IUV Administrator Address. **Note: If a value matching a department s External Organization Code is not passed, the user will still be able to sign in, but will only have access to products offered through the organizational program(s). SCENARIO 4: ELMS WEBSTORE FOR ALL MEMBERS OF A FEDERATION This scenario involves an ELMS WebStore deployed for ALL members of a federation. During the sign-in process, the WebStore points the user to a discovery services website (WAYF) where they choose the organization they belong to. The implementation requirements for Scenario 4 are as follows. See Table 2 and Table 3 for a description of each attribute and setting listed, and for optional additional attributes/settings. Attribute Requirements: Unique identifier for a user. For example: edupersontargetedid Persistent ID UID edupersonprincipalname Eligibility (user group) identifier for a user. For example: edupersonscopedaffiliation edupersonaffiliation edupersonprimaryaffiliation ismemberof (for custom user groups) edupersonentitlement (for custom user groups) ELMS Configuration Requirements: In the e5 WebStore Verification Settings page: Select your federation from the Relying Party dropdown list. DO NOT enter a value in the Identity Provider EntityID field (discovery services will be used instead). Provide an IUV Administrator Address. Shibboleth User Verification: Customer Implementation Guide

26 Support If you have any difficulties with configuring Shibboleth for ELMS or require technical assistance, send an to Be sure to include the following in your Customer Name Contact Name Contact Contact Phone ELMS Account Number Detailed description of the problem or request for information Shibboleth User Verification: Customer Implementation Guide