Carnegie Mellon University

Advanced Topics

Follow these steps to restrict access to only users:

Apache Servers

  1. In your .htaccess file or shib.conf configuration file, do the following:
    replace require valid-user with require eppn ~ .*$
  2. Edit shibboleth2.xml

  3. Add an additional MetadataFilter tag below <MetadataProvider>:

    <MetadataFilter type="Whitelist">

Microsoft IIS Servers

  1. Edit shibboleth2.xml, under <RequestMap> <Host.../> or under <RequestMap> <Path .../> include: <AccessControlProvider path="C:\opt\shibboleth-sp\etc\shibboleth\shibboleth2_ACL.xml" type="XML"/>
  2. Contents of shibboleth2_ACL.xml:
    <?xml version="1.0" encoding="UTF-8"?>
    <AccessControl xmlns="urn:mace:shibboleth:target:config:1.0"/>
    <RuleRegex require="eppn">$</RuleRegex>
  3. Add an additional MetadataFilter tag below <MetadataProvider>:

    <MetadataFilter type="Whitelist">

  1. Add the following line to /etc/shibboleth/attribute-map.xml:
    <Attribute name="urn:oid:" id="cmuAndrewCommonNamespaceId"/>
    Note: This adds the CMU specific attribute to the list of known mapped attributes.
  2. In /etc/shibboleth/shibboleth2.xml where HOSTNAME is the name of your service as known to users, change the following line
    <ApplicationDefaults entityID="https://HOSTNAME/shibboleth" REMOTE_USER="eppn persistent-id targeted-id">
    <ApplicationDefaults entityID="https://HOSTNAME/shibboleth" REMOTE_USER="cmuAndrewCommonNamespaceId">

Note: This configuration should be used to support legacy applications only. New web services should be designed to use an identifier in the form of "user@domain" to represent the authenticated identity. To release "cmuAndrewCommonNamespaceID" for your service provider, email a request

In addition to accepting identities from InCommon, some applications have an additional administrative area that will only accept identities from a specific identity provider.  Administrative users may find it annoying to work through a discovery service when they know that certain web pages will only accept identities from specific identity provider. The shibboleth2.xml configuration file normally defines where a user is directed when Shibboleth authentication is required.

In the shibboleth2.xml configuration file, the user may be directed to a discovery service: 

<SSO discoveryProtocol="SAMLDS" discoveryURL="">

 or to one specific identity provider:

 <SSO entityID="">

In the apache configuration file the following directives are normally used to protect pages with Shibboleth and will redirect an authenticating user to a discovery service or identity provider specified in shibboleth2.xml:

<Location /somewebpath/*.cgi>
AuthType shibboleth
ShibRequestSetting requireSession 1
ShibUseHeaders on
require valid-user

The following directives within an Apache configuration file will override the specification within the shibboleth2.xml file for specific pages and direct the authenticating user to a specific identity provider:

<Location /anotherwebpath/*.cgi>
AuthType shibboleth
ShibRequestSetting requireSession 1
ShibRequestSetting entityId
ShibUseHeaders on
require valid-user

Note that this configuration only affects where users are directed when authentication is required. Those who already have Shibboleth sessions will not be redirected even if they have not authenticated via the The restrictions on acceptance of user identities by the application must still be enforced by the application itself.

The following is released per the Attribute Release Policy for InCommon Federation Members. Individual service providers may request additional attributes be released.


  • eduPersonPrincipalName
  • eduPersonScopedAffiliation


  • givenName
  • surname
  • commonName
  • email
  • displayName