Skip to content »
ITS and UVa logos for printed output
MENU menu icon

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.

  1. Install Shibboleth.
    If installing on a CentOS Linux server with the UVa 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
  2. Configure your Service Provider (SP). Typically, all SP configuration files are under /etc/shibboleth.
    1. Shibboleth2.xml
      Change SP entityID:
            <ApplicationDefaults entityID=""
            REMOTE_USER="eppn persistent-id targeted-id">
            <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=""
            discoveryProtocol="SAMLDS" discoveryURL="">
      for initial testing, use the test IdP:
      <SSO entityID="">
      for production, change to the production IdP:
      <SSO entityID="">
      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"/>
    2. Attribute-map.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.
    3. Add the combined UVa IdP metadata
      wget --no-check-certificate -O /etc/shibboleth/uva-idp-metadata.xml \
    4. 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/ to generate these files.
  3. 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,
    mkdir /var/www/html/myapp
    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
  4. Enable httpd and shibd start on boot as appropriate for your distribution.
  5. Contact ITS to configure your SP; you are required to give ITS the entityID for your SP (via this request 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 ( if your entityID is in the domain. Other attributes released by default to any UVa SP are eduPersonAffiliation and eduPersonScopedAffiliation.
  6. 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/shibboleth
    Note: 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;

  Page Updated: Tuesday 2014-10-07 11:14:28 EDT