LSU-Specific Service Providers

Service Provider Registration

The registration process serves a number of purposes, such as tracking and record keeping within the IT Security and Policy Office to better support campus users, auditing of information disclosure about users (so we know who's getting what and why), and secure binding of certificates. Some of the information is also required for the secure operation of the Shibboleth system, and must be updated in the event that it changes. Therefore accurate contact information is essential.

The current registration process is largely manual (via e-mail), but may be more automated in the future. To initiate the process, the following information must be supplied in an email to servicedesk@lsu.edu with a subject of "Shibboleth - LSU Service Provider Registration".

1. Name of service (if multiple, just summarize)
2. Brief description of service
3. Technical, administrative, and/or support contact information for this service (names, e-mail addresses, phone, etc.)
4. Is the service in-house where a department/LSU employee will be managing it, or will it be off-site (Software-as-a-Service) managed by a third party?
5. User attributes required by this service such as email (mail), first name (givenName), last name (sn), lsuId (lsuPersonLSUID), etc.
6. Will this service need LSU to release a "NameID" value as any of the following?
   • emailAddress ("jdoe@lsu.edu")
   • uid ("jdoe")
   • unspecified ("jdoe")
7. A copy of your service's metadata, or your service's entityID if you are a member of InCommon
8. The Test URL for this service (if applicable)
9. The Production for this service
10. Should this service only be accessible to certain users? If yes, please elaborate (e.g. Faculty, students, staff, etc. which would need to equate to a set of SAM profiles or ActiveDirectory groups)

Once your submission is processed, LSU's Test Shibboleth server will be configured to work with your service. When a successful login can be performed by Security Personnel, then this configuration change will be pushed through LSU's Change Management process in order to move the configuration to LSU's production Shibboleth servers.

Information Service Providers will need from LSU

• LSU is a member of the InCommon federation, and LSU's EntityID is: https://webauth.shib.lsu.edu/idp/shibboleth
• If your service is not a member of the InCommon federation, download LSU's IDP Metadata
• If your service has a logout feature, then after logging out, it should redirect to: https://webauth.shib.lsu.edu/idp/logout.jsp

Firewall Configuration

An LSU-specific deployment requires that an outbound firewall allow the server running Shibboleth to make outgoing HTTP requests on port 443 and 8443 to all servers that respond to the DNS alias "webauth.shib.lsu.edu". There may be multiple physical addresses behind those names. No Shibboleth-specific inbound traffic is necessary.

Software Configuration

The following steps will enable you to (relatively) easily modify the default software configuration to support and "lock down" access to LSU identity provider, enable your new key and certificate, and customize the settings to your web server and service provider configuration. Some of the specific changes depend on your environment, but this should provide a suitable starting point.

1. Supplement/replace default configuration files with these files

Download the following files (right click and save) and place them in the etc/shibboleth/ folder beneath your installation root:

lsu-attribute-policy.xml
lsu-metadata.pem
sessionError.html

Replace the default etc/shibboleth/shibboleth2.xml file with the appropriate version:

• shibboleth2.xml

Replace the default etc/shibboleth/attribute-map.xml file with this version:

• attribute-map.xml

2. Make site-specific changes to shibboleth2.xml file

The primary Shibboleth configuration file is in etc/shibboleth/shibboleth2.xml . The LSU version supplied is a starting point that includes most of the LSU-specific settings required, and reasonable defaults for campus applications. Some of the content is based on your application requirements and your particular configuration, and must be modified to reflect this. To get up and running, make these changes:

• Replace any references to the dummy hostname changeme.lsu.edu with the fully-qualified domain name of your web server. On Apache servers, this value should correspond to the Apache ServerName directive (which you may also need to set).


• If you're using IIS, and need to enable the filter for multiple virtual host names, you will need to insure that the <ISAPI> element contains a <Site> element mapping your IIS web sites' INSTANCE_ID values to the appropriate hostname(s). Failure to do this will usually cause the filter to ignore requests you expect to be secured.


• Modify the <ApplicationDefaults> element's entityID attribute, replacing the default value with the identifier assigned to you when you register your service provider.


• Modify the <Errors> element's supportContact attribute, replacing the default value with the email address of your help desk or support personnel.


• Ensure that the <CredentialResolver> element near the end of the file contains the accurate filenames of your private key and certificate (and that they're located in the same directory as the configuration file).



3. Designate content to be protected

The final step (and an ongoing one) is to specify content that requires an authenticated session to access. Apache supports various commands for this purpose, but the <RequestMap> element in the Shibboleth configuration file must be used with IIS servers. This does not directly perform any authorization for you, but it does ensure that a session via LSU identity provider has been established and any attributes the software can obtain about the user are available.

By default, a single <Path> element and its requireSession attribute is used to designate that any content in a folder named "secure" beneath the server document root is protected. Each element specifies a single component of the URL path to a resource. The resource/file name itself can also be specified as a <Path> element (the leaf of a tree). You can nest elements to specify session requirements embedded within specific subtrees. Other approaches (such as regular expression matching based on the URL) are also supported. Here is a complete reference.

4. Start (or restart) Shibboleth service and web server

Once the initial changes described here have been made, you can try starting (or restarting) the various services and proceed to test and troubleshoot the installation. A few problems are not unexpected. The wiki and mailing list archive should help you diagnose problems or at least know where to look so you can provide accurate problem reports.

If you're getting metadata errors indicating the identity provider isn't supported, make sure you downloaded the lsu-metadata.pem file mentioned earlier, as you'll need it at runtime to verify the signature on the metadata file that contains the LSU IdP's information.

Next Steps

The preceding steps should get you close to a working Shibboleth-enabled service, but obviously there are a lot of complex options available and additional tasks necessary to maintain your deployment effectively. Additional information is available to assist with application development .