NetBadge at UVa
Information for Linux/Apache Developers
Installing & Configuring a Shibboleth Service Provider for NetBadge Single-Signon
These instructions are for Linux/Apache httpd and the Shibboleth Service Provider (SP) is installed and configured as a replacement for Pubcookie.
- Install Shibboleth.
If installing on a CentOS Linux server with the openuse.org security_shibboleth repo configured,
yum install shibboleth
If you are installing on a different distribution, you may find that one of the software repositories for your distribution has a Shibboleth package which you can install. Otherwise, see https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPLinuxInstall
- Configure your Service Provider (SP). Typically, all SP configuration files are under
Change SP entityID:
<ApplicationDefaults entityID="https://sp.example.org/shibboleth" REMOTE_USER="eppn persistent-id targeted-id"> to <ApplicationDefaults entityID="https://Your-Virtual-Host-Name/shibboleth" REMOTE_USER="uid eppn persistent-id targeted-id">To use only the UVa IdP, change SSO entityID:
<SSO entityID="https://idp.example.org/idp/shibboleth" discoveryProtocol="SAMLDS" discoveryURL="https://ds.example.org/DS/WAYF">for initial testing, use the test IdP:
<SSO entityID="https://shibidp-test.its.virginia.edu/idp/shibboleth">for production, change to the production IdP:
<SSO entityID="urn:mace:incommon:virginia.edu">Locate the block reading
<!-- Example of locally maintained metadata. --> <!-- <MetadataProvider type="XML" file="partner-metadata.xml"/> -->Insert after the "-->" the line
<MetadataProvider type="XML" file="uva-idp-metadata.xml"/>
Before the last line of the file (</Attributes>), insert to configure the uid attribute to be used for the REMOTE_USER variable:
<Attribute name="urn:oid:0.9.2342.19200300.100.1.1" id="uid"/>Add or uncomment other attribute definitions as needed.
- Add the combined UVa IdP metadata
wget --no-check-certificate -O /etc/shibboleth/uva-idp-metadata.xml \
- Verify that the SP certificate and private key files have been generated. Unless you changed the names in the shibboleth2.xml file, these should be named /etc/shibboleth/sp-cert.pem and /etc/shibboleth/sp-key.pem. If they are not present, use /etc/shibboleth/keygen.sh to generate these files.
- Configure Apache mod_shib as needed.
Authentication at the document root requires that you exempt some shibboleth URLs from the authentication requirement. The best way to do this seems to be use of mod_rewrite to serve the entire site internally from a lower-level directory, where you configure the authentication required, and exclude the shibboleth URLs from the rewrite processing. For example, if your DocumentRoot is /var/www/html,
and put the application under myapp; to authenticate and allow all users, configure:
RewriteEngine On RewriteRule ^/favicon.ico - [L] RewriteRule ^/shibboleth.* - [L] RewriteRule ^/Shibboleth.* - [L] RewriteRule ^/(.*) /myapp/$1 [QSA,L] <Directory "/var/www/html/myapp"> AuthType shibboleth ShibRequestSetting requireSession 1 require valid-user </Directory>
- Enable httpd and shibd start on boot as appropriate for your distribution.
- Contact ITS to configure your SP; you are required to give ITS
the entityID for your SP (via this
form). ITS will download your SP metadata from
and configure an attribute release filter for your SP which includes the attributes uid (computing id of the user) and eduPersonPrincipalName (email@example.com) if your entityID is in the virginia.edu domain. Other attributes released by default to any UVa SP are eduPersonAffiliation and eduPersonScopedAffiliation.
- If you have configured SELinux enforcing, the default
policies prevent the httpd from writing to
the shibd.sock file which is necessary for the httpd shibboleth module to communicate
with the shibboleth daemon. The Shibboleth statement on SELinux is that it is not supported; however,
it appears to be fairly easy to add the SELinux policies needed without having to disable SELinux.
Attempt a Shibboleth login, and if SELinux is blocking access to the socket, your browser will report either a Shibboleth error or a 500 Internal Error. The paths in this description are those used on CentOS; you may need to change these depending on your distribution of Linux. Check /var/log/audit/audit.log or /var/log/messages, and if you see that SELinux blocked httpd access to shibd.sock, you can create a shibboleth SELinux policy to allow access. Use
cd /tmp cat /var/log/audit/audit.log | audit2allow -M shibboleth semodule -i shibboleth.pp restorecon -R /var/run/shibbolethNote: if auditd is not configured, use /var/log/messages instead of the audit.log in the above command. A shibboleth.pp policy file should also have been added to /etc/selinux/targetd/modules/modules so that it will be activated on a system reboot.
On CentOS 6.5, with shibboleth 2.5, the policy change needed was:
#============= httpd_t ============== allow httpd_t initrc_t:unix_stream_socket connectto; allow httpd_t var_run_t:sock_file write;