Your campus may already support Shibboleth Authentication, which provides centralized authentication to the various online applications that your users access. Faculty Success supports Shibboleth Authentication, allowing your users to access Faculty Success either directly or via a link, such as "Access Faculty Success." After clicking this link, your campus' Shibboleth Identity Provider (IdP) will prompt users who do not already have a valid login session for their credentials, and then will automatically log them in to Faculty Success behind-the-scenes.
Shibboleth Authentication is a secure and convenient authentication method. Your users never have to provide their credentials to a Faculty Success server – only to your campus’s IdP. Moreover, you can use any authentication method you wish at your campus.
Some of the individuals whose activities you will track in Faculty Success may not have accounts in your campus IdP. In addition, you may wish to leave some administrator accounts to use Faculty Success default Local Authentication so they may still access Faculty Success, even if the IdP fails. You will need to provide a list of those user accounts that should continue to use the default, Local Authentication.
Technical Notes and Requirements
Federation Membership
You must be a member of a federation in order for Faculty Success to proceed with the implementation of Shibboleth. Faculty Success is a Sponsored Partner of the InCommon Federation. If your campus is also a member of the InCommon Federation, implementation is quite straightforward. If your campus is a member of a different federation, contact Faculty Success through a General work request to inquire whether we support Shibboleth authentication in conjunction with that federation.
Faculty Success requires federation membership for several reasons:
- Federations provide rules or guidelines for supported configurations and recommended attributes. These requirements help ensure Faculty Success ability to consistently support clients during initial setup, troubleshooting, and future changes.
- Federations allow interoperability between all member organizations, with reduced involvement by Information Technology staff for both Identity Providers and Service Providers.
- Federations require disclosure of privacy, access control, and security breach notification policies by member organizations, helping to ensuring the security and confidentiality of all private data.
Faculty Success strongly recommends membership in the InCommon Federation, the most widely used and trusted federation within higher education in the United States. Other public, regional, and national federations also exist; please review the following resources to identify a federation appropriate for your campus:
|
Note: Faculty Success must also join the federation you choose to participate in, which may affect the time required to enable Shibboleth authentication for your campus. Additionally, many higher education federations require that commercial one or more higher education members sponsor Service Providers; please determine if your organization could act as a sponsor for Faculty Success application process. As part of evaluating membership in additional federations, Faculty Success will need to consider the impact of any fees assessed for joining. To request that Faculty Success consider joining a federation, please provide the federation's web site URL in a General work request. |
Faculty Success EntityID
Although Shibboleth Authentication requires the involvement of your campus’s technical staff resources, it provides the most secure and convenient solution. To implement it, your campus must configure your Shibboleth Identity Provider (IdP) to work with Faculty Success’ Shibboleth Service Provider (SP).
Faculty Success Shibboleth Service Provider EntityID is https://www.DigitalMeasures.com/shibboleth-sp/. This URL also provides our self-published Shibboleth Service Provider metadata, which will be required if you are not a member of InCommon. You should configure your Identity Provider to release attributes to any server listed in Faculty Success Service Provider metadata to allow use from both our Production and Beta testing environments.
SAML 2.x Compliance
When implementing Shibboleth authentication, please consider that SAML 2.x compliance is strongly recommended. For more information on the SAML specification, please see http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf.
The eduPersonPrincipalName Attribute
At present, we support Shibboleth only for authentication. By default, Faculty Success will use the eduPersonPrincipalName attribute as the username, removing any text following the @ sign. The eduPersonPrincipalName is not part of the SAML specification; however, it has been widely adopted, particularly by members of the InCommon Federation. For more information regarding how you should implement this attribute, please see http://www.incommonfederation.org/attributesummary.html.
The requirements for usernames in Faculty Success are that they:
- Must be unique
- Cannot contain the “@” character
- Cannot be longer than 50 characters
- May contain any ASCII character (with the exception of the "@" character, as noted above)
Login Error Redirect Protocol
There are cases where authentication can succeed but the login attempt can fail once a request has been passed to Faculty Success. For example, if the eduPersonPrincipalName value you pass does not match an enabled Faculty Success username, the login attempt will fail. When this occurs, the user is, by default, redirected to a Faculty Success Local Authentication login page. If you would prefer us to redirect the user to a different URL such as your campus helpdesk URL, please provide it as part of your General work request.
Single-Sign-Off protocol
As Shibboleth does not yet define a standard Single-Sign-Off protocol, many campuses have created a custom implementation. If you have a Single-Sign-Off URL that we should redirect users to after local logout, please provide the URL in the General work request. Also, if your Single-Sign-Off implementation supports a query parameter to redirect the user after central logout, please indicate the query parameter as well.
Troubleshooting Resources
If you encounter issues when implementing Shibboleth authentication, there are many helpful resources available online. To get in touch with other Shibboleth experts, we recommend the following mailing lists:
- InCommon: https://lists.incommon.org/sympa/info/participants
- Shibboleth: http://shibboleth.internet2.edu/lists.html
You could also utilize TestShib Two, a testing service for new installations of Shibboleth 2. Please visit http://www.testshib.org for more details.
Test Account
Faculty Success requires a test account to test connectivity during the initial set up of Shibboleth Authentication and on an ongoing basis as we make changes or enhancements to our Faculty Success Shibboleth environment. For this reason, it is necessary for this test account to remain active.
|
Warning: Without a test account, Faculty Success will be unable to test Shibboleth changes for you. This will prevent Faculty Success from ensuring that future Shibboleth enhancements and upgrades will have no adverse impact on your configuration. |
In the absence of a test account, it will be necessary for you to perform any required testing. Since we may need to make changes quickly, Faculty Success cannot guarantee a certain amount of advance notice when making a request that you test. Of course, Faculty Success will provide as much advance notice as possible. If you prefer testing on your end to providing a test account, please provide the contact information for the individual Faculty Success should contact with Shibboleth questions. If we present questions to this individual, all contact will occur via email. As the Faculty Success Administrator, we will copy you on such messages.
Implementation Details
Once your technical staff has completed the required steps, they will need to provide you the following technical details:
- Your institution's Shibboleth EntityID
- The name of the Shibboleth federation in which you participate
- A permanent test username and password; alternatively, the contact information for the person on your campus who will be testing Shibboleth Authentication
- A login error redirect (optional)
- A single sign-off URL, if your campus has one (optional)
- A URL for authentication errors, if users should receive instructions regarding who to contact in the event that access is denied (optional)
Once you have received this information, submit a General work request with it and your list of excluded users, if any.
|
Warning:You should submit the password for the test account Faculty Success will use in an attachment to the work request, rather than in the work request note itself. When Faculty Success responds to one of your work requests, we send you a notification email to alert you that the request is awaiting your response. This notification email will include the text from the original work request note. As attachments to work requests are never included in the notification email, including passwords and other sensitive details in an attachment will ensure that these always remain within the secure Work Requests utility. |
Faculty Success will complete the necessary work to configure Shibboleth Authentication in Faculty Success for you. Faculty Success will provide the login URL configured to use your IdP and ask you to confirm the date on which we should switch the user accounts to Shibboleth Authentication.
|
Important: Users can no longer use the Faculty Success login page after they have been switched to Shibboleth Authentication. |