For IT Pros This page provides additional information on how to configure your Shibboleth installation in order to restrict access to members of the Urbana campus only.
<MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
<MetadataFilter type="Signature" certificate="itrust.pem"/>
<!-- Limit users to those from Urbana's IDP -->
<!-- InCommon Per-Entity Metadata Distribution Service -->
<MetadataProvider type="Dynamic" ignoreTransport="true" maxCacheDuration="86400" minCacheDuration="60">
<MetadataFilter type="RequireValidUntil" maxValidityInterval="1209600"/>
<MetadataFilter type="Signature" certificate="inc-md-cert-mdq.pem"/>
<!-- Limit users to those from Urbana's IDP -->
This copy of shibboleth2.xml can be configured to restrict access to specific IDPs, meaning that if someone tries to log in through a different IDP, the sessionError.html template will be returned to that person. You may want to customize that file to suit your site's look and feel.
The attributes with names that don't start with iTrust should be widely supported by InCommon IDPs. Therefore, you should use eduPerson attributes when possible to ensure the greatest compatibility with other universities' attribute naming conventions. Uncomment whichever eduPerson or other non-iTrust attributes your application needs.
The use of eduPersonPrincipalName is highly recommended for federated applications, while uid is not recommended. That's because two different people can have the same NetID or uid at two different institutions, but when you scope it (firstname.lastname@example.org) to the end of it, the identifier becomes unique.
In order to complete federating with inCommon, the Shibboleth service managers will need to register you as a delegated administrator in the InCommon Federation Manager and help you enter your metadata. (This is easiest to do if you've already gotten things working in I-Trust first, as noted above.)
The Shibboleth managers will then need to approve your submission to InCommon as the campus site administrators.
After that, InCommon staff will review and approve the submission before publishing the metadata.
Once this is done, all InCommon IDPs will have their metadata within 24 hours.
In rare cases, you may need users from an institution neither in I-Trust or InCommon to have access to your service. Smaller schools or international organizations are both good examples of this. If this describes your service, you'll need to manually generate metadata that describes your service and send it to the IDP operator for that organization. Before doing this, ask if the organization is a member of another federation and if they'd be willing to sponsor your registration in that federation. Joining a federation is much cleaner and more secure than manually sharing metadata and should always be the preferred option. If, however, your only choice is to manually share metadata, the following sections explain how to generate it. Send the results to the IDP operator at the institution you're federating with along with a list of attributes you need supplied. Make sure to check and see if that institution has any other requirements for federating with your service provider.
If you're on Unix, you can manually generate metadata using the /etc/shibboleth/metagen.sh script. If the hostname in your entity ID is also one of the hostnames that your web server answers to, run:
/etc/shibboleth/metagen.sh -c /etc/shibboleth/sp-cert.pem -h entityid.hostname.illinois.edu >metadata.xml
Add more -h flags followed by the hostnames configured in your web server to represent each hostname that will have Shibboleth-protected applications on your server. Each hostname that users will be visiting requiring Shibboleth authentication must be listed or the IDP will not send responses back. Always list the hostname used for your entity ID first, as this hostname is used to generate the entity ID in the metadata.
If you're using a system hostname not used by your web server as your entity ID, you'll need to add the -e option to the above command:
/etc/shibboleth/metagen.sh -c /etc/shibboleth/sp-cert.pem -e https://entity.id.illinois.edu/shibboleth -h some.hostname.illinois.edu >metadata.xml
As above, add more -h flags if you have multiple hostnames hosted by your web server that will need Shibboleth authentication.
The Windows SP doesn't include a metagen.sh. Instead, use your web browser or a command-line web tool to retrieve your metadata from the metadata handler at . You may need to modify hostnames in the generated XML. Look through this file and ensure that location attributes for each assertionConsumerService matches the hostname your web server answers to. If your web server answers to multiple hostnames, copy these elements so that you have a set for each hostname that Shibboleth needs to know about.
The above discoveryUrl settings will send your user to the InCommon centralized discovery service which lists all institutions in InCommon when asking the user to select their campus. This is more than likely overkill for your needs unless you really are allowing logins from every school in InCommon. You can, of course, whitelist only the organizations whose users should be allowed in on your service provider, but all InCommon members will still be presented to your users from the discovery service.
In a case like this, you may wish to run your own embedded discovery service. This not only lets you choose which institutions are presented as options to your users, but it allows you to give the discovery service page the same look and feel as the rest of your site. Conveniently, embedded discovery services are extremely easy to set up and configure, and the Shibboleth project offers one. Installation and configuration instructions can be found at https://wiki.shibboleth.net/confluence/display/EDS10/Embedded+Discovery+Service
Next, continue from step 7 (restart and registration) in Shibboleth, Setting up a Service Provider .