-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-
+<!doctype HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
- <head>
- <title>Shibboleth Target Deployment Guide</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=utf-8">
- <style type="text/css">
+
+<head>
+<meta http-equiv="Content-Language" content="en-us">
+<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
+<meta name="ProgId" content="FrontPage.Editor.Document">
+<title>Shibboleth Target Deployment Guide</title>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+<style type="text/css">
html
{
}
dl
{
-background-color: #DDDDDD;
-background-image: none;
+border-width:2px; background-color: #DDDDDD;
+background-image: url('none');
margin: 5px;
padding: 0px;
border-style: solid;
-border-bottom-width: 2px;
-border-top-width: 2px;
-border-left-width: 2px;
-border-right-width: 2px;
+
}
dt
{
background-color: #DDDDDD;
-background-image: none;
+background-image: url('none');
margin: 1px;
-padding: 1px;
+padding: 1px
}
dd
{
background-color: #DDDDDD;
-background-image: none;
+background-image: url('none');
margin: 0px;
-padding: 1px;
+padding: 1px
}
.attribute
{
font-size: 115%;
-font-color: #000000;
+color: #000000;
text-align: left;
background-color: #DDDDDD;
-border: 1px black inset;
-background-image: none;
+border: 1px inset black;
+background-image: url('none');
margin: 0px;
-padding: 2px;
+padding: 2px
}
.value
{
-font-color: #000000;
+color: #000000;
text-align: left;
background-color: #EEEEEE;
-background-image: none;
+background-image: url('none');
padding-top: 0em;
padding-bottom: 0.5em;
padding-right: 1em;
padding-left: 5em;
-border-style: solid;
border-bottom-width: none;
border-top-width: none;
border-left-width: 1px;
-border-right-width: 1px;
+border-right-width: 1px; border-left-style:solid; border-right-style:solid; border-top-style:solid; border-bottom-style:solid
}
.attributeopt
{
font-size: 115%;
-font-color: #000000;
+color: #000000;
text-align: left;
background-color: #BCBCEE;
-border: 1px black inset;
-background-image: none;
+border: 1px inset black;
+background-image: url('none');
margin: 0px;
-padding: 2px;
+padding: 2px
}
.valueopt
{
-font-color: #000000;
+color: #000000;
text-align: left;
background-color: #DDDDFF;
-background-image: none;
+background-image: url('none');
padding-top: 0em;
padding-bottom: 0.5em;
padding-right: 1em;
padding-left: 5em;
-border-style: solid;
border-bottom-width: none;
border-top-width: none;
border-left-width: 1px;
-border-right-width: 1px;
+border-right-width: 1px; border-left-style:solid; border-right-style:solid; border-top-style:solid; border-bottom-style:solid
}
.attributelong
{
font-size: 85%;
-font-color: #000000;
+color: #000000;
text-align: left;
background-color: #DDDDDD;
-border: 1px black inset;
-background-image: none;
+border: 1px inset black;
+background-image: url('none');
margin: 0px;
-padding: 2px;
+padding: 2px
}
.attributeoptlong
{
font-size: 85%;
-font-color: #000000;
+color: #000000;
text-align: left;
background-color: #BCBCEE;
-border: 1px black inset;
-background-image: none;
+border: 1px inset black;
+background-image: url('none');
margin: 0px;
-padding: 2px;
+padding: 2px
}
.demo
{
background-color: #EEEEEE;
padding: 3px;
}
-.fixedwidth
+.fixed
{
font-family: monospace;
font-size: 90%;
-font-color: #121212;
+color: #121212;
+}
+.feature
+{
+color: #00FF00
}
- </style>
- </head>
-
- <body link="red" vlink="red" alink="black" bgcolor="white">
- <center>
- <h2>Shibboleth Target Deployment Guide</h2>
- </center>
-
- Shibboleth Target Deployment Guide<br>
- Shibboleth Version 1.0<br />
- June 19, 2003<br />
-
-
- <h3>This version of the deploy guide is for Shibboleth v1.0. For
- documentation related to prior versions of Shibboleth, please
- consult the appropriate branch in the Shibboleth CVS.</h3>
-
- <h3>Federations have been abstracted out from the Shibboleth
- documentation. For further information on using Shibboleth in a
- federation, refer to the federation guide.</h3>
-
- <p>Shibboleth v1.0 is stable and secure enough to deploy in
- production scenarios. While attempts have been made to include all
- functionality that would represent a break of interoperability with
- previous versions in v1.0, be aware that future versions of
- Shibboleth are likely to be developed and may include further
- implementation of the architectural document, functional
- enhancements, and user interface improvements.</p>
-
- <h4>Major New Features - 1.0</h4>
- This new release contains many improvements and enhancements, including:
-
- <h5>Federation Support</h5>
- <ol>
- <li>
- Federation and trust support has been substantially extended. Federation
- structures are now defined. The set of metadata collected and managed
- by each Federation is more fully defined. The configuration values
- assigned by a Federation are now identified. <br>
- </li>
- <li>
- There is some support for targets to be members of multiple federations;
- this support will continue to evolve. When a browser user arrives,
- a target will determine which federation their origin belongs to,
- and then use the trust fabric associated with that Federation. <br>
- </li>
- <li>
- Better support for flexible and bilateral trust agreements. A key
- specific to an origin site can be used to vallidate its signature.
- <br>
- </li>
-
- <li>
- This version contains a significantly more mature security implementation,
- and should meet the security requirements of typical sites. <p></p>
- </li>
- </ol>
-
- <h5>Origin</h5>
- <ol>
-
- <li> The Attribute Authority has a powerful new attribute resolver.
- Simple scenarios (using a string attribute stored in ldap) can be
- accomplished by merely editing a configuration file. Java classes
- may still be written for more complex evaluations (eg retrieving information
- from multiple disparate repositories, and computing the SAML attribute
- using business rules). This should greatly simplify the process of
- configuring the AA to support additional general attributes.<br>
- </li>
- </ol>
-
- <h5>Target</h5>
- <ol>
- <li> Significantly more flexibility in configuring targets to ensure
- robustness. Failover and redundant configurations are now supported.
- <br>
- <ol>
- <li>The SHAR may now optionally store its session and attribute
- cache in a back-end database in addition to the previously available
- in-memory option. This would allow a site to run an apache server
- farm, with multiple SHARs, supporting the same set of sessions.
- </li>
- <li>Federation supplied files (sites.xml and trust.xml) are now
- refreshed in a much more robust manner. <br>
- </li>
-
- </ol>
- </li>
- <li>Attribute acceptance policies have been greatly enhanced, and now
- supports filtering of attribute values by sites. <br>
- </li>
- <li>The SHAR can be configured to request specific attributes from the
- Origin. <br>
- </li>
- </ol>
- <h5>Miscellaneous</h5>
- <ol>
- <li>Origin sites can configure a value to describe the type of authentication
- mechanism used at the origin site(e.g. password, Kerberos, PKI, etc.).
- This value is made available on the target side as Shib-Authentication-Method.
- <br>
- </li>
- <li>Various improvements to error handling. Origin sites are now able
- to supply an "error URL" and contact information to a federation.
- When a target encounters an error, it can include this information
- in the error page. <br>
-
- </li>
- <li>Local time string values are now used in log files. <br>
- </li>
- <li>Internationalization support has been extended.</li>
- </ol>
-
- <p>Before starting, please sign up for all applicable <a href=
- "http://shibboleth.internet2.edu/shib-misc.html#mailinglist">
- mailing lists</a>. Announcements pertinent to Shibboleth
- deployments and developments and resources for deployment
- assistance can be found here.</p>
-
- <p>Please send any questions, concerns, or eventual confusion
- to <a href=
- "mailto:mace-shib-users@internet2.edu">mace-shib-users@internet2.edu</a>.
- This should include, but not be limited to, questions about the
- documentation, undocumented problems, installation or
- operational issues, and anything else that arises. Please
- ensure that you have the <a href=
- "http://shibboleth.internet2.edu/release/shib-download.html">appropriate
- tarball</a> for your operating system.</p>
- <br>
- <hr>
- <br>
- <br>
-
-
- <h3><a name="TOC"></a>Shibboleth Target -- Table of
- Contents</h3>
+ </style>
+</head>
+
+<body link="red" vlink="red" alink="black" bgcolor="white">
+
+<center>
+<h2>Shibboleth Target Deployment Guide</h2>
+</center>
+<p>Shibboleth Target Deployment Guide<br>
+Shibboleth Version 1.0.1<br />
+July 15, 2003<br />
+</p>
+<h3>This version of the deploy guide is for Shibboleth v1.0.1. For documentation
+related to prior versions of Shibboleth, please consult the appropriate branch
+in the Shibboleth CVS.</h3>
+<h3>Federations have been abstracted out from the Shibboleth documentation. For
+further information on using Shibboleth in a federation, refer to the federation
+guide.</h3>
+<p>Shibboleth v1.0.1 is stable and secure enough to deploy in production
+scenarios. It is backward compatible with 1.0 in all respects, including
+configuration, but some older commands have been deprecated or replaced.</p>
+<p>Features and changes specific to 1.0.1 are marked with <span class="feature">
+[1.0.1]</span></p>
+<h4>Major New Features in 1.0 and 1.0.1</h4>
+<p>This new release contains several improvements and enhancements, including:
+</p>
+<h5>Federation Support</h5>
+<ol>
+ <li>Federation and trust support has been substantially extended. Federation
+ structures are now defined. The set of metadata collected and managed by
+ each Federation is more fully defined. The configuration values assigned by
+ a Federation are now identified. </li>
+ <li>There is some support for targets to be members of multiple federations;
+ this support will continue to evolve. When a browser user arrives, a target
+ will determine which federation their origin belongs to, and then use the
+ trust fabric associated with that Federation.</li>
+ <li>Better support for flexible and bilateral trust agreements. A key
+ specific to an origin site can be used to vallidate its signature.</li>
+ <li>This version contains a significantly more mature security
+ implementation, and should meet the security requirements of typical sites.</li>
+</ol>
+<h5>Origin</h5>
+<ol>
+ <li>The Attribute Authority has a powerful new attribute resolver. Simple
+ scenarios (using a string attribute stored in ldap) can be accomplished by
+ merely editing a configuration file. Java classes may still be written for
+ more complex evaluations (eg retrieving information from multiple disparate
+ repositories, and computing the SAML attribute using business rules). This
+ should greatly simplify the process of configuring the AA to support
+ additional general attributes.</li>
+ <li>Support for a runtime-derived per-requester persistent identifier
+ attribute to support anonymous personalization by targets has been added via
+ an attribute plugin. <span class="feature">[1.0.1]</span></li>
+ <li>Specialized sites without privacy needs can configure identity-based
+ handles interoperable with other SAML deployments. <span class="feature">
+ [1.0.1]</span></li>
+</ol>
+<h5>Target</h5>
+<ol>
+ <li>Significantly more flexibility in configuring targets to ensure
+ robustness. Failover and redundant configurations are now supported.</li>
+ <li>The SHAR may now optionally store its session and attribute cache in a
+ back-end database in addition to the previously available in-memory option.
+ This would allow a site to run an apache server farm, with multiple SHARs,
+ supporting the same set of sessions.</li>
+ <li>Federation supplied files (sites.xml and trust.xml) are now refreshed in
+ a much more robust manner. </li>
+ </li>
+ <li>The SHAR can be configured to request specific attributes from the
+ Origin. </li>
+ <li>The SHAR can use TCP sockets when responding to the Apache module, for
+ specialized deployment behind firewalls. <span class="feature">[1.0.1]</span>
+ </li>
+ <li>Attribute acceptance policies have been greatly enhanced, and are now
+ used to configure all aspects of attribute handling by the target, except
+ for requesting specific attributes by sitename. Adding attributes now takes
+ place in one configuration step. <span class="feature">[1.0.1]</span> </li>
+ <li>Support for Apache 1.3 on Windows NT/2000/XP/2003 has been added.
+ <span class="feature">[1.0.1]</span> </li>
+ <li>Microsoft IIS web server support has been added via an ISAPI filter and
+ extension. <span class="feature">[1.0.1]</span> </li>
+</ol>
+<h5>Miscellaneous</h5>
+<ol>
+ <li>Origin sites can configure a value to describe the type of
+ authentication mechanism used at the origin site(e.g. password, Kerberos,
+ PKI, etc.). This value is made available on the target side as Shib-Authentication-Method.
<br>
-
-
- <ol type="1">
- <li>
- <h4><a href="#1."><font color="black">Shibboleth
- Overview</font></a></h4>
-
- <ol type="a">
- <li><a href="#1.a."><font color=
- "black">Origin</font></a></li>
-
- <li><a href="#1.b."><font color=
- "black">Target</font></a></li>
-
- <li><a href="#1.c."><font color=
- "black">WAYF</font></a></li>
-
- <li><a href="#1.d."><font color=
- "black">Federations</font></a></li>
- </ol>
- </li>
-
- <li>
- <h4><a href="#2."><font color=
- "black">Planning</font></a></h4>
-
- <ol type="a">
- <li><a href="#2.a."><font color=
- "black">Requirements</font></a></li>
-
- <li><a href="#2.b."><font color="black">Join a
- Federation</font></a></li>
-
- <li><a href="#2.c."><font color="black">Security
- Considerations</font></a></li>
-
- <li><a href="#2.d."><font color="black">Server
- Certs</font></a></li>
-
- <li><a href="#2.e."><font color="black">Attribute Release
- Policies</font></a></li>
-
- <li><a href="#2.f."><font color="black">Designate
- Contacts</font></a></li>
-
- <li><a href="#2.g."><font color="black">Browser
- Requirements</font></a></li>
-
- <li><a href="#2.h."><font color=
- "black">Clocks</font></a></li>
-
- <li><a href="#2.i."><font color="black">Other
- Considerations</font></a></li>
- </ol>
- </li>
-
- <li>
- <h4><a href="#3."><font color=
- "black">Installation</font></a></h4>
-
- <ol type="a">
- <li><a href="#3.a."><font color="black">Software
- Requirements</font></a></li>
-
- <li><a href="#3.b."><font color="black">Deploy the
- Shibboleth Package</font></a></li>
-
- <li><a href="#3.c."><font color="black">Configure
- Apache</font></a></li>
- </ol>
- </li>
-
- <li>
- <h4><a href="#4."><font color="black">Getting
- Running</font></a></h4>
-
- <ol type="a">
- <li><a href="#4.a."><font color="black">Configuring
- <span class="fixedwidth">shibboleth.ini</span></font></a></li>
-
- <li><a href="#4.b."><font color="black">Dynamic Error
- Page Generation</font></a></li>
-
- <li><a href="#4.c."><font color="black">Key Generation
- and Certificate Installation</font></a></li>
-
- <li><a href="#4.d."><font color="black">Protecting
- Webpages</font></a></li>
-
- <li><a href="#4.e."><font color="black">Designing
- AAP's</font></a></li>
-
- <li><a href="#4.f."><font color="black">Using Attributes
- in Applications</font></a></li>
-
- <li><a href="#4.g."><font color="black"><span
- class="fixedwidth">siterefresh</span></font></a></li>
- </ol>
- </li>
-
- <li>
- <h4><a href="#5."><font color=
- "black">Troubleshooting</font></a></h4>
-
- <ol type="a">
- <li><a href="#5.a."><font color="black">Basic
- Testing</font></a></li>
-
- <li><a href="#5.b."><font color="black">Common
- Problems</font></a></li>
- </ol>
- </li>
+ </li>
+ <li>Various improvements to error handling. Origin sites are now able to
+ supply an "error URL" and contact information to a federation. When a target
+ encounters an error, it can include this information in the error page. <br>
+ </li>
+ <li>Local time string values are now used in log files. <br>
+ </li>
+ <li>Internationalization support has been extended.</li>
+</ol>
+<p>Before starting, please sign up for all applicable
+<a href="http://shibboleth.internet2.edu/shib-misc.html#mailinglist">mailing
+lists</a>. Announcements pertinent to Shibboleth deployments and developments
+and resources for deployment assistance can be found here.</p>
+<p>Please send any questions, concerns, or eventual confusion to
+<a href="mailto:mace-shib-users@internet2.edu">mace-shib-users@internet2.edu</a>.
+This should include, but not be limited to, questions about the documentation,
+undocumented problems, installation or operational issues, and anything else
+that arises. Please ensure that you have the
+<a href="http://shibboleth.internet2.edu/release/shib-download.html">appropriate
+tarball</a> for your operating system.</p>
+<p><br>
+</p>
+<hr>
+<p><br>
+<br>
+</p>
+<h3><a name="TOC"></a>Shibboleth Target -- Table of Contents</h3>
+<ol type="1">
+ <li>
+ <h4><a href="#1."><font color="black">Shibboleth Overview</font></a></h4>
+ <ol type="a">
+ <li><a href="#1.a."><font color="black">Origin</font></a></li>
+ <li><a href="#1.b."><font color="black">Target</font></a></li>
+ <li><a href="#1.c."><font color="black">WAYF</font></a></li>
+ <li><a href="#1.d."><font color="black">Federations</font></a></li>
</ol>
- <br>
- <hr>
- <br>
-
-
- <h3><a name="1."></a>1. Shibboleth Overview</h3>
-
- <p>Shibboleth is a system designed to exchange attributes
- across realms for the primary purpose of authorization. It
- provides a secure framework for one organization to transmit
- attributes about a web-browsing individual across security
- domains to another institution. In the primary usage case, when
- a user attempts to access a resource at a remote domain, the
- user's own home security domain can send certain information
- about that user to the target site in a trusted exchange. These
- attributes can then be used by the resource to help determine
- whether to grant the user access to the resource. The user may
- have the ability to decide whether to release specific
- attributes to certain sites by specifying personal Attribute
- Release Policies (ARP's), effectively preserving privacy while
- still granting access based on trusted information.</p>
-
- <p>When a user first tries to access a resource protected by
- Shibboleth, they are redirected to a service which asks the
- user to specify the organization from which they want to
- authenticate. If the user has not yet locally authenticated to
- a WebISO service, the user will then be redirected to their
- home institution's authentication system. After the user
- authenticates, the Shibboleth components at the local
- institution will generate a temporary reference to the user,
- known as a handle, for the individual and send this to the
- target site. The target site can then use the handle to ask for
- attributes about this individual. Based on these attributes,
- the target can decide whether or not to grant access to the
- resource. The user may then be allowed to access the requested
- materials.</p>
-
- <p>There are several controls on privacy in Shibboleth, and
- mechanisms are provided to allow users to determine exactly
- which information about them is released. A user's actual
- identity isn't necessary for many access control decisions, so
- privacy often is needlessly compromised. Instead, the resource
- often utilizes other attributes such as faculty member or member
- of a certain class. While these are commonly determined using
- the identity of the user, Shibboleth provides a way to mutually
- refer to the same principal without revealing that principal's
- identity. Because the user is initially known to the target site
- only by a randomly generated temporary handle, if sufficient,
- the target site might know no more about the user than that the
- user is a member of the origin organization. This handle should
- never be used to decide whether or not to grant access, and is
- intended only as a temporary reference for requesting
- attributes.</p>
-
- <h4><a name="1.a."></a>1.a. Origin</h4>
-
- <blockquote>
- <p>There are four primary components to the origin side in
- Shibboleth: the Attribute Authority (AA), the Handle Service
- (HS), the directory service, and the local sign-on system
- (SSO). The AA and HS are provided with Shibboleth, and an
- open-source WebISO solution Pubcookie is also supplied; the
- directory is provided by the origin site. Shibboleth is able
- to interface with a directory exporting an LDAP interface or a
- SQL database containing user attributes, and is designed such
- that programming interfaces to other repositories should be
- readily implemented. Shibboleth relies on standard web server
- mechanisms to trigger local authentication. A .htaccess file
- can be easily used to trigger either the local WebISO system
- or the web server's own Basic Auth mechanism, which will
- likely utilize an enterprise authentication system, such as
- Kerberos.</p>
-
- <p>From the origin site's point of view, the first contact
- will be the redirection of a user to the handle service,
- which will then consult the SSO system to determine whether
- the user has already been authenticated. If not, then the
- browser user will be asked to authenticate, and then sent
- back to the target URL with a handle bundled in an attribute
- assertion. Next, a request from the Shibboleth Attribute
- Requester (SHAR) will arrive at the AA which will include the
- previously mentioned handle. The AA then consults the ARP's
- for the directory entry corresponding to the handle, queries
- the directory for these attributes, and releases to the SHAR
- all attributes the SHAR is entitled to know about that
- user.</p>
- </blockquote>
-
- <h4><a name="1.b."></a>1.b. Target</h4>
-
- <blockquote>
- <p>There are three primary components to the target side in
- Shibboleth: the Shibboleth Indexical Reference Establisher
- (SHIRE), the Shibboleth Attribute Requester (SHAR), and the
- resource manager (RM). An implementation of each of these is
- included in the standard Shibboleth distribution. These
- components are intended to run on the same web server.</p>
-
- <p>From the target's point of view, a browser will hit the RM
- with a request for a Shibboleth-protected resource. The RM
- then allows the SHIRE to step in, which will use the WAYF to
- acquire the name of a handle service to ask about the user.
- The handle service (HS) will then reply with a SAML
- authentication assertion containing a handle, which the SHIRE
- then hands off to the SHAR. The SHAR uses the handle and the
- supplied address of the corresponding attribute authority
- (AA) to request all attributes it is allowed to know about
- the handle. The SHAR performs some basic validation and
- analysis based on attribute acceptance policies (AAP's).
- These attributes are then handed off to the RM, which is
- responsible for using these attributes to decide whether to
- grant access.</p>
- </blockquote>
-
- <h4><a name="1.c."></a>1.c. Where are you from? (WAYF)</h4>
-
- <blockquote>
- <p>The WAYF service can be either outsourced and operated by a
- federation or deployed as part of the SHIRE. It is responsible for
- allowing a user to associate themself with an institution of their
- specification, then redirecting the user to the known address for
- the handle service of that institution.</p>
- </blockquote>
-
- <h4><a name="1.d."></a>1.d. Federations</h4>
-
- <blockquote>
- <p>A federation provides part of the underlying trust required for
- function of the Shibboleth architecture. A federation in the
- context of Shibboleth is a group of organizations(universities,
- corporations, content providers, etc.) who agree to exchange
- attributes using the SAML/Shibboleth protocols and abide by a
- common set of policies and practices. In so doing, they must
- implicitly or explicitly agree to a common set of guidelines.
- Joining a federation is not explicitly necessary for operation of
- Shibboleth, but it dramatically expands the number of targets and
- origins that can interact without defining bilateral agreements
- between all these parties.</p>
-
- <p>A federation can be created in a variety of formats and trust
- models, but to support Shibboleth, it must provide a certain set
- of services to federation members. It needs to supply a registry
- to process applications to the federation and distribute
- membership information to the origin and target sites. This must
- include distribution of the PKI components necessary for trust
- between origins and targets. There also needs to be a set of
- agreements and best practices defined by the federation governing
- the exchange, use, and population of attributes before and after
- transit, and there should be a way to find information on local
- authentication and authorization practices for federation
- members.</p>
- </blockquote>
- <br>
- <br>
- <br>
- <hr>
- <br>
-
-
- <h3><a name="2."></a>2. Planning</h3>
-
- <p>There are several essential elements that must be present in
- the environment to ensure Shibboleth functions well, both
- political and technical. Shibboleth currently runs on a
- specific range of platforms and web server environments. The
- SHAR and SHIRE are implemented entirely in C/C++. These are the
- recommendations and requirements for a successful implementation
- of a Shibboleth target.</p>
-
- <h4><a name="2.a."></a>2.a. Requirements</h4>
-
- <blockquote>
- <p>Shibboleth currently only supports Linux and Solaris. At
- present, Shibboleth consists of Apache plugins and a separate SHAR
- process. The plugins use the ONC RPC mechanism to communicate with
- the SHAR. The target's web servers must be running <a href=
- "http://http://www.apache.org/dist/httpd/">Apache</a> 1.3.26+, but
- not Apache 2. More precise technical details are discussed in <a
- href="#3.a.">3.a</a>.</p>
- </blockquote>
-
- <h4><a name="2.b."></a>2.b. Join a Federation</h4>
-
- <blockquote>
- <p>While it is not necessary for a target or origin to join a
- federation, doing so greatly facilitates the implementation of
- multilateral trust relationships. Each federation will have a
- different application process.</p>
-
- <p>For more information on federations, refer to <a href=
- "#1.d.">1.d</a> or the Shibboleth v1.0 architectural
- document.</p>
- </blockquote>
-
- <h4><a name="2.c."></a>2.c. Security Considerations</h4>
-
- <blockquote>
- <p>Shibboleth's protocols and software have been extensively
- engineered to provide protection against many attacks.
- However, the most secure protocol can be compromised if it is
- placed in an insecure environment. To ensure Shibboleth is as
- secure as possible, there are several recommended security
- precautions which should be in place at local sites.</p>
-
- <ol type="i">
- <li>
- <p>SSL use is optional for target sites. Federation guidelines
- should be considered when determining whether to
- implement SSL, and, in general, SSL should be used for
- interactions with client machines to provide the
- necessary authentication and encryption to ensure
- protection from man-in-the-middle attacks. It is strongly
- suggested that all password traffic or similarly
- sensitive data should be SSL-protected. Assessment of the
- risk tradeoff against possible performance degradation
- should be performed for all applications.</p>
- </li>
-
- <li>
- <p>Many other attacks can be made on the several
- redirection steps that Shibboleth takes to complete
- attribute transfer. The best protection against this is
- safeguarding the WAYF service and ensuring that rogue
- targets and origins are not used, generally by
- development of the trust model underneath Shibboleth.
- Shibboleth also leverages DNS for security, which is not
- uncommon, but attacks concerning bad domain information
- should be considered.</p>
- </li>
-
- <li>
- <p>Information regarding origin users is generally
- provided by the authoritative enterprise directory, and
- the acceptance of requests from target applications can
- be carefully restricted to ensure that all requests the
- SHAR performs are authorized and all information the
- origin provides is accurate. Use of plaintext passwords
- is strongly advised against.</p>
- </li>
-
- <li>
- <p>Server platforms should be properly secured,
- commensurate with the level that would be expected for a
- campus' other security services, and cookie stores on
- client machines should be well protected.</p>
- </li>
- </ol>
- </blockquote>
-
- <h4><a name="2.d."></a>2.d. Server Certs</h4>
-
- <blockquote>
- <p>In the Shibboleth architecture, the SHAR, HS, and AA must
- all have various client and/or server certificates for use in
- signing assertions and creating SSL channels. These should be
- issued by a commonly accepted CA, which may be stipulated by
- your federation. After understanding the CA's acceptible to your
- federations, consult chapter <a href="#4.c.">4.c</a> for
- information on certificate and key generation.</p>
- </blockquote>
-
- <h4><a name="2.e."></a>2.e. Attribute Release Policies</h4>
-
- <blockquote>
- <p>The Attribute Authority maintains a set of rules called
- Attribute Release Policies (ARP's) that define which
- attributes are released to which targets. When a browser user
- tries to access a resource, the SHAR asks the origin site AA
- to release all the attributes it is allowed to know. The SHAR
- provides its own name and an optional URL on behalf of which
- the attribute request is made which can further refine the
- information the SHAR is allowed to know. The AA processes this
- request using all applicable ARP's, determines which
- attributes and values it will release, and then obtains the
- values actually associated with the browser user. The AA sends
- these attributes and values back to the SHAR.</p>
-
- <p>Targets should work together with expected origin sites to
- ensure that the sets of attributes that both sites expect to
- correspond using are congruent.</p>
- </blockquote>
-
- <h4><a name="2.f."></a>2.f. Designate Contacts</h4>
-
- <blockquote>
- <p>Since Shibboleth deals both with daily technical and
- operational issues and also with contractual issues, a set of
- contacts should be set up to support the user base and to
- facilitate interactions with other Shibboleth sites and federation
- members. It is recommended that at least technical and
- administrative contacts be designated. Names, titles, e-mail
- addresses, and phone numbers may all be useful information to
- provide.</p>
- </blockquote>
-
- <h4><a name="2.g."></a>2.g. Browser Requirements</h4>
-
- <blockquote>
- <p>A primary Shibboleth design consideration was to require
- very little or no modification to client machines. The only
- requirement is that a browser is used which supports cookies,
- redirection and SSL. Browser users will have to perform an
- additional click to submit the authentication assertion if
- JavaScript is not functional.</p>
- </blockquote>
-
- <h4><a name="2.h."></a>2.h. Clocks</h4>
-
- <blockquote>
- <p><a href="http://www.eecis.udel.edu/~ntp/">NTP</a> should
- be run on all web servers. Shibboleth employs a short handle
- issuance time to protect against replay attacks. Because of
- this, any significant degree of clock skew can hinder the
- ability of users to access sites successfully.</p>
- </blockquote>
-
- <h4><a name="2.h."></a>2.i. Other Considerations</h4>
-
- <blockquote>
- <p>Especially for higher education, there are a handful of
- laws enacted which may have important ramifications on the
- disclosure of personal information and attributes. Since
- Shibboleth does not necessarily need to transmit identity, it
- is an ideal solution for many higher education situations.
- Nevertheless, all parties within the United States of America
- are strongly advised to consult the <a href=
- "http://www.ed.gov/offices/OM/fpco/ferpa/">Family Educational
- Rights and Privacy Act of 1974(FERPA)</a>, and all other
- relevant state and federal legislation before deploying
- Shibboleth.</p>
- </blockquote>
- <br>
- <br>
- <hr>
- <br>
-
-
- <h3><a name="3."></a>3. Installation</h3>
-
- <h4><a name="3.a."></a>3.a. Software Requirements</h4>
-
- <p>The Shibboleth project makes binary packages available for
- Solaris and Linux that are precompiled against recent releases
- of various required libraries such as OpenSSL. It is highly
- advisable to build from source when using Shibboleth in a
- production environment in order to permit patching or updating
- of packages as security holes and bugs are fixed. Building from
- source is necessary to give you complete control over your
- deployment platform. The binary packages represent a snapshot in
- time only. To build from source, see the <span class="fixedwidth">INSTALL.txt</span>
- files in the root of the OpenSAML and Shibboleth source
- distributions.</p>
-
- <blockquote>
- <b>Operating System:</b>
-
- <ul type="circle">
- <li>
- RedHat 7.2-7.3:
-
- <ul type="disc">
- <li>
- <a href="http://www.apache.org/dist/httpd/">Apache 1.3.27</a>
-
- <blockquote>
- <p>Apache must be compiled with mod_so for DSO
- module support, and must include SSL
- support (preferably using <span class="fixedwidth">mod_ssl</span>), and
- EAPI support (which <span class="fixedwidth">mod_ssl</span> requires and
- provides). Shibboleth can coexist with
- <span class="fixedwidth">mod_auth</span>, which may be compiled or loaded
- into the server for use elsewhere, but Shibboleth
- does not need or use it. The most recent Red Hat
- RPM (1.3.23-14 as of this writing) is sufficient.
- </p>
- </blockquote>
-
- <blockquote>
- <p>On Linux, Shibboleth requires that Apache and
- Apache-SSL be built with <span
- class="fixedwidth">libpthread</span>, or loading the
- <span class="fixedwidth">mod_shibrm</span> or <span
- class="fixedwidth">mod_shire</span> modules will
- cause Apache to stop. While RedHat's Apache is
- compatible, Debian's Apache must be rebuilt with
- <span class="fixedwidth">libpthread</span>:</p>
+ </li>
+ <li>
+ <h4><a href="#2."><font color="black">Planning</font></a></h4>
+ <ol type="a">
+ <li><a href="#2.a."><font color="black">Requirements</font></a></li>
+ <li><a href="#2.b."><font color="black">Join a Federation</font></a></li>
+ <li><a href="#2.c."><font color="black">Security Considerations</font></a></li>
+ <li><a href="#2.d."><font color="black">Server Certificates</font></a></li>
+ <li><a href="#2.e."><font color="black">Attribute Release Policies</font></a></li>
+ <li><a href="#2.f."><font color="black">Designate Contacts</font></a></li>
+ <li><a href="#2.g."><font color="black">Browser Requirements</font></a></li>
+ <li><a href="#2.h."><font color="black">Clocks</font></a></li>
+ <li><a href="#2.i."><font color="black">Other Considerations</font></a></li>
+ </ol>
+ </li>
+ <li>
+ <h4><a href="#3."><font color="black">Installation</font></a></h4>
+ <ol type="a">
+ <li><a href="#3.a."><font color="black">Software Requirements</font></a></li>
+ <li><a href="#3.b."><font color="black">Deploy the Shibboleth Package</font></a></li>
+ <li><a href="#3.c."><font color="black">Configuring Apache 1.3.x</font></a></li>
+ <li><a href="#3.d."><font color="black">Configuring IIS</font></a></li>
+ <li><a href="#3.e."><font color="black">Running the SHAR on Windows</font></a></li>
+ </ol>
+ </li>
+ <li>
+ <h4><a href="#4."><font color="black">Getting Running</font></a></h4>
+ <ol type="a">
+ <li><a href="#4.a."><font color="black">Configuring <span class="fixed">
+ shibboleth.ini</span></font></a></li>
+ <li><a href="#4.b."><font color="black">Dynamic Error Page Generation</font></a></li>
+ <li><a href="#4.c."><font color="black">Key Generation and Certificate
+ Installation</font></a></li>
+ <li><a href="#4.d."><font color="black">Protecting Web Pages</font></a></li>
+ <li><a href="#4.e."><font color="black">Defining Attributes and
+ Acceptance Policies</font></a></li>
+ <li><a href="#4.f."><font color="black">Using Attributes in Applications</font></a></li>
+ <li><a href="#4.g."><font color="black"><span class="fixed">siterefresh</span></font></a></li>
+ </ol>
+ </li>
+ <li>
+ <h4><a href="#5."><font color="black">Troubleshooting</font></a></h4>
+ <ol type="a">
+ <li><a href="#5.a."><font color="black">Basic Testing</font></a></li>
+ <li><a href="#5.b."><font color="black">Common Problems</font></a></li>
+ </ol>
+ </li>
+</ol>
+<p><br>
+</p>
+<hr>
+<p><br>
+</p>
+<h3><a name="1."></a>1. Shibboleth Overview</h3>
+<p>Shibboleth is a system designed to exchange attributes across realms for the
+primary purpose of authorization. It provides a secure framework for one
+organization to transmit attributes about a web-browsing individual across
+security domains to another institution. In the primary usage case, when a user
+attempts to access a resource at a remote domain, the user's own home security
+domain can send certain information about that user to the target site in a
+trusted exchange. These attributes can then be used by the resource to help
+determine whether to grant the user access to the resource. The user may have
+the ability to decide whether to release specific attributes to certain sites by
+specifying personal Attribute Release Policies (ARP's), effectively preserving
+privacy while still granting access based on trusted information.</p>
+<p>When a user first tries to access a resource protected by Shibboleth, they
+are redirected to a service which asks the user to specify the organization from
+which they want to authenticate. If the user has not yet locally authenticated
+to a WebISO service, the user will then be redirected to their home
+institution's authentication system. After the user authenticates, the
+Shibboleth components at the local institution will generate a temporary
+reference to the user, known as a handle, for the individual and send this to
+the target site. The target site can then use the handle to ask for attributes
+about this individual. Based on these attributes, the target can decide whether
+or not to grant access to the resource. The user may then be allowed to access
+the requested materials.</p>
+<p>There are several controls on privacy in Shibboleth, and mechanisms are
+provided to allow users to determine exactly which information about them is
+released. A user's actual identity isn't necessary for many access control
+decisions, so privacy often is needlessly compromised. Instead, the resource
+often utilizes other attributes such as faculty member or member of a certain
+class. While these are commonly determined using the identity of the user,
+Shibboleth provides a way to mutually refer to the same principal without
+revealing that principal's identity. Because the user is initially known to the
+target site only by a randomly generated temporary handle, if sufficient, the
+target site might know no more about the user than that the user is a member of
+the origin organization. This handle should never be used to decide whether or
+not to grant access, and is intended only as a temporary reference for
+requesting attributes.</p>
+<h4><a name="1.a."></a>1.a. Origin</h4>
+<blockquote>
+ <p>There are four primary components to the origin side in Shibboleth: the
+ Attribute Authority (AA), the Handle Service (HS), the directory service,
+ and the local sign-on system (SSO). The AA and HS are provided with
+ Shibboleth, and an open-source WebISO solution Pubcookie is also supplied;
+ the directory is provided by the origin site. Shibboleth is able to
+ interface with a directory exporting an LDAP interface or a SQL database
+ containing user attributes, and is designed such that programming interfaces
+ to other repositories should be readily implemented. Shibboleth relies on
+ standard web server mechanisms to trigger local authentication. A .htaccess
+ file can be easily used to trigger either the local WebISO system or the web
+ server's own Basic Auth mechanism, which will likely utilize an enterprise
+ authentication system, such as Kerberos.</p>
+ <p>From the origin site's point of view, the first contact will be the
+ redirection of a user to the handle service, which will then consult the SSO
+ system to determine whether the user has already been authenticated. If not,
+ then the browser user will be asked to authenticate, and then sent back to
+ the target URL with a handle bundled in an attribute assertion. Next, a
+ request from the Shibboleth Attribute Requester (SHAR) will arrive at the AA
+ which will include the previously mentioned handle. The AA then consults the
+ ARP's for the directory entry corresponding to the handle, queries the
+ directory for these attributes, and releases to the SHAR all attributes the
+ SHAR is entitled to know about that user.</p>
+</blockquote>
+<h4><a name="1.b."></a>1.b. Target</h4>
+<blockquote>
+ <p>There are three primary components to the target side in Shibboleth: the
+ Shibboleth Indexical Reference Establisher (SHIRE), the Shibboleth Attribute
+ Requester (SHAR), and the resource manager (RM). An implementation of each
+ of these is included in the standard Shibboleth distribution. These
+ components are intended to run on the same web server.</p>
+ <p>From the target's point of view, a browser will hit the RM with a request
+ for a Shibboleth-protected resource. The RM then allows the SHIRE to step
+ in, which will use the WAYF to acquire the name of a handle service to ask
+ about the user. The handle service (HS) will then reply with a SAML
+ authentication assertion containing a handle, which the SHIRE then hands off
+ to the SHAR. The SHAR uses the handle and the supplied address of the
+ corresponding attribute authority (AA) to request all attributes it is
+ allowed to know about the handle. The SHAR performs some basic validation
+ and analysis based on attribute acceptance policies (AAP's). These
+ attributes are then handed off to the RM, which is responsible for using
+ these attributes to decide whether to grant access.</p>
+</blockquote>
+<h4><a name="1.c."></a>1.c. Where are you from? (WAYF)</h4>
+<blockquote>
+ <p>The WAYF service can be either outsourced and operated by a federation or
+ deployed as part of the SHIRE. It is responsible for allowing a user to
+ associate themself with an institution of their specification, then
+ redirecting the user to the known address for the handle service of that
+ institution.</p>
+</blockquote>
+<h4><a name="1.d."></a>1.d. Federations</h4>
+<blockquote>
+ <p>A federation provides part of the underlying trust required for function
+ of the Shibboleth architecture. A federation in the context of Shibboleth is
+ a group of organizations(universities, corporations, content providers,
+ etc.) who agree to exchange attributes using the SAML/Shibboleth protocols
+ and abide by a common set of policies and practices. In so doing, they must
+ implicitly or explicitly agree to a common set of guidelines. Joining a
+ federation is not explicitly necessary for operation of Shibboleth, but it
+ dramatically expands the number of targets and origins that can interact
+ without defining bilateral agreements between all these parties.</p>
+ <p>A federation can be created in a variety of formats and trust models, but
+ to support Shibboleth, it must provide a certain set of services to
+ federation members. It needs to supply a registry to process applications to
+ the federation and distribute membership information to the origin and
+ target sites. This must include distribution of the PKI components necessary
+ for trust between origins and targets. There also needs to be a set of
+ agreements and best practices defined by the federation governing the
+ exchange, use, and population of attributes before and after transit, and
+ there should be a way to find information on local authentication and
+ authorization practices for federation members.</p>
+</blockquote>
+<hr>
+<h3><a name="2."></a>2. Planning</h3>
+<p>There are several essential elements that must be present in the environment
+to ensure Shibboleth functions well, both political and technical. Shibboleth
+currently runs on a specific range of platforms and web server environments. The
+SHAR and SHIRE are implemented entirely in C/C++. These are the recommendations
+and requirements for a successful implementation of a Shibboleth target.</p>
+<h4><a name="2.a."></a>2.a. Requirements</h4>
+<blockquote>
+ <p>Shibboleth currently supports Windows NT/2000/XP/2003, Linux, and
+ Solaris. At present, Shibboleth consists of Apache (or IIS) plugins and a
+ separate SHAR process. The plugins use the ONC RPC mechanism to communicate
+ with the SHAR over Unix domain or TCP sockets. The target's web servers must
+ be running <a href="http://http://www.apache.org/dist/httpd/">Apache</a>
+ 1.3.26+, or Microsoft IIS 4.0+, but not Apache 2. More precise technical
+ details are discussed in <a href="#3.a.">3.a</a>.</p>
+</blockquote>
+<h4><a name="2.b."></a>2.b. Join a Federation</h4>
+<blockquote>
+ <p>While it is not necessary for a target or origin to join a federation,
+ doing so greatly facilitates the implementation of multilateral trust
+ relationships. Each federation will have a different application process.</p>
+ <p>For more information on federations, refer to <a href="#1.d.">1.d</a> or
+ the Shibboleth v1.0 architectural document.</p>
+ <p>To use Shibboleth without a federation, manual configuration of target
+ and origin trust and site information will be needed to insure that sites
+ interoperate. Most identifiers, such as site names, should be URI-based, and
+ should be chosen in accordance with DNS domains under the control of the
+ parties involved, much as Java package naming is coordinated. In other
+ words, don't use a URI containing a DNS domain or hostname that you do not
+ control.</p>
+</blockquote>
+<h4><a name="2.c."></a>2.c. Security Considerations</h4>
+<blockquote>
+ <p>Shibboleth's protocols and software have been extensively engineered to
+ provide protection against many attacks. However, the most secure protocol
+ can be compromised if it is placed in an insecure environment. To ensure
+ Shibboleth is as secure as possible, there are several recommended security
+ precautions which should be in place at local sites.</p>
+ <ol type="i">
+ <li>SSL use is optional for target sites, but should be used if at all
+ possible, at least in the processing of incoming sessions (called the
+ SHIRE URL or assertion consumer service). Federation guidelines should
+ be considered when determining whether to implement SSL, and, in
+ general, SSL should be used for interactions with client machines to
+ provide the necessary authentication and encryption to ensure protection
+ from man-in-the-middle attacks. It is strongly suggested that all
+ password traffic or similarly sensitive data should be SSL-protected.
+ Assessment of the risk tradeoff against possible performance degradation
+ should be performed for all applications.</li>
+ <li>Many other attacks can be made on the several redirection steps that
+ Shibboleth takes to complete attribute transfer. The best protection
+ against this is safeguarding the WAYF service and ensuring that rogue
+ targets and origins are not used, generally by development of the trust
+ model underneath Shibboleth. Shibboleth also leverages DNS for security,
+ which is not uncommon, but attacks concerning bad domain information
+ should be considered.</li>
+ <li>Information regarding origin users is generally provided by the
+ authoritative enterprise directory, and the acceptance of requests from
+ target applications can be carefully restricted to ensure that all
+ requests the SHAR performs are authorized and all information the origin
+ provides is accurate. Use of plaintext passwords is strongly advised
+ against.</li>
+ <li>Server platforms should be properly secured, commensurate with the
+ level that would be expected for an organization's other security
+ services, and cookie stores on client machines should be well protected.</li>
+ </ol>
+</blockquote>
+<h4><a name="2.d."></a>2.d. Server Certs</h4>
+<blockquote>
+ <p>In the Shibboleth architecture, the SHAR, HS, and AA must all have
+ various client and/or server certificates for use in signing assertions and
+ creating SSL channels. These should be issued by a commonly accepted CA,
+ which may be stipulated by your federation. After understanding the CA's
+ acceptible to your federations, consult chapter <a href="#4.c.">4.c</a> for
+ information on certificate and key generation.</p>
+</blockquote>
+<h4><a name="2.e."></a>2.e. Attribute Release Policies</h4>
+<blockquote>
+ <p>The Attribute Authority maintains a set of rules called Attribute Release
+ Policies (ARP's) that define which attributes are released to which targets.
+ When a browser user tries to access a resource, the SHAR asks the origin
+ site AA to release all the attributes it is allowed to know, possibly
+ restricted to specifically desired subset. The SHAR provides its own name
+ and an optional URL on behalf of which the attribute request is made which
+ can further refine the information the SHAR is allowed to know. The AA
+ processes this request using all applicable ARP's, determines which
+ attributes and values it will release, and then obtains the values actually
+ associated with the browser user. The AA sends these attributes and values
+ back to the SHAR.</p>
+ <p>Targets should work together with expected origin sites to ensure that
+ the sets of attributes that both sites expect to correspond using are
+ congruent.</p>
+</blockquote>
+<h4><a name="2.f."></a>2.f. Designate Contacts</h4>
+<blockquote>
+ <p>Since Shibboleth deals both with daily technical and operational issues
+ and also with contractual issues, a set of contacts should be set up to
+ support the user base and to facilitate interactions with other Shibboleth
+ sites and federation members. It is recommended that at least technical and
+ administrative contacts be designated. Names, titles, e-mail addresses, and
+ phone numbers may all be useful information to provide.</p>
+</blockquote>
+<h4><a name="2.g."></a>2.g. Browser Requirements</h4>
+<blockquote>
+ <p>A primary Shibboleth design consideration was to require very little or
+ no modification to client machines. The only requirement is that a browser
+ is used which supports cookies, redirection and SSL. Browser users will have
+ to perform an additional click to submit the authentication assertion if
+ JavaScript is not functional.</p>
+</blockquote>
+<h4><a name="2.h."></a>2.h. Clocks</h4>
+<blockquote>
+ <p><a href="http://www.eecis.udel.edu/~ntp/">NTP</a> should be run on all
+ web servers. Shibboleth employs a short handle issuance time to protect
+ against replay attacks. Because of this, any significant degree of clock
+ skew can hinder the ability of users to access sites successfully.</p>
+</blockquote>
+<h4><a name="2.h."></a>2.i. Other Considerations</h4>
+<blockquote>
+ <p>Especially for higher education, there are a handful of laws enacted
+ which may have important ramifications on the disclosure of personal
+ information and attributes. Since Shibboleth does not necessarily need to
+ transmit identity, it is an ideal solution for many higher education
+ situations. Nevertheless, all parties within the United States of America
+ are strongly advised to consult the
+ <a href="http://www.ed.gov/offices/OM/fpco/ferpa/">Family Educational Rights
+ and Privacy Act of 1974(FERPA)</a>, and all other relevant state and federal
+ legislation before deploying Shibboleth.</p>
+</blockquote>
+<p><br>
+</p>
+<hr>
+<h3><a name="3."></a>3. Installation</h3>
+<h4><a name="3.a."></a>3.a. Software Requirements</h4>
+<p>The Shibboleth project makes binary packages available for Solaris and Linux
+that are precompiled against recent releases of various required libraries such
+as OpenSSL. It is highly advisable to build from source when using Shibboleth in
+a production environment in order to permit patching or updating of packages as
+security holes and bugs are fixed. Building from source is necessary to give you
+complete control over your deployment platform. The binary packages represent a
+snapshot in time only. To build from source, see the <span class="fixed">
+INSTALL.txt</span> files in the doc folder of the OpenSAML and Shibboleth source
+distributions.</p>
+<p>The software requirements listed correspond to the binary distributions. In
+general, source builds should work against all recent versions of the operating
+systems and software dependencies listed below. For specific questions, inquire
+to the support mailing list, or give it a try. Note that OpenSSL releases
+frequent security updates; the version listed may not be the most current, but
+most minor "letter" updates should be usable.</p>
+<blockquote>
+ <p><b>Operating System:</b> </p>
+ <ul type="circle">
+ <li>RedHat 7.2-7.3:<ul type="disc">
+ <li><a href="http://www.apache.org/dist/httpd/">Apache 1.3.27</a><blockquote>
+ <p>Apache must be compiled with mod_so for DSO module support,
+ and must include SSL support (preferably using
+ <span class="fixed">mod_ssl</span>), and EAPI support (which
+ <span class="fixed">mod_ssl</span> requires and provides).
+ Shibboleth can coexist with <span class="fixed">mod_auth</span>,
+ which may be compiled or loaded into the server for use
+ elsewhere, but Shibboleth does not need or use it. The most
+ recent Red Hat RPM (1.3.27-2 as of this writing) is sufficient.</p>
+ </blockquote>
+ <blockquote>
+ <p>On Linux, Shibboleth requires that Apache and Apache-SSL be
+ built with <span class="fixed">libpthread</span>, or loading the
+ <span class="fixed">mod_shibrm</span> or <span class="fixed">
+ mod_shire</span> modules will cause Apache to stop. While
+ RedHat's Apache is compatible, Debian's Apache must be rebuilt
+ with <span class="fixed">libpthread</span>:</p>
<blockquote>
- <span class="fixedwidth">$ export LDFLAGS=-lpthread'<br>
- $ apt-build --rebuild --reinstall install apache-common apache \ apache-ssl</span>
+ <p><span class="fixed">$ export LDFLAGS=-lpthread<br>
+ $ apt-build --rebuild --reinstall install \<br>
+ apache-common apache apache-ssl</span></p>
</blockquote>
- </blockquote>
+ </blockquote>
</li>
-
- <li><a href=
- "http://shibboleth.internet2.edu/release/shib-download.html">
- Shibboleth v1.0 Target for RedHat</a></li>
-
- <li><a href= "http://www.openssl.org/source/">openssl-0.9.6,
- revision <span class="fixedwidth">i</span> or newer</a></li>
-
<li>
- libstdc++3-3.0.4-1.i386.rpm and
- libgcc-3.0.4-1.i386.rpm
-
- <blockquote>
- <p>Shibboleth binaries are currently built with <a href=
- "http://www.gnu.org/software/gcc/gcc.html">GCC
- 3.04</a>, and require these specific library
- versions. They are available as RPMs and are
- available in the RedHat 7.2 updates directory on
- any <a href=
- "ftp://rufus.w3.org/linux/redhat/updates/7.2/en/os/i386/">
- RedHat mirror</a>. They can be installed alongside
- earlier and later GCC libraries.</p>
- </blockquote>
+ <a href="http://shibboleth.internet2.edu/release/shib-download.html">
+ Shibboleth v1.0.1 Target for RedHat</a></li>
+ <li><a href="http://www.openssl.org/source/">openssl-0.9.6, revision
+ <span class="fixed">i</span> or newer</a></li>
+ <li>libstdc++3-3.0.4-1.i386.rpm and libgcc-3.0.4-1.i386.rpm<blockquote>
+ <p>Shibboleth binaries are currently built with
+ <a href="http://www.gnu.org/software/gcc/gcc.html">GCC 3.04</a>,
+ and require these specific library versions. They are available
+ as RPMs and are available in the RedHat 7.2 updates directory on
+ any
+ <a href="ftp://rufus.w3.org/linux/redhat/updates/7.2/en/os/i386/">
+ RedHat mirror</a>. They can be installed alongside earlier and
+ later GCC libraries.</p>
+ </blockquote>
</li>
-
- <li><b>Portions of the <span
- class="fixedwidth">libphp4</span> Apache plugin are written
- in C++, as is Shibboleth. There is a known conflict between
- the PHP extensions <span
- class="fixedwidth">libpspell.so</span> and <span
- class="fixedwidth">libsablot.so</span> which will manifest
- itself as segmentation faults when starting Apache. If a
- site wants to use <span class="fixedwidth">libphp4.so</span>
- and Shibboleth at once, then one of the following may be
- done:</b>
- <ol>
- <li>
- Remove the options <span class="fixedwidth">--with-pspell</span> and <span class="fixedwidth">--with-xslt-sablot</span> from PHP's configuration.
- </li>
- <li>
- Rebuild these two modules using
- the same version of GCC that was used to compile Shibboleth.
- </li>
- </ol>
+ <li><b>Portions of the <span class="fixed">libphp4</span> Apache
+ plugin are written in C++, as is Shibboleth. There is a known
+ conflict between the PHP extensions <span class="fixed">libpspell.so</span>
+ and <span class="fixed">libsablot.so</span> which will manifest
+ itself as segmentation faults when starting Apache. If a site wants
+ to use <span class="fixed">libphp4.so</span> and Shibboleth at once,
+ then one of the following may be done:</b><ol>
+ <li>Remove the options <span class="fixed">--with-pspell</span>
+ and <span class="fixed">--with-xslt-sablot</span> from PHP's
+ configuration.</li>
+ <li>Rebuild these two modules using the same version of GCC that
+ was used to compile Shibboleth.</li>
+ </ol>
</li>
- </ul>
+ </ul>
</li>
- <br>
- <li>
- Solaris 2.8:
-
- <ul type="disc">
- <li><a href=
- "ftp://ftp.openssl.org/source/openssl-0.9.7a.tar.gz">
- openssl-0.9.7a</a>
-
- <blockquote>
- <p>The shared library version of OpenSSL is required
- by Shibboleth. The static libraries may be installed as
- well if necessary for other applications, but cannot be
- used within mod_ssl or any other Apache modules.</p>
- </blockquote>
+ <p><br>
+ </li>
+ <li>Solaris 2.8:<ul type="disc">
+ <li><a HREF="ftp://ftp.openssl.org/source/openssl-0.9.7b.tar.gz">
+ openssl-0.9.7b</a>
+ <blockquote>
+ <p>The shared library version of OpenSSL is required by
+ Shibboleth. The static libraries may be installed as well if
+ necessary for other applications, but cannot be used within
+ mod_ssl or any other Apache modules.</p>
+ </blockquote>
+ </li>
+ <li><a href="http://www.apache.org/dist/httpd/">Apache 1.3.27</a><blockquote>
+ <p>Apache must be compiled with mod_so for DSO module support,
+ and must include SSL support (preferably using
+ <span class="fixed">mod_ssl</span>) and EAPI support (which
+ <span class="fixed">mod_ssl</span> requires and provides).
+ Shibboleth can coexist with <span class="fixed">mod_auth</span>,
+ which may be compiled or loaded into the server for use
+ elsewhere, but Shibboleth does not need or use it.</p>
+ <p><span class="fixed">mod_ssl</span>'s loadable module,
+ <span class="fixed">libssl.so</span>, must be compiled against
+ <span class="fixed">OpenSSL 0.9.7b</span>'s shared libraries.
+ Other versions or a statically linked build of
+ <span class="fixed">libssl.so</span> will cause failures such as
+ bus errors when used with Shibboleth.</p>
+ <p>To check how OpenSSL was built, run the <span class="fixed">
+ ldd</span> command against <span class="fixed">libssl.so</span>
+ in the Apache <span class="fixed">/libexec/</span> folder and
+ check the output for references to <span class="fixed">
+ libssl.so.0.9.7b</span>. If you see an earlier version
+ mentioned, or no mention of it at all, then <span class="fixed">
+ OpenSSL 0.9.7b</span> must be built with shared libraries from
+ source, and the Apache module rebuilt with it.</p>
+ </blockquote>
</li>
-
<li>
- <a href="http://www.apache.org/dist/httpd/">Apache 1.3.27</a>
-
- <blockquote>
- <p>Apache must be compiled with mod_so for DSO
- module support, and must include SSL
- support (preferably using <span class="fixedwidth">mod_ssl</span>) and EAPI
- support (which <span class="fixedwidth">mod_ssl</span> requires and
- provides). Shibboleth can coexist with
- <span class="fixedwidth">mod_auth</span>, which may be compiled or loaded
- into the server for use elsewhere, but Shibboleth
- does not need or use it.</p>
-
- <p><span class="fixedwidth">mod_ssl</span>'s
- loadable module, <span class="fixedwidth">libssl.so</span>, must be
- compiled against <span class="fixedwidth">OpenSSL
- 0.9.7a</span>'s shared libraries. Other versions or
- a statically linked build of <span
- class="fixedwidth">libssl.so</span> will cause
- failures such as bus errors when used with
- Shibboleth.</p>
-
- <p>To check how OpenSSL was built, run the <span
- class="fixedwidth">ldd</span> command against <span
- class="fixedwidth">libssl.so</span> in the Apache
- <span class="fixedwidth">/libexec/</span> folder and
- check the output for references to <span
- class="fixedwidth">libssl.so.0.9.7a</span>. If you
- see an earlier version mentioned, or no mention of
- it at all, then <span class="fixedwidth">OpenSSL
- 0.9.7a</span> must be rebuilt with shared libraries
- from source.</p>
- </blockquote>
+ <a href="ftp://ftp.sunfreeware.com/pub/freeware/sparc/8/libgcc-3.2.2-sol8-sparc-local.gz">
+ libgcc v3.2.2+ and libstdc++ v3.2.2+</a><blockquote>
+ <p>Shibboleth binaries are currently built with
+ <a HREF="http://www.gnu.org/software/gcc/gcc.html">GCC 3.2.2</a>,
+ and require these specific library versions or newer. They are
+ available as Sun freeware packages and can be installed
+ alongside earlier and later GCC libraries.</p>
+ </blockquote>
</li>
-
- <li><a href=
- "ftp://ftp.sunfreeware.com/pub/freeware/sparc/8/libgcc-3.2.2-sol8-sparc-local.gz">
- libgcc v3.2.2+ and libstdc++ v3.2.2+</a></li>
-
- <li><a href=
- "http://shibboleth.internet2.edu/release/shib-download.html">
- Shibboleth v1.0 Target for Solaris</a></li>
-
- <li><b>Portions of the <span
- class="fixedwidth">libphp4</span> Apache plugin are written
- in C++, as is Shibboleth. There is a known conflict with
- the PHP extensions <span
- class="fixedwidth">libpspell.so</span> and <span
- class="fixedwidth">libsablot.so</span> which will manifest
- itself as segmentation faults when starting Apache. If a
- site wants to use <span class="fixedwidth">libphp4.so</span>
- and Shibboleth at once, then one of the following may be
- done:</b>
- <ol>
- <li>
- Remove the options <span class="fixedwidth">--with-pspell</span> and <span class="fixedwidth">--with-xslt-sablot</span> from PHP's configuration.
- </li>
- <li>
- Rebuild these two modules using the same version of GCC
- that was used to compile Shibboleth.
- </li>
- </ol>
+ <li>
+ <a href="http://shibboleth.internet2.edu/release/shib-download.html">
+ Shibboleth v1.0.1 Target for Solaris</a></li>
+ <li><b>Portions of the <span class="fixed">libphp4</span> Apache
+ plugin are written in C++, as is Shibboleth. There is a known
+ conflict with the PHP extensions <span class="fixed">libpspell.so</span>
+ and <span class="fixed">libsablot.so</span> which will manifest
+ itself as segmentation faults when starting Apache. If a site wants
+ to use <span class="fixed">libphp4.so</span> and Shibboleth at once,
+ then one of the following may be done:</b><ol>
+ <li>Remove the options <span class="fixed">--with-pspell</span>
+ and <span class="fixed">--with-xslt-sablot</span> from PHP's
+ configuration.</li>
+ <li>Rebuild these two modules using the same version of GCC that
+ was used to compile Shibboleth.</li>
+ </ol>
</li>
- </ul>
+ </ul>
</li>
- <br>
- <li>
- RedHat 8:
- <blockquote>
- <p>RedHat 8 ships with Apache 2, which is not supported by
- Shibboleth. To run Shibboleth under this OS, <a
- href="http://www.apache.org/dist/httpd/">Apache 1.3.27</a>
- must be installed.</p>
- </blockquote>
- <blockquote>
- <p>Apache must be compiled with mod_so for DSO
- module support, and must include SSL
- support (preferably using <span class="fixedwidth">mod_ssl</span>), and
- EAPI support (which <span class="fixedwidth">mod_ssl</span> requires and
- provides). Shibboleth can coexist with
- <span class="fixedwidth">mod_auth</span>, which may be compiled or loaded
- into the server for use elsewhere, but Shibboleth
- does not need or use it. The most recent Red Hat
- RPM (1.3.23-14 as of this writing) is sufficient.
- </p>
- </blockquote>
-
- <blockquote>
- <p>On Linux, Shibboleth requires that Apache and
- Apache-SSL be built with <span
- class="fixedwidth">libpthread</span>, or loading the
- <span class="fixedwidth">mod_shibrm</span> or <span
- class="fixedwidth">mod_shire</span> modules will
- cause Apache to stop. While RedHat's Apache is
- compatible, Debian's Apache must be rebuilt with
- <span class="fixedwidth">libpthread</span>:</p>
- <blockquote>
- <span class="fixedwidth">$ export LDFLAGS=-lpthread'<br>
- $ apt-build --rebuild --reinstall install apache-common apache \ apache-ssl</span>
- </blockquote>
- </blockquote>
-
- <ul type=disc>
-
- <li><a href=
- "http://shibboleth.internet2.edu/release/shib-download.html">
- Shibboleth 1.0 Target for RedHat</a></li>
-
- <li><a href= "http://www.openssl.org/source/">openssl-0.9.6,
- revision <span class="fixedwidth">i</span> or newer</a></li>
-
+ <p><br>
+ </li>
+ <li>RedHat 8 and 9:<blockquote>
+ <p>RedHat 8 and 9 ship with Apache 2, which is not yet supported by
+ Shibboleth. To run Shibboleth under this OS,
+ <a href="http://www.apache.org/dist/httpd/">Apache 1.3.27</a> must
+ be installed.</p>
+ </blockquote>
+ <blockquote>
+ <p>Apache must be compiled with mod_so for DSO module support, and
+ must include SSL support (preferably using <span class="fixed">
+ mod_ssl</span>), and EAPI support (which <span class="fixed">mod_ssl</span>
+ requires and provides). Shibboleth can coexist with
+ <span class="fixed">mod_auth</span>, which may be compiled or loaded
+ into the server for use elsewhere, but Shibboleth does not need or
+ use it. The most recent Red Hat RPM (1.3.23-14 as of this writing)
+ is sufficient.</p>
+ </blockquote>
+ <blockquote>
+ <p>On Linux, Shibboleth requires that Apache and Apache-SSL be built
+ with <span class="fixed">libpthread</span>, or loading the
+ <span class="fixed">mod_shibrm</span> or <span class="fixed">
+ mod_shire</span> modules will cause Apache to stop. While RedHat's
+ Apache is compatible, Debian's Apache must be rebuilt with
+ <span class="fixed">libpthread</span>:</p>
+ <blockquote>
+ <p><span class="fixed">$ export LDFLAGS=-lpthread<br>
+ $ apt-build --rebuild --reinstall install apache-common \<br>
+ apache apache-ssl</span></p>
+ </blockquote>
+ </blockquote>
+ <ul type="disc">
<li>
- libstdc++3-3.0.4-1.i386.rpm and
- libgcc-3.0.4-1.i386.rpm
-
- <blockquote>
- <p>Shibboleth binaries are currently built with <a href=
- "http://www.gnu.org/software/gcc/gcc.html">GCC
- 3.04</a>, and require these specific library
- versions. They are available as RPMs and are
- available in the RedHat 7.2 updates directory on
- any <a href=
- "ftp://rufus.w3.org/linux/redhat/updates/7.2/en/os/i386/">
- RedHat mirror</a>. They can be installed alongside
- earlier and later GCC libraries.</p>
- </blockquote>
+ <a href="http://shibboleth.internet2.edu/release/shib-download.html">
+ Shibboleth 1.0.1 Target for RedHat</a></li>
+ <li><a href="http://www.openssl.org/source/">openssl-0.9.6, revision
+ <span class="fixed">i</span> or newer</a></li>
+ <li>libstdc++3-3.0.4-1.i386.rpm and libgcc-3.0.4-1.i386.rpm
+ <blockquote>
+ <p>Shibboleth binaries are currently built with
+ <a href="http://www.gnu.org/software/gcc/gcc.html">GCC 3.04</a>,
+ and require these specific library versions. They are available
+ as RPMs and are available in the RedHat 7.2 updates directory on
+ any
+ <a href="ftp://rufus.w3.org/linux/redhat/updates/7.2/en/os/i386/">
+ RedHat mirror</a>. They can be installed alongside earlier and
+ later GCC libraries.</p>
+ </blockquote>
</li>
-
- <li><b>Portions of the <span
- class="fixedwidth">libphp4</span> Apache plugin are written
- in C++, as is Shibboleth. There is a known conflict with
- the PHP extensions <span
- class="fixedwidth">libpspell.so</span> and <span
- class="fixedwidth">libsablot.so</span> which will manifest
- itself as segmentation faults when starting Apache. If a
- site wants to use <span class="fixedwidth">libphp4.so</span>
- and Shibboleth at once, then one of the following may be
- done:</b>
- <ol>
- <li>
- Remove the options <span class="fixedwidth">--with-pspell</span> and <span class="fixedwidth">--with-xslt-sablot</span> from PHP's configuration.
- </li>
- <li>
- Rebuild these two modules using
- the same version of GCC that was used to compile Shibboleth.
- </li>
- </ol>
+ <li><b>Portions of the <span class="fixed">libphp4</span> Apache
+ plugin are written in C++, as is Shibboleth. There is a known
+ conflict with the PHP extensions <span class="fixed">libpspell.so</span>
+ and <span class="fixed">libsablot.so</span> which will manifest
+ itself as segmentation faults when starting Apache. If a site wants
+ to use <span class="fixed">libphp4.so</span> and Shibboleth at once,
+ then one of the following may be done:</b>
+ <ol>
+ <li>Remove the options <span class="fixed">--with-pspell</span>
+ and <span class="fixed">--with-xslt-sablot</span> from PHP's
+ configuration. </li>
+ <li>Rebuild these two modules using the same version of GCC that
+ was used to compile Shibboleth. </li>
+ </ol>
</li>
- </ul>
+ </ul>
</li>
- </ul>
- </blockquote>
-
- <h4><a name="3.b."></a>3.b. Deploy the Shibboleth Package</h4>
-
- <blockquote>
- <p>For the sake of clarity, this deployment guide assumes
- that standard directories are used for all installations.
- These directories may be changed for local implementations,
- but must be done so consistently.</p>
-
- <ol type="1">
- <li>
- <p>Ensure that you have obtained the proper <a href=
- "http://shibboleth.internet2.edu/release/shib-download.html">
- tarball</a> for your operating system.</p>
- </li>
-
- <li>
- <p>The tarballs expand into <span class="fixedwidth">/opt/shibboleth</span>,
- and should be expanded as <span class="fixedwidth">root</span> from <span class="fixedwidth">/</span>.
- You should see the following directory structure:</p>
-
- <blockquote>
- <span class="fixedwidth">$ ls -al<br>
- drwxr-xr-x 10 root root 4096 Oct 24 03:54 .<br>
- drwxr-xr-x 3 root root 4096 Oct 24 00:37 ..<br>
+ </ul>
+</blockquote>
+<h4><a name="3.b."></a>3.b. Deploy the Shibboleth Package</h4>
+<blockquote>
+ <p>For the sake of clarity, this deployment guide assumes that standard
+ directories are used for all installations. These directories may be changed
+ for local implementations, but must be done so consistently.</p>
+ <ol type="1">
+ <li>Ensure that you have obtained the proper
+ <a href="http://shibboleth.internet2.edu/release/shib-download.html">
+ tarball</a> for your operating system.</li>
+ <li>On Unix, the tarballs expand into <span class="fixed">
+ /opt/shibboleth</span>, and should be expanded as <span class="fixed">
+ root</span> from <span class="fixed">/</span>. If you use a different
+ layout or location, you will need to adjust your configuration files.
+ You should see the following directory structure (date and size details
+ notwithstanding):<blockquote>
+ <p><span class="fixed">$ ls -l<br>
drwxr-xr-x 2 root root 4096 Oct 24 03:54 bin<br>
drwxr-xr-x 2 root root 4096 Oct 24 03:54 doc<br>
drwxr-xr-x 4 root root 4096 Oct 24 03:54 etc<br>
drwxr-xr-x 13 root root 4096 Oct 24 03:54 include<br>
drwxr-xr-x 4 root root 4096 Oct 24 03:55 lib<br>
drwxr-xr-x 2 root root 4096 Oct 24 03:55 libexec<br>
- drwxr-xr-x 4 root root 4096 Oct 24 02:02 share<br>
- </span>
- </blockquote>
- </li>
- </ol>
- </blockquote>
-
- <h4><a name="3.c."></a>3.c. Configure Apache</h4>
-
- <blockquote>
- <ol type="1">
- <li>
- <p>Shibboleth includes configuration directives in the
- file <span class="fixedwidth">/opt/shibboleth/etc/shibboleth/apache.config</span>
- which must be added to the httpd.conf file used locally.
- It is recommended that these directives simply be added
- to the end of the existing <span class="fixedwidth">httpd.conf</span> file
- rather than trying to merge it in-line;
- <a href="#3.c.2.">step 2</a> describes the necessary
- modifications to the Apache startup script. The default
- configuration will often work, but if customization is
- necessary, these options may be modified:</p>
-
- <dl>
-
- <dd class="attribute">
- <span class="fixedwidth">LoadModule <module>
- <pathname></span>
- </dd>
-
- <dd class="value">
- <p>Specifies the title and location of the
- <span class="fixedwidth">shibrm_module</span> resource manager and
- <span class="fixedwidth">shire_module</span> SHIRE modules. These are
- installed by default at
- <span class="fixedwidth">/opt/shibboleth/libexec/mod_shibrm.so</span>
- and
- <span class="fixedwidth">/opt/shibboleth/libexec/mod_shire.so</span></p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">SHIREConfig <pathname></span>
- </dd>
-
- <dd class="value">
- <p>Specifies the <span class="fixedwidth">pathname</span> of the SHIRE's
- configuration file. Defaults to
- <span class="fixedwidth">/opt/shibboleth/etc/shibboleth/shibboleth.ini</span>.</p>
- </dd>
-
- <dd class="attribute"><span class="fixedwidth">SHIREURL <url><br>
- <Location <url>><br>
- SetHandler <method><br>
- </Location></span></dd>
-
- <dd class="value">
- <p>Specifies the <span class="fixedwidth">URL</span> and the
- <span class="fixedwidth">method</span> the target uses to handle
- requests for Shibboleth-protected resources.
- Currently, <span class="fixedwidth">shib-shire-post</span> is the only
- available handler <span class="fixedwidth">method</span>.
- <span class="fixedwidth">SHIREURL</span> is used by Shibboleth when
- re-directing the user to the WAYF and
- <span class="fixedwidth"><Location></span> by Apache; for this
- reason, both <span class="fixedwidth">URL</span> specifications must
- match. Note that the configuration file itself
- contains <>'s, and <span class="fixedwidth">Location</span> should
- not be replaced.</p>
-
- <p>The referenced <span class="fixedwidth">URL</span> can be either a
- partial path or an absolute URL. The partial path
- allows each virtual server to use its own
- hostname and port in the SHIRE for session cookie
- purposes, while the absolute URL forces HTTP
- virtual servers to use HTTPS for the SHIRE. Use
- of a full <span class="fixedwidth">https://</span> URL is advised.</p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">ShibMapAttribute <attribute-uri>
- <HTTP-header> [alias]</span>
- </dd>
-
- <dd class="value">
- <p>Registers attributes to be recognized and maps
- them to an authorization <span class="fixedwidth">alias</span> for use
- in <span class="fixedwidth">.htaccess</span> files or Location Blocks
- with <span class="fixedwidth">require</span> directives.
- <span class="fixedwidth">REMOTE_USER</span> is a special case, suggested
- for use with <span class="fixedwidth">eduPersonPrincipalName</span>, and
- is automatically checked by a <span class="fixedwidth">require
- user</span> rule.</p>
- </dd>
- </dl>
-
- </li>
-
- <li>
- <a name="3.c.2."></a>
-
- <p>These modifications must be made to the Apache startup
- script:</p>
-
- <p>Add the following environment variables:</p>
-
- <blockquote>
- <span class="fixedwidth">
- SHIBCONFIG=/opt/shibboleth/etc/shibboleth/shibboleth.ini;
- export SHIBCONFIG</span>
- </blockquote>
-
- <p>If the OpenSSL libraries are not in the system's search
- path, they should be added to <span class="fixedwidth">LD_LIBRARY_PATH</span> as
- well.</p>
-
- <p>If the SHIBCONFIG environment variable is not
- specified, Shibboleth will use
- <span class="fixedwidth">/opt/shibboleth/etc/shibboleth/shibboleth.ini</span> by
- default.</p>
- </li>
-
- <li>
- <p>The SHAR must be started before Apache. Among other
- methods, this can be done either by creating a separate
- SHAR startup script or by modifying Apache's RC script to
- start/stop the <span class="fixedwidth">SHAR</span> <b>before</b>
- <span class="fixedwidth">httpd</span>. It is suggested that Apache's script be
- modified by adding:</p>
-
- <blockquote>
- <span class="fixedwidth">/opt/shibboleth/bin/shar -f &</span>
- </blockquote>
-
- <p>Sample <span class="fixedwidth">init.d</span> scripts may be included with
- future releases. Ensure that the environment variables
- referenced in <a href="#3.c.2">3.c.2</a> are in
- place.</p>
-
+ drwxr-xr-x 4 root root 4096 Oct 24 02:02 share</span></p>
+ </blockquote>
+ <p>On Windows, until a real installer is available, the zip file should
+ be unpacked beneath the root of the system drive, where it will create
+ an <span class="fixed">\opt\shibboleth</span> tree that resembles the
+ Unix layout above. This will allow the standard configuration options to
+ work. <b>The <span class="fixed">C:\opt\shibboleth\lib</span> directory
+ MUST be added to the system path to enable proper operation.</b> </li>
+ </ol>
+</blockquote>
+<h4><a name="3.c."></a>3.c. Configure Apache 1.3.x</h4>
+<blockquote>
+ <ol type="1">
+ <li>Shibboleth includes configuration directives in the file
+ <span class="fixed">/opt/shibboleth/etc/shibboleth/apache.config</span>
+ which must be added to the httpd.conf file used locally. It is
+ recommended that these directives simply be added to the end of the
+ existing <span class="fixed">httpd.conf</span> file rather than trying
+ to merge it in-line; <a href="#3.c.2.">step 2</a> describes the
+ necessary modifications to the Apache startup script. The default
+ configuration will often work, but if customization is necessary, these
+ options may be modified:<dl>
+ <dd class="attribute"><span class="fixed">LoadModule <module>
+ <pathname></span> </dd>
+ <dd class="value">Specifies the title and location of the
+ <span class="fixed">shibrm_module</span> resource manager and
+ <span class="fixed">shire_module</span> SHIRE modules. These are
+ installed by default at <span class="fixed">/opt/shibboleth/libexec/mod_shibrm.so</span>
+ and <span class="fixed">/opt/shibboleth/libexec/mod_shire.so</span></dd>
+ <dd class="attribute"><span class="fixed">SHIREConfig <pathname></span>
+ </dd>
+ <dd class="value">Specifies the <span class="fixed">pathname</span>
+ of the SHIRE's configuration file. Defaults to <span class="fixed">
+ /opt/shibboleth/etc/shibboleth/shibboleth.ini</span>.</dd>
+ <dd class="attribute"><span class="fixed">SHIREURL <url><br>
+ <Location <url>><br>
+ SetHandler <method><br>
+ </Location></span></dd>
+ <dd class="value">Specifies the <span class="fixed">URL</span> and
+ the <span class="fixed">method</span> the target uses to handle
+ requests for Shibboleth-protected resources. Currently,
+ <span class="fixed">shib-shire-post</span> is the only available
+ handler <span class="fixed">method</span>. <span class="fixed">
+ SHIREURL</span> is used by Shibboleth when re-directing the user to
+ the WAYF and <span class="fixed"><Location></span> by Apache; for
+ this reason, both <span class="fixed">URL</span> specifications must
+ match. Note that the configuration file itself contains <>'s, and
+ <span class="fixed">Location</span> should not be replaced.<p>The
+ referenced <span class="fixed">URL</span> can be either a partial
+ path or an absolute URL. The partial path allows each virtual server
+ to use its own hostname and port in the SHIRE for session cookie
+ purposes, while the absolute URL forces HTTP virtual servers to use
+ HTTPS for the SHIRE. Use of a full <span class="fixed">https://</span>
+ URL is advised.</dd>
+ <dd class="attribute"><span class="fixed">ShibMapAttribute
+ <attribute-uri> <HTTP-header> [alias]</span> </dd>
+ <dd class="value"><b>This command has been deprecated in favor of
+ the configuration support available in the Attribute Acceptance
+ Policy file. See <a href="#4.e.">section 4.e.</a> It may be removed
+ in a future release.</b></dd>
+ </dl>
</li>
-
- <li>
- <p>The options in <span class="fixedwidth">shibboleth.ini</span> must be
- configured as documented in <a href="#4.a.">4.a</a>.
- Apache content will then need to be modified for
- Shibboleth authentication. This is discussed in <a href=
- "#4.d.">4.d</a>. It is recommended that the target then
- be tested as detailed in section <a href=
- "#5.a.">5.a</a>.</p>
+ <li><a name="3.c.2."></a>These modifications must be made to the Apache
+ startup script:<p>Add the following environment variable:</p>
+ <blockquote>
+ <p><span class="fixed">SHIBCONFIG=/opt/shibboleth/etc/shibboleth/shibboleth.ini<br>
+ export SHIBCONFIG</span></p>
+ </blockquote>
+ <p>If the OpenSSL libraries are not in the system's search path, they
+ should be added to <span class="fixed">LD_LIBRARY_PATH</span>. Generally
+ libtool's linker options will insure that the modules can locate the
+ Shibboleth libraries, but if not, you may need to add
+ <span class="fixed">/opt/shibboleth/lib</span> to <span class="fixed">
+ LD_LIBRARY_PATH</span> as well.</p>
+ <p>If the SHIBCONFIG environment variable is not specified, Shibboleth
+ will use <span class="fixed">/opt/shibboleth/etc/shibboleth/shibboleth.ini</span>
+ by default.</li>
+ <li>The SHAR must be started along with Apache. Among other methods on
+ Unix, this can be done either by creating a separate SHAR startup script
+ or by modifying Apache's RC script to start/stop the <span class="fixed">
+ SHAR</span> <b>before</b> <span class="fixed">httpd</span>. It is
+ suggested that Apache's script be modified by adding:<blockquote>
+ <p><span class="fixed">/opt/shibboleth/bin/shar -f &</span> </p>
+ </blockquote>
+ <p>Sample <span class="fixed">init.d</span> scripts may be included with
+ future releases. Ensure that the environment variable referenced in
+ <a href="#3.c.2">3.c.2</a> are in place.</li>
+ <li>By default, the Shibboleth modules are configured to log information
+ on behalf of Apache to the file <span class="fixed">
+ /opt/shibboleth/etc/shibboleth/shire.log</span>, though this can be
+ changed. For this log to be created, Apache must have permission to
+ write to this file, which may require that the file be manually created
+ and permissions assigned to whatever user Apache is configured to run
+ under. If the file does not appear when Apache runs with the modules
+ loaded, check for permission problems. </li>
+ <li>The options in <span class="fixed">shibboleth.ini</span> must be
+ configured as documented in <a href="#4.a.">4.a</a>. Apache content will
+ then need to be modified for Shibboleth authentication. This is
+ discussed in <a href="#4.d.">4.d</a>. It is recommended that the target
+ then be tested as detailed in section <a href="#5.a.">5.a</a>.</li>
+ </ol>
+</blockquote>
+<h4><a name="3.d."></a>3.d. Configure Microsoft IIS</h4>
+<blockquote>
+ <ol type="1">
+ <li>The package includes an ISAPI filter and bundled extension for SHIRE
+ POST processing in a single library, <span class="fixed">libexec\isapi_shib.dll</span>.
+ This filter is configured using commands in <span class="fixed">
+ C:\opt\shibboleth\etc\shibboleth\shibboleth.ini</span>. Make sure you've
+ added the library directory to the path as directed in <a href="#3.b.">
+ section 3.b.</a><p>Installing the extension into IIS is a two step
+ process:<ol type="1">
+ <li type="a">First, add the filter using the Internet Services
+ Manager MMC console. Right click on the machine icon on the left,
+ and edit the WWW Service master properties. On the "ISAPI Filters"
+ tab, add a new filter called Shibboleth and specify the DLL named
+ above. The priority should be High, and once the filter is loaded,
+ make sure it appears in the list <b>below</b> the "sspifilt" entry.
+ Restart IIS and make sure the filter shows up with a green arrow.
+ Check the Windows event log if it fails to load. The default
+ configuration options are sparse, but they should allow the filter
+ to at least initialize.</li>
+ <li type="a">Secondly, map a special file extension, such as
+ <span class="fixed">.shire</span>, to the ISAPI library so that
+ virtual URLs can be specified to invoke the SHIRE handler for each
+ web site. Right click on the machine icon on the left, and edit the
+ WWW Service master properties. On the "Home Directory" tab, add a
+ script mapping using the "Configuration" button. The "Executable"
+ box should point to the filter/extension library, and the
+ "Extension" can be set to anything unlike to conflict, but
+ <span class="fixed">.shire</span> is assumed (and the dot must be
+ included). You should select the option to limit verbs to POST, and
+ you must uncheck the "Check that file exists" box.</li>
+ </ol>
</li>
- </ol>
- </blockquote>
- <br>
- <hr>
- <br>
-
-
- <h3><a name="4."></a>4. Getting Running</h3>
-
- <h4><a name="4.a."></a>4.a. Configuring
- <span class="fixedwidth">shibboleth.ini</span></h4>
-
- <blockquote>
- <p>Most of the configuration for the SHAR, SHIRE, and RM is stored
- in the file <span class="fixedwidth">shibboleth.ini</span>. This
- file is split into several pre-defined sections. The first
- sections, <span class="fixedwidth">general</span>, <span
- class="fixedwidth">shire</span>, and <span
- class="fixedwidth">shar</span>, define the operational parameters
- for the <span class="fixedwidth">SHIRE</span> and <span
- class="fixedwidth">SHAR</span>. The <span
- class="fixedwidth">general</span> section holds global tags, used
- by all pieces. The <span class="fixedwidth">shire</span> and <span
- class="fixedwidth">shar</span> sections can override the <span
- class="fixedwidth">general</span> tags with SHIRE- or
- SHAR-specific configuration. For example, if the SHAR is looking
- for a tag, it will look first in the <span
- class="fixedwidth">shar</span> section; if it does not find the
- tag there, it will proceed to look in the <span
- class="fixedwidth">general</span> section. The following
- sections, <span class="fixedwidth">metadata_shire</span>, <span
- class="fixedwidth">metadata_shar</span>, <span
- class="fixedwidth">attributes</span>, and <span
- class="fixedwidth">policies</span>, define the trust framework
- within the SHIRE and SHAR operate. Example configuration files
- are bundled with the Shibboleth distribution.</p>
-
- <p>There is also information that must be configured in
- <span class="fixedwidth">/usr/local/apache/conf/httpd.conf</span>; for more
- information, refer to <a href="#3.c.2.">3.c</a>.</p>
-
- <p>Information in the logger files referenced by
- <span class="fixedwidth">shibboleth.ini</span> may require additional configuration.
- It is recommended that after initial installation is
- completed, the log level in both files be changed to either
- <span class="fixedwidth">INFO</span> or <span class="fixedwidth">WARN</span>.</p>
-
- <p>Fields that are purple are optional; grey fields are
- mandatory.</p>
-
- <p><span class="fixedwidth">[general]</span>:</p>
-
- <dl>
- <dd class="attribute">
- <span class="fixedwidth">logger = <pathname></span>
- </dd>
-
- <dd class="value">
- <p>Specifies the location of the <span class="fixedwidth">log4cpp</span>
- configuration file for most Shibboleth events. This
- element may also be optionally specified for each of
- the components individually. Default logging settings (using local log files)
- should suffice. If using a remote syslogd instead, the <span class="fixedwidth">syslog</span>
- daemon must accept <span class="fixedwidth">UDP:514</span> messages, and on Linux,
- <span class="fixedwidth">SYSLOGD_OPTIONS</span> must include <span class="fixedwidth">-r</span>
- to <span class="fixedwidth">enable logging from remote machines.</span> The
- logging level is also defined in the logger configuration.
- The configuration format and log levels are similar to that of the
- <a href="http://jakarta.apache.org/log4j/docs/documentation.html">Log4j</a> package's
- property format.</p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">schemadir = <pathname></span>
- </dd>
-
- <dd class="value">
- <p>Specifies the directory in which the XML schema
- files are located; defaults to
- <span class="fixedwidth">/opt/shibboleth/etc/shibboleth/</span>.</p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">sharsocket = <pathname></span>
- </dd>
-
- <dd class="value">
- <p>Specifies the location of the socket the SHAR uses to
- form connections. Note that if you change this, the SHAR and Apache
- should both be restarted immediately, since new Apache child processes will
- use the changed value as soon as they start up.</p>
- </dd>
- </dl>
-
- <p>The next segment of the <span class="fixedwidth">[general]</span> configuration
- section defines server-specific tags in sections defined by
- the server name for use by the SHIRE and RM. For example, if
- you have a web server at www.example.edu, you can define a
- section <span class="fixedwidth">[www.example.edu]</span> and override global tags
- with tags for that server only.</p>
-
- <p>The following table lists the server-specific tags. It is
- broken into mandatory tags, and optional tags. Tags in the <span
- class="fixedwidth">[general]</span> section correspond to all
- servers; to override specific tags on a per-server basis, use
- <span class="fixedwidth">[<FQDN>]</span> as the header for a
- section.</p>
-
- <span class="fixedwidth">[<general>]</span>:
-
- <dl>
-
- <dd class="attributeopt">
- <span class="fixedwidth">normalizeRequest = <true/false></span>
- </dd>
-
- <dd class="valueopt">
- <p>If true, all redirects generated by
- <span class="fixedwidth">mod_shire</span> will be created using the virtual
- server name assigned to the server containing this
- command. If <span class="fixedwidth">false</span>, the browser's supplied
- URL is used to compute the redirect back.</p>
- </dd>
-
- <dd class="attributeopt">
- <span class="fixedwidth">checkIPAddress = <true/false></span>
- </dd>
-
- <dd class="valueopt">
- <p>If <span class="fixedwidth">true</span>, Shibboleth will check client
- addresses for impersonation protection. In most
- circumstances, this should be enabled to prevent
- certain attacks concerning stolen cookies. Defaults
- to <span class="fixedwidth">false</span>.</p>
- </dd>
-
- <dd class="attributeopt">
- <span class="fixedwidth">supportContact = <e-mail></span>
- </dd>
-
- <dd class="valueopt">
- <p>Specifies the e-mail address used in the
- generation of error pages.</p>
- </dd>
-
- <dd class="attributeopt">
- <span class="fixedwidth">logoLocation = <pathname></span>
- </dd>
-
- <dd class="valueopt">
- <p>Specifies the location of the logo used in the
- generation of error pages. This logo can be in any
- format that the web browser will understand.</p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">wayfURL = <url></span>
- </dd>
-
- <dd class="value">
- <p>Specifies the URL of the WAYF service the user is
- redirected to. Federations will generally provide this URL
- or provide information on how to locally host WAYF's with
- a distributed hosts file.</p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">cookieName = <string></span>
- </dd>
-
- <dd class="value">
- <p>Defines the name to be used for session cookies.</p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">shireSSLOnly = <true/false></span>
- </dd>
-
- <dd class="value">
- <p>If <span class="fixedwidth">true</span>, the SHIRE will reject HTTP
- connections that are not SSL-protected. This guards the initial session
- sign-on from the browser, but does not preclude non-SSL content. Use of
- SSL is strongly recommended; see section <a href=
- "#2.c.">2.c</a> for more information.</p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">shireError = <pathname></span>
- </dd>
-
- <dd class="value">
- <p>Specifies the location of the template for the
- error page generated when there is an error
- re-directing the user to the WAYF or processing a
- SHIRE POST.</p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">rmError = <pathname></span>
- </dd>
-
- <dd class="value">
- <p>Specifies the location of the template for the
- error page generated if internal errors occur in the
- RM.</p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">accessError = <pathname></span>
- </dd>
-
- <dd class="value">
- <p>Specifies the location of the template for the
- page displayed to users when access to a protected
- resource is denied by the RM.</p>
- </dd>
- </dl>
-
- <span class="fixedwidth">[shire]</span>:
-
- <dl>
- <dd class="attribute">
- <span class="fixedwidth">logger = <pathname></span>
- </dd>
-
- <dd class="value">
- <p>Specifies the location of the <span class="fixedwidth">log4cpp</span>
- configuration file for most Shibboleth events. This
- element may also be optionally specified for each of
- the components individually. Default logging settings (using local log files)
- should suffice. If using a remote syslogd instead, the <span class="fixedwidth">syslog</span>
- daemon must accept <span class="fixedwidth">UDP:514</span> messages, and on Linux,
- <span class="fixedwidth">SYSLOGD_OPTIONS</span> must include <span class="fixedwidth">-r</span>
- to <span class="fixedwidth">enable logging from remote machines.</span> The
- logging level is also defined in the logger configuration.
- The configuration format and log levels are similar to that of the
- <a href="http://jakarta.apache.org/log4j/docs/documentation.html">Log4j</a> package's
- property format.</p>
- </dd>
-
- <dd class="attributeopt">
- <span class="fixedwidth">aap-uri = <uri></span>
- </dd>
-
- <dd class="valueopt">
- <p>Specifies the URI of an attribute acceptance policy XML
- file. Attributes must be listed in the <span
- class="fixedwidth">aap-uri</span> file if they are to be
- visible to the Apache server. Unlisted or rejected attributes are
- filtered out and hidden from the web server (but also see the
- <b>ShibExportAssertion</b> Apache command).
- For more information, refer to section <a href="#4.e.">4.e</a>.</p>
- </dd>
-
- <dd class="attributeopt">
- <span class="fixedwidth">metadata = <tag></span>
- </dd>
-
- <dd class="valueopt">
- <p>Specifies the tag that defines the section of <span
- class="fixedwidth">shibboleth.ini</span> the SHIRE should
- use to acquire its metadata. The SHIRE does not need trust
- metadata, and so generally it will only need sites data to
- enforce attribute policies like scope limitations(e.g. MIT
- not asserting @brown.edu attributes.)</p>
- </dd>
- </dl>
-
- <span class="fixedwidth">[shar]</span>:
- <dl>
-
- <dd class="attribute">
- <span class="fixedwidth">logger = <pathname></span>
- </dd>
-
- <dd class="value">
- <p>Specifies the location of the <span class="fixedwidth">log4cpp</span>
- configuration file for most Shibboleth events. This
- element may also be optionally specified for each of
- the components individually. Default logging settings (using local log files)
- should suffice. If using a remote syslogd instead, the <span class="fixedwidth">syslog</span>
- daemon must accept <span class="fixedwidth">UDP:514</span> messages, and on Linux,
- <span class="fixedwidth">SYSLOGD_OPTIONS</span> must include <span class="fixedwidth">-r</span>
- to <span class="fixedwidth">enable logging from remote machines.</span> The
- logging level is also defined in the logger configuration.
- The configuration format and log levels are similar to that of the
- <a href="http://jakarta.apache.org/log4j/docs/documentation.html">Log4j</a> package's
- property format.</p>
- </dd>
-
- <dd class="attributeopt">
- <span class="fixedwidth">metadata = <tag></span>
- </dd>
-
- <dd class="valueopt">
- <p>Specifies the tag that defines the section of <span
- class="fixedwidth">shibboleth.ini</span> the SHAR should
- use to acquire its site and trust metadata.</p>
- </dd>
-
- <dd class="attributeopt">
- <span class="fixedwidth">certFile = <pathname></span>
- </dd>
-
- <dd class="valueopt">
- <p>Specifies the location of the PEM-format certificate used by
- the SHAR to communicate in authenticated fashion with
- origin site Attribute Authorities.</p>
- </dd>
-
- <dd class="attributeopt">
- <span class="fixedwidth">keyFile = <pathname></span>
- </dd>
-
- <dd class="valueopt">
- <p>Specifies the location of the PEM-format private key used by
- the SHAR to communicate in authenticated fashion with
- origin site Attribute Authorities.</p>
- </dd>
-
- <dd class="attributeopt">
- <span class="fixedwidth">keyPass = <password></span>
- </dd>
-
- <dd class="valueopt">
- <p>Specifies the <span class="fixedwidth">password</span> used to access the
- <span class="fixedwidth">keyFile</span>, if any.</p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">calist = <pathname></span>
- </dd>
-
- <dd class="value">
- <p>Specifies a single file of PEM-format certificates containing
- the root CAs the SHAR will consider to be valid signers of AA server
- certificates. Currently applies globally to all communication with AAs.</p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">AATimeout = <seconds></span>
- </dd>
-
- <dd class="value">
- <p>Specifies the number of seconds that the SHAR will wait
- for attributes to be sent from an AA. Defaults to <span
- class="fixedwidth">60</span>.</p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">AAConnectTimeout = <seconds></span>
- </dd>
-
- <dd class="value">
- <p>Specifies the number of seconds that the SHAR will wait
- for a connection to be established with an AA.
- Defaults to <span class="fixedwidth">30</span>.</p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">cacheType = <method></span>
- </dd>
-
- <dd class="value">
- <p>Specifies the method used by the SHAR to cache received
- attributes. The default is <span
- class="fixedwidth">memory</span>, which indicates that
- the SHAR should store received attributes in its memory.
- Another option is <span class="fixedwidth">mysql</span>,
- which will use the MySQL Credential Cache. The steps to using this are described
- in the MySQL Credential Cache guide.</p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">cacheClean = <seconds></span>
- </dd>
-
- <dd class="value">
- <p>Specifies the duration in seconds between cleanups of
- the SHAR's cached but expired attributes. Defaults to <span
- class="fixedwidth">300</span>, or 5 minutes.</p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">cacheTimeout = <seconds></span>
- </dd>
-
- <dd class="value">
- <p>Specifies the duration in <span
- class="fixedwidth">seconds</span> that must elapse
- between user accesses before that user's session is
- destroyed, including the associated handle and all
- cached attributes. Defaults to <span
- class="fixedwidth">28800</span> seconds, or 8 hours.</p>
- </dd>
- </dl>
-
- <p><span class="fixedwidth">[metadata]</span> sections must be
- created and named in accordance with the value of the <span
- class="fixedwidth">metadata</span> parameter in the <span
- class="fixedwidth">[shire]</span> and <span
- class="fixedwidth">[shar]</span> sections. Metadata sections may
- be shared or defined for each component. Two providers are
- supported by Shibboleth, but additional providers may be
- specified with name/value pairs consisting of <span
- class="fixedwidth"><metadata provider type>=<source></span>.</p>
-
- <p><span class="fixedwidth">[<metadata>]</span>:</p>
-
- <dl>
- <dd class="attributelong">
- <span class="fixedwidth">edu.internet2.middleware.shibboleth.metadata.XML = <pathname></span>
- </dd>
-
- <dd class="value">
- <p>Specifies the location of the file to load site
- metadata from. This will often be a <span
- class="fixedwidth">sites.xml</span> file stored locally,
- and may be used by both the SHIRE and SHAR.</p>
-
- <p>Shibboleth provides a simple utility called <span
- class="fixedwidth">siterefresh</span> for updating the
- metadata file as described in section <a
- href="#4.g.">4.g</a>.</p>
- </dd>
-
- <dd class="attributelong">
- <span class="fixedwidth">edu.internet2.middleware.shibboleth.trust.XML = <pathname></span>
- </dd>
-
- <dd class="value">
- <p>Specifies the location of the trust database of
- certificates and/or CA roots used by the SHAR during
- session initiation. The SHIRE module generally does not need trust
- data.</p>
- </dd>
- </dl>
-
- <p>In order for an attribute to be used by Shibboleth, it must be
- recognized as valid by the SHAR and implemented with any specific
- rules for how to understand and express its value based on the XML
- from the AA. Additional string-valued attributes may be added to
- the SHAR using the <span class="fixedwidth">[attributes]</span>
- section.</p>
-
- <p><span class="fixedwidth">[attributes]</span>:</p>
-
- <dl>
- <dd class="attribute">
- <span class="fixedwidth"><attribute_URI>=<type></span>
- </dd>
-
- <dd class="value">
- <p>Attribute names are URI's that are assigned by the
- parties standardizing the attribute. Frequently, a
- federation or standard object class may define these URI's.
- The attribute type may be either <span
- class="fixedwidth">scoped</span> or <span
- class="fixedwidth">simple</span>, which defines how
- the attribute is processed as described in section <a
- href="#4.e.">4.e</a>.</p>
- </dd>
- </dl>
-
- <p>The <span class="fixedwidth">[policies]</span> section contains the policy URI
- values that control acceptance of assertions from origin
- sites. This may eventually have multiple elements associated
- it for targets that are members of multiple federations.</p>
-
- <p><span class="fixedwidth">[policies]</span>:</p>
-
- <dl>
- <dd class="attribute">
- <span class="fixedwidth"><federation> = <URI></span>
- </dd>
-
- <dd class="value">
- <p>The name of the <span
- class="fixedwidth">federation</span> and its
- associated policy <span class="fixedwidth">URI</span>.
- These URI's will be provided by federations.</p>
-
- <p>This set of URI values is matched against the SAML
- <span class="fixedwidth">Audience</span> fields of
- assertions received from HS's and AA's. One of the
- URI's specified by the origin in <span
- class="fixedwidth">edu.internet2.middleware.shibboleth.audiences</span>
- must match one of these URIs or the
- assertion will not be accepted by design.</p>
- </dd>
- </dl>
-
- <p>Additional sections for individual servers may be defined with
- either parameters overriding those found in <span
- class="fixedwidth">[general]</span>, or the following additional
- parameters:</p>
-
- <p><span class="fixedwidth">[<FQDN>]</span>:</p>
-
- <dl>
- <dd class="attributeopt">
- <span class="fixedwidth">requestAttributes = <attr1> <attr2>
- <attr3>...</span>
- </dd>
-
- <dd class="valueopt">
- <p>Specifies a space-delimited list of attributes named by
- URI that the SHAR will request of an AA. If the parameter
- does not exist or is null, then the SHAR will receive all
- attributes the AA is willing to release to it.</p>
- </dd>
- </dl>
-
- </blockquote>
-
- <h4><a name="4.b."></a>4.b. Dynamic Error Page Generation</h4>
-
+ <li>All other aspects of configuration are handled via the
+ <span class="fixed">shibboleth.ini</span> file and associated XML-based
+ policy files described in subsequent sections. Particular use is made of
+ the per-hostname section feature that allows global settings to be
+ overridden per-site, and this permits different IIS instances to be
+ separately configured.</li>
+ <li>A special section must be added/uncommented in the
+ <span class="fixed">shibboleth.ini</span> file to support IIS usage. The
+ <span class="fixed">[isapi]</span> section must be used to map IIS
+ Instance ID numbers to fully-qualified hostnames that correspond to
+ named sections later in the file. Instance IDs are used in the IIS
+ metabase to identify web sites. They are applied starting with the
+ number 1 and number the web sites in order in the Internet Services
+ Manager from top to bottom. In the <span class="fixed">[isapi]</span>
+ section, add lines in the following form:
+ <blockquote class="fixed">
+ <p>1=hostname.domain.com<br>
+ 2=hostname2.domain.com<br>
+ (etc...)</p>
+ </blockquote>
+ <p>At least an empty configuration section named <span class="fixed">
+ hostname.domain.com</span> should then be added to the end of the file.
+ Any options specific to that web site can be added as documented in
+ later sections.</li>
+ <li>See the following section for information on running the SHAR
+ service on Windows.</li>
+ <li>The options in <span class="fixed">shibboleth.ini</span> must be
+ configured as documented in <a href="#4.a.">4.a</a>. It is recommended
+ that the target then be tested as detailed in section <a href="#5.a.">
+ 5.a</a>.</li>
+ </ol>
+</blockquote>
+<h4><a name="3.e."></a>3.e. Running the SHAR on Windows</h4>
+<blockquote>
+ <p>The SHAR is a console application that is primarily designed to be
+ installed as a Windows service. To run the process in console mode for
+ testing, the <span class="fixed">-console</span> parameter is used.
+ Otherwise, parameters are used to install (or remove) the SHAR from the
+ service database and subsequent control is via the Service Control Manager
+ applet. The following command line parameters can be used:</p>
+ <dl>
+ <dd class="attribute"><span class="fixed">-console</span></dd>
+ <dd class="value">Allows the process to be started from a command
+ prompt. Since the console will exit if the desktop user logs out, this
+ is not suitable for production use, but may be useful for testing.</dd>
+ <dd class="attribute"><span class="fixed">-config <pathname></span> </dd>
+ <dd class="value">Specifies the pathname of the SHAR's configuration
+ file. Defaults to <span class="fixed">\opt\shibboleth\etc\shibboleth\shibboleth.ini</span>
+ or the value of the <span class="fixed">SHIBCONFIG</span> environment
+ variable, if it is set.</dd>
+ <dd class="attribute"><span class="fixed">-install <servicename></span></dd>
+ <dd class="value">Installs the SHAR as a named service in the Windows
+ service database. A name should be provided if multiple instances of the
+ SHAR need to be run on different ports, and thus installed separately.
+ The <span class="fixed">-config</span> option can be provided to include
+ a specific configuration file on the service's command line.</dd>
+ <dd class="attribute"><span class="fixed">-remove <servicename></span></dd>
+ <dd class="value">Removes the named service instance of the SHAR from
+ the Windows service database.</dd>
+ </dl>
+ <h4><br>
+ </h4>
+</blockquote>
+<hr>
+<h3><a name="4."></a>4. Getting Running</h3>
+<h4><a name="4.a."></a>4.a. Configuring <span class="fixed">shibboleth.ini</span></h4>
+<blockquote>
+ <p>Most of the configuration for the SHAR, SHIRE, and RM is stored in the
+ file <span class="fixed">shibboleth.ini</span>. This file is split into
+ several pre-defined sections. The first sections, <span class="fixed">
+ [general]</span>, <span class="fixed">[shire]</span>, and
+ <span class="fixed">[shar]</span>, define the operational parameters for the
+ <span class="fixed">SHIRE</span> and <span class="fixed">SHAR</span>. While
+ not precisely accurate, the <span class="fixed">[shire]</span> section is
+ generally associated with the web server modules and libraries that
+ applications interface with, while the <span class="fixed">[shar]</span>
+ section is associated with the separate SHAR process. The
+ <span class="fixed">[general]</span> section holds global settings, used by
+ all components. The <span class="fixed">[shire]</span> and
+ <span class="fixed">[shar]</span> sections can override the
+ <span class="fixed">[general]</span> tags with SHIRE- or SHAR-specific
+ configuration. For example, if the SHAR is looking for a tag, it will look
+ first in the <span class="fixed">shar</span> section; if it does not find
+ the tag there, it will proceed to look in the <span class="fixed">general</span>
+ section.</p>
+ <p>The following sections, <span class="fixed">[metadata_shire]</span>,
+ <span class="fixed">[metadata_shar]</span>, and <span class="fixed">
+ [policies]</span>, define the trust framework within which the entire system
+ operates. Example configuration files are bundled with the Shibboleth
+ distribution, currently derived from the InQueue staging federation managed
+ by Internet2</p>
+ <p>For Apache (but not IIS), there is also information that must be
+ configured in <span class="fixed">/usr/local/apache/conf/httpd.conf</span>
+ (or equivalent); for more information, refer to <a href="#3.c.2.">3.c</a>.</p>
+ <p>Information in the logging configuration files referenced by
+ <span class="fixed">shibboleth.ini</span> may require additional changes to
+ meet local needs. The logging level can be raised to <span class="fixed">
+ INFO</span> or <span class="fixed">DEBUG</span> if additional detail is
+ needed for testing. It is recommended that after initial installation is
+ completed, the log level in both files be left at either <span class="fixed">
+ INFO</span> or <span class="fixed">WARN</span>.</p>
+ <p>Fields that are purple are optional; grey fields are mandatory. If the
+ option only applies to a specific environment, such as IIS/ISAPI only, then
+ this is indicated.</p>
+ <p><span class="fixed">[general]</span>:</p>
+ <dl>
+ <dd class="attribute"><span class="fixed">logger = <pathname></span></dd>
+ <dd class="value">Specifies the location of the <span class="fixed">
+ log4cpp</span> configuration file for most Shibboleth events. This
+ element may also be optionally specified for each of the components
+ individually (which is the default provided, so this setting is often
+ unused). Default logging settings (using local log files) should
+ suffice. If using a remote syslogd instead, the <span class="fixed">
+ syslog</span> daemon must accept <span class="fixed">UDP:514</span>
+ messages, and on Linux, <span class="fixed">SYSLOGD_OPTIONS</span> must
+ include <span class="fixed">-r</span> to enable logging from remote
+ machines. The logging level is also defined in the logger configuration
+ file. The configuration format and log levels are similar to that of the
+ <a href="http://jakarta.apache.org/log4j/docs/documentation.html">Log4j</a>
+ package's property format.</dd>
+ <dd class="attribute"><span class="fixed">schemadir = <pathname></span></dd>
+ <dd class="value">Specifies the directory in which the XML schema files
+ are located; defaults to <span class="fixed">
+ /opt/shibboleth/etc/shibboleth/</span>. This should generally be left
+ alone, unless a non-default installation path is used.</dd>
+ <dd class="attribute"><span class="fixed">sharsocket = <pathname> | [IP
+ interface:]port</span></dd>
+ <dd class="value">Specifies the location of the socket the SHAR uses to
+ form connections. Note that if you change this, the SHAR and Apache
+ should both be restarted immediately, since new Apache child processes
+ will use the changed value as soon as they start up.
+ <p>On Unix, this is usually set to a domain socket path, often something
+ in <span class="fixed">/tmp</span>. On Windows, this must be either a
+ TCP port number, or a combination of an IP address and port, with a
+ colon in between. Using an address specifies an IP interface to bind to
+ on multi-homed servers. Using just a port number generally suffices. If
+ this syntax is used on Unix, then the process will use a TCP socket
+ instead of a domain socket. </p>
+ <p><b>Security Note:</b> Using TCP, which is mandatory on Windows, can
+ be insecure if used in certain non-default configurations. If you allow
+ access to the service from other hosts, be sure a firewall is in place
+ to prevent unauthorized access. The <span class="fixed">sharacl</span>
+ setting, described later, provides some minimal filtering, but TCP is
+ still an insecure protocol.</dd>
+ </dl>
+ <p>The rest of the <span class="fixed">[general]</span> configuration
+ section defines global settings that can be overridden by server-specific
+ tags in sections defined by the server name. This is especially applicable
+ for non-Apache configurations. For example, if you have a web server named
+ www.example.edu, you can define a section <span class="fixed">[www.example.edu]</span>
+ and override global tags with tags for that server only.</p>
+ <p>The following table lists the server-specific tags. It is broken into
+ mandatory tags, and optional tags. Tags in the <span class="fixed">[general]</span>
+ section correspond to all servers; to override specific tags on a per-server
+ basis, use <span class="fixed">[<FQDN>]</span> as the header for a section (FQDN
+ means fully-qualified domain name, and corresponds to the name you assign to
+ a virtual host using the Apache ServerName directive, or that you map IIS
+ instance IDs to using the <span class="fixed">[isapi]</span> section.</p>
+ <p><span class="fixed">[<general>]</span>:</p>
+ <dl>
+ <dd class="attribute"><span class="fixed">wayfURL = <absolute url></span></dd>
+ <dd class="value">Specifies the URL of the WAYF service the user is
+ redirected to. Federations will often provide this URL in order to
+ control the way in which sites are presented to users, but a target may
+ provide this function, or it may be set directly to a specific site's
+ Handle Service, effectively rendering the system internal to a single
+ origin site.</dd>
+ <dd class="attribute"><span class="fixed">shireURL = <absolute or
+ relative url></span> ISAPI</dd>
+ <dd class="value">Specifies the URL of the SHIRE POST URL, or assertion
+ consumer service, at which new sessions are initiated. This can be an
+ absolute URL, or a relative path to be prefixed by the base URL of the
+ web site. Using an absolute URL allows a virtual server to funnel SHIRE
+ requests to a fixed location, such as in the case where a non-SSL site
+ wants to handle SHIRE requests over SSL (on a different port).
+ <p>Note that this URL will result in a cookie being set, and this cookie
+ must be returned in subsequent requests, so the virtual server's domain
+ name and port must be consistent with the SHIRE's domain name and port
+ for some browsers to properly return the cookie. If default ports are
+ used (and thus left unspecified), browsers will generally return cookies
+ set via SSL to a non-SSL server. If non-default ports are used, it is
+ recommended that this be a relative URL so that each virtual host
+ handles its own cookie operations.</p>
+ <p>For Shibboleth to function in IIS, the file extension at the end of
+ this URL must match the value configured into IIS and mapped to the
+ ISAPI extension. This causes the request to be serviced properly, even
+ though no file by that name actually exists.</dd>
+ <dd class="attribute"><span class="fixed">cookieName = <string></span></dd>
+ <dd class="value">Defines the name to be assigned to in-memory session
+ cookies.</dd>
+ <dd class="attribute"><span class="fixed">shireError = <pathname></span></dd>
+ <dd class="value">Specifies the location of the template for the error
+ page generated when there is an error re-directing the user to the WAYF
+ or processing a new session sign-on.</dd>
+ <dd class="attribute"><span class="fixed">rmError = <pathname></span></dd>
+ <dd class="value">Specifies the location of the template for the error
+ page generated if internal errors occur in the RM.</dd>
+ <dd class="attribute"><span class="fixed">accessError = <pathname></span></dd>
+ <dd class="value">Specifies the location of the template for the page
+ displayed to users when access to a protected resource is denied by the
+ RM. This is distinct from when errors occur during the evaluation
+ process itself, and indicates a denial of authorization.</dd>
+ <dd class="attributeopt"><span class="fixed">normalizeRequest = <true|false></span></dd>
+ <dd class="valueopt">If true, all redirects and computed request URLs
+ generated by Shibboleth will be created using the virtual server name
+ assigned to the server. If <span class="fixed">false</span>, the
+ browser's supplied URL is sometimes used to compute the information.
+ This sometimes has no effect, depending on the capabilities of the web
+ server, since the correct behavior is almost always to rely on the
+ server's API to report the hostname and ignore the browser.</dd>
+ <dd class="attributeopt"><span class="fixed">checkIPAddress = <true|false></span></dd>
+ <dd class="valueopt">If <span class="fixed">true</span>, Shibboleth will
+ check client addresses for impersonation protection. In most
+ circumstances, this should be enabled to prevent certain attacks
+ concerning stolen cookies, but this can cause problems for users behind
+ proxies or NAT devices. Defaults to <span class="fixed">false</span>.</dd>
+ <dd class="attributeopt"><span class="fixed">shireSSLOnly = <true/false></span></dd>
+ <dd class="valueopt">If <span class="fixed">true</span>, the SHIRE will
+ reject HTTP connections for new session sign-on that are not SSL-protected.
+ This guards the initial session sign-on from the browser, but does not
+ preclude non-SSL content. Use of SSL is strongly recommended; see
+ section <a href="#2.c.">2.c</a> for more information.</dd>
+ <dd class="attributeopt"><span class="fixed">mustContain =
+ <string1>;<string2></span> ISAPI</dd>
+ <dd class="valueopt">Controls what content in IIS to protect with
+ Shibboleth. Multiple values should be separated with a semicolon. Each
+ string is matched directly against the requested URL, and if the URL
+ contains the string, a match is made and Shibboleth applies. No regular
+ expressions are supported, only literal matches. Slashes are matched
+ like other characters, so path components can be surrounded with slashes
+ to match any requests with a particular component in the path. Defaults
+ to protecting everything on a server or site.</dd>
+ <dd class="attributeopt"><span class="fixed">contentSSLOnly = <true|false></span>
+ ISAPI</dd>
+ <dd class="valueopt">If <span class="fixed">true</span>, Shibboleth will
+ insist that any request for protected content is over an SSL connection.
+ Defaults to <span class="fixed">false</span>.</dd>
+ <dd class="attributeopt"><span class="fixed">authLifetime = <seconds></span>
+ ISAPI</dd>
+ <dd class="valueopt">If set, sessions are always terminated after the
+ specified number of seconds, resulting in a new redirect and request for
+ authentication, just as if a new request without a session is received.
+ Defaults to infinite.</dd>
+ <dd class="attributeopt"><span class="fixed">authTimeout = <seconds></span>
+ ISAPI</dd>
+ <dd class="valueopt">If set, sessions are always terminated after the
+ specified number of seconds of inactivity (defined as no requests
+ received in that session), resulting in a new redirect and request for
+ authentication, just as if a new request without a session is received.
+ Defaults to infinite.</dd>
+ <dd class="attributeopt"><span class="fixed">requestAttributes = <attr1>
+ <attr2> <attr3>...</span> </dd>
+ <dd class="valueopt">Specifies a space-delimited list of attributes
+ (named by a designated URI) that the SHAR will request when querying for
+ attributes. By default, the SHAR will ask for and receive all attributes
+ the AA is willing to release to it.</dd>
+ <dd class="attributeopt"><span class="fixed">exportAssertion = <true|false></span>
+ ISAPI</dd>
+ <dd class="valueopt">If set, the SAML attribute assertion received by
+ the SHAR is exported to a CGI request header called Shib-Attributes,
+ encoded in base64. Defaults to <span class="fixed">false</span>. While
+ this does require parsing the raw XML, it also permits an application to
+ see attributes that may have been filtered by an AAP, or to forward the
+ SAML assertion to a third party.</dd>
+ <dd class="attributeopt"><span class="fixed">supportContact = <e-mail></span></dd>
+ <dd class="valueopt">Specifies the local site's support e-mail address,
+ and is used in the generation of error pages.</dd>
+ <dd class="attributeopt"><span class="fixed">logoLocation = <pathname></span></dd>
+ <dd class="valueopt">Specifies the location of the logo used in the
+ generation of error pages. This logo can be in any format that the web
+ browser will understand, and should be a URL (absolute or relative) that
+ will return a valid logo.</dd>
+ </dl>
+ <p><span class="fixed">[shire]</span>:</p>
+ <dl>
+ <dd class="attribute"><span class="fixed">metadata = <section tag></span></dd>
+ <dd class="value">Specifies the tag that defines the section of
+ <span class="fixed">shibboleth.ini</span> the SHIRE should use to
+ acquire its metadata. The SHIRE does not need trust metadata, and so
+ generally it will only need site metadata and attribute acceptance
+ policy to define attributes and enforce policies like scope
+ limitations(e.g. MIT not asserting attributes @brown.edu.)</dd>
+ <dd class="attributeopt"><span class="fixed">logger = <pathname></span></dd>
+ <dd class="valueopt">Specifies the location of the <span class="fixed">
+ log4cpp</span> configuration file for Shibboleth events produced by the
+ web server modules and libraries. Refer to the global setting for more
+ information.</dd>
+ <dd class="attributeopt"><span class="fixed">aap-uri = <uri></span>
+ DEPRECATED</dd>
+ <dd class="valueopt">Specifies the URI of an attribute acceptance policy
+ XML file. This command has been replaced with a new metadata provider
+ type for attribute policy that should be provided to both the SHIRE and
+ SHAR components. To replace this command, add lines to both metadata
+ sections of this form:
+ <blockquote class="fixed">
+ <p>edu.internet2.middleware.shibboleth.target.AAP.XML=<uri></p>
+ </blockquote>
+ <p>For more information, refer to section <a href="#4.e.">4.e</a>. This
+ command will be removed in future releases.</dd>
+ </dl>
+ <p><span class="fixed">[shar]</span>:</p>
+ <dl>
+ <dd class="attribute"><span class="fixed">metadata = <tag></span></dd>
+ <dd class="value">Specifies the tag that defines the section of
+ <span class="fixed">shibboleth.ini</span> the SHAR should use to acquire
+ its site, trust, and attribute metadata.</dd>
+ <dd class="attribute"><span class="fixed">cacheType = <method></span></dd>
+ <dd class="value">Specifies the method used by the SHAR to cache
+ sessions and attributes. The default is <span class="fixed">memory</span>,
+ which indicates that the SHAR should store received attributes in
+ memory. Another option is <span class="fixed">mysql</span>, which will
+ use the MySQL Credential Cache, if it is available.</dd>
+ <dd class="attribute"><span class="fixed">cacheClean = <seconds></span></dd>
+ <dd class="value">Specifies the duration in seconds between cleanups of
+ the SHAR's cached but expired sessions and attributes. Defaults to
+ <span class="fixed">300</span>, or 5 minutes.</dd>
+ <dd class="attribute"><span class="fixed">cacheTimeout = <seconds></span></dd>
+ <dd class="value">Specifies the duration in <span class="fixed">seconds</span>
+ that must elapse between user accesses before that user's session is
+ destroyed, including the associated handle and all cached attributes.
+ Defaults to <span class="fixed">28800</span> seconds, or 8 hours. This
+ should be longer than the associated server's settings for session
+ lifetime and timeout.</dd>
+ <dd class="attributeopt"><span class="fixed">logger = <pathname></span></dd>
+ <dd class="valueopt">Specifies the location of the <span class="fixed">
+ log4cpp</span> configuration file for Shibboleth events produced by the
+ SHAR service. Refer to the global setting for more information.</dd>
+ <dd class="attributeopt"><span class="fixed">sharacl = <IP Address></span></dd>
+ <dd class="valueopt">Specifies one or more space-delimited IP addresses
+ from which a TCP-based SHAR service will accept connections. Defaults to
+ 127.0.0.1 (localhost). Should only be changed if proper precautions have
+ been taken to protect connections from off-host.</dd>
+ <dd class="attributeopt"><span class="fixed">certFile = <pathname></span>
+ </dd>
+ <dd class="valueopt">Specifies the location of the PEM-format
+ certificate used by the SHAR to communicate in authenticated fashion
+ with origin site Attribute Authorities.</dd>
+ <dd class="attributeopt"><span class="fixed">keyFile = <pathname></span>
+ </dd>
+ <dd class="valueopt">Specifies the location of the PEM-format private
+ key used by the SHAR to communicate in authenticated fashion with origin
+ site Attribute Authorities.</dd>
+ <dd class="attributeopt"><span class="fixed">keyPass = <password></span>
+ </dd>
+ <dd class="valueopt">Specifies the <span class="fixed">password</span>
+ used to access the <span class="fixed">keyFile</span>, if any.</dd>
+ <dd class="attributeopt"><span class="fixed">calist = <pathname></span>
+ </dd>
+ <dd class="valueopt">Specifies a single file of PEM-format certificates
+ containing the root CAs the SHAR will consider to be valid signers of AA
+ server certificates. Currently applies globally to all communication
+ with AAs.</dd>
+ <dd class="attributeopt"><span class="fixed">AATimeout = <seconds></span>
+ </dd>
+ <dd class="valueopt">Specifies the number of seconds that the SHAR will
+ wait for attributes to be sent from an AA. Defaults to
+ <span class="fixed">60</span>.</dd>
+ <dd class="attributeopt"><span class="fixed">AAConnectTimeout =
+ <seconds></span> </dd>
+ <dd class="valueopt">Specifies the number of seconds that the SHAR will
+ wait for a connection to be established with an AA. Defaults to
+ <span class="fixed">30</span>.</dd>
+ </dl>
+ <p><span class="fixed">[metadata]</span> sections must be created and named
+ in accordance with the value of the <span class="fixed">metadata</span>
+ parameter in the <span class="fixed">[shire]</span> and <span class="fixed">
+ [shar]</span> sections. Metadata sections may be shared or defined for each
+ component. Three XML-based providers are supported by Shibboleth, but future
+ providers may be specified with name/value pairs consisting of
+ <span class="fixed"><metadata provider type>=<source></span>.</p>
+ <p>Note that any number of files of the three types may be loaded into the
+ system, which supports aggregating policy from across federations.</p>
+ <p>Shibboleth provides a simple utility called <span class="fixed">
+ siterefresh</span> for updating metadata files from a central location and
+ verifying a digital signature over them, as described in section
+ <a href="#4.g.">4.g</a>.</p>
+ <p><span class="fixed">[<metadata>]</span>:</p>
+ <dl>
+ <dd class="attribute"><span class="fixed">
+ edu.internet2.middleware.shibboleth.metadata.XML = <pathname></span></dd>
+ <dd class="value">Specifies the location of the file to load site
+ metadata from. This information controls what origin sites are trusted
+ by the target and provides contact information. This should be a file
+ stored locally, and may be used by both the SHIRE and SHAR.</dd>
+ <dd class="attribute"><span class="fixed">
+ edu.internet2.middleware.shibboleth.trust.XML = <pathname></span></dd>
+ <dd class="value">Specifies the location of the trust database of
+ certificates and/or CA roots used by the SHAR during session initiation
+ (but currently is not used during attribute exchange). The SHIRE
+ component generally does not need trust data.</dd>
+ <dd class="attribute"><span class="fixed">
+ edu.internet2.middleware.shibboleth.target.AAP.XML = <pathname></span></dd>
+ <dd class="value">Specifies the location of the Attribute Acceptance
+ Policy file that defines what attributes will be visible to
+ applications, how to filter their values based on the source, and how to
+ make them available to applications and the RM. See <a href="#4.e.">
+ section 4.e.</a> for detailed information on this file.<p><b>This
+ provider has been added as of version 1.0.1, and supersedes the old
+ <span class="fixed">aap-uri</span> and <span class="fixed">attributes</span>
+ settings, as well as the Apache <span class="fixed">ShibMapAttribute</span>
+ command.</b></dd>
+ </dl>
+ <p>The <span class="fixed">[policies]</span> section contains the policy URI
+ values that control acceptance of assertions from origin sites. This may
+ eventually have multiple elements associated it for targets that are members
+ of multiple federations.</p>
+ <p><span class="fixed">[policies]</span>:</p>
+ <dl>
+ <dd class="attribute"><span class="fixed"><federation> = <URI></span>
+ </dd>
+ <dd class="value">The name of the <span class="fixed">federation</span>
+ and its associated policy <span class="fixed">URI</span>. This
+ information should be provided by federations and is designed to support
+ future work in federation deployment. For the time being, it simply
+ insures that deployments not meant to interoperate will not do so.<p>
+ This set of URI values is matched against the SAML <span class="fixed">
+ Audience</span> fields of assertions received from HS's and AA's. One of
+ the URI's specified by the origin in the <span class="fixed">
+ edu.internet2.middleware.shibboleth.audiences</span> property must match
+ one of these URIs or the assertion will not be accepted by design.</dd>
+ </dl>
+</blockquote>
+<h4><a name="4.b."></a>4.b. Dynamic Error Page Generation</h4>
+<blockquote>
+ <p>Shibboleth supports the dynamic generation of information in error pages
+ referenced by <span class="fixed">shibboleth.ini</span>. The Shib Target
+ employs a special Markup Language Processor to insert special tags into the
+ generated HTML. The parser will read the error file looking for any tag that
+ looks like:</p>
<blockquote>
- <p>Shibboleth supports the dynamic generation of information
- in error pages referenced by <span class="fixedwidth">shibboleth.ini</span>. The
- Shib Target employs a special Markup Language Processor to
- insert special tags into the generated HTML. The parser will
- read the error file looking for any tag that looks like:</p>
-
- <blockquote>
- <span class="fixedwidth"><shibmlp tag-name /></span>
- </blockquote>
-
- <p>Shibboleth will replace <span class="fixedwidth">tag-name</span> with the
- appropriate markup tag from the table below:</p>
-
- <dl>
- <dd class="attribute"><span class="fixedwidth">supportContact</span></dd>
-
- <dd class="value">The value of the <span class="fixedwidth">supportContact</span> for this
- server.</dd>
-
- <dd class="attribute"><span class="fixedwidth">logoLocation</span></dd>
-
- <dd class="value">The value of the <span
- class="fixedwidth">logoLocation</span> for this server. This
- is used to fill in the template error page only; if a custom
- error page is created, then the image may be linked to
- statically by the page itself.</dd>
-
- <dd class="attribute"><span class="fixedwidth">requestURL</span></dd>
-
- <dd class="value">The user's requested URL.</dd>
-
- <dd class="attribute"><span class="fixedwidth">errorType</span></dd>
-
- <dd class="value">The type of error.</dd>
-
- <dd class="attribute"><span class="fixedwidth">errorText</span></dd>
-
- <dd class="value">The actual error message.</dd>
-
- <dd class="attribute"><span class="fixedwidth">errorDesc</span></dd>
-
- <dd class="value">A textual description of the error intended for human
- consumption.</dd>
-
- <dd class="attribute"><span class="fixedwidth">originContactName</span></dd>
-
- <dd class="value">The contact name for the origin site provided by that
- site's metadata.</dd>
-
- <dd class="attribute"><span class="fixedwidth">originContactEmail</span></dd>
-
- <dd class="value">The contact email address for the origin site provided by that
- site's metadata.</dd>
-
- <dd class="attribute"><span class="fixedwidth">originErrorURL</span></dd>
-
- <dd class="value">The URL of an error handling page for the origin site
- provided by that site's metadata.</dd>
- </dl>
-
- <p>This configuration is only for Apache servers, and is only
- used by resources protected by Shibboleth. See section <a
- href= "#4.d.">4.d</a>.</p>
-
- <p>Sample error templates for different kinds of errors are
- included in the Shibboleth distribution, and can be triggered
- by anything that will cause Shibboleth to be unable to make an
- authorization decision, including a bad sites file, certificate chain,
- or skewed clock.</p>
-
- <p><b>You should edit these templates, provide or remove style sheets and
- images, and otherwise customize these templates to suit the user experience
- you want your users to have when errors occur.</b></p>
-
+ <p><span class="fixed"><shibmlp tag-name /></span> </p>
</blockquote>
-
- <h4><a name="4.c."></a>4.c. Key Generation and Certificate
- Installation</h4>
-
+ <p>Shibboleth will replace <span class="fixed">tag-name</span> with the
+ appropriate markup tag from the table below:</p>
+ <dl>
+ <dd class="attribute"><span class="fixed">supportContact</span></dd>
+ <dd class="value">The value of the <span class="fixed">supportContact</span>
+ for this web site.</dd>
+ <dd class="attribute"><span class="fixed">logoLocation</span></dd>
+ <dd class="value">The value of the <span class="fixed">logoLocation</span>
+ for this web site. This is used to fill in the template error page only;
+ if a custom error page is created, then the image may be linked to
+ statically by the page itself.</dd>
+ <dd class="attribute"><span class="fixed">requestURL</span></dd>
+ <dd class="value">The user's requested URL.</dd>
+ <dd class="attribute"><span class="fixed">errorType</span></dd>
+ <dd class="value">The type of error.</dd>
+ <dd class="attribute"><span class="fixed">errorText</span></dd>
+ <dd class="value">The actual error message.</dd>
+ <dd class="attribute"><span class="fixed">errorDesc</span></dd>
+ <dd class="value">A textual description of the error intended for human
+ consumption.</dd>
+ <dd class="attribute"><span class="fixed">originContactName</span></dd>
+ <dd class="value">The contact name for the origin site provided by that
+ site's metadata.</dd>
+ <dd class="attribute"><span class="fixed">originContactEmail</span></dd>
+ <dd class="value">The contact email address for the origin site provided
+ by that site's metadata.</dd>
+ <dd class="attribute"><span class="fixed">originErrorURL</span></dd>
+ <dd class="value">The URL of an error handling page for the origin site
+ provided by that site's metadata.</dd>
+ </dl>
+ <p>This configuration is only for Apache servers, and is only used by
+ resources protected by Shibboleth. See <a href="#4.d.">section 4.d.</a></p>
+ <p>Sample error templates for different kinds of errors are included in the
+ Shibboleth distribution, and can be triggered by anything that will cause
+ Shibboleth to be unable to make an authorization decision, including a bad
+ sites file, certificate verification failures, or a skewed clock between
+ sites.</p>
+ <p><b>You should edit these templates, provide or remove style sheets and
+ images, and otherwise customize these templates to suit the user experience
+ you want your users to have when errors occur. The defaults are not likely
+ to meet the needs of any site.</b></p>
+</blockquote>
+<h4><a name="4.c."></a>4.c. Key Generation and Certificate Installation</h4>
+<blockquote>
+ <p>The only target component that must have a private key and certificate is
+ the SHAR. While the target server itself should support SSL in most cases
+ for users, it is mandatory for the SHAR to authenticate when contacting an
+ AA, and it must therefore be given a key and an SSL client certificate. It
+ is permissible for the SHAR to use the same keypair and certificate used by
+ the target server itself, provided the certificate is signed by a CA
+ accepted by the community of sites.</p>
+ <p>The certificate and key file location should be based on whether they
+ will also be used for Apache. If they will be used as a server certificate
+ as well, they should probably be in the Apache tree in the usual
+ <span class="fixed">mod_ssl</span>-defined locations inside the Apache
+ configuration folder., and the SHAR can read them from there. If the SHAR is
+ not running as <span class="fixed">root</span>, permissions might need to be
+ changed to allow this access. If the certificate and key will only be used
+ for the SHAR, they can be put in the same folder with the
+ <span class="fixed">shibboleth.ini</span> file and protected appropriately.</p>
+ <p>Other web servers like IIS do not use the raw PEM format that Apache and
+ Shibboleth can share, and therefore the components must generally use
+ separate copies of the key and certificate if they are to be shared. Most
+ other servers can export and/or import keys to and from PEM format or other
+ formats that OpenSSL can convert.</p>
+ <p>The SHAR is assigned a key and a certificate using shibboleth.ini's
+ <span class="fixed">certFile</span>, <span class="fixed">keyFile</span> and
+ <span class="fixed">keyPass</span> settings, described in <a href="#4.a.">
+ section 4.a.</a> These files must currently be in PEM format. OpenSSL
+ commands to generate a new keypair and a certificate request are shown here,
+ assuming 2048 bit RSA keys are to be used:</p>
<blockquote>
- <p>The only target component that must have a private key and
- certificate is the SHAR. While the target server itself should support
- SSL in most cases, it is mandatory for the SHAR to
- authenticate when contacting an AA, and it must therefore be
- given a key and an SSL client certificate. It is permissible
- for the SHAR to use the same keypair and certificate used by
- the target server itself, provided the certificate is signed
- by a CA accepted by the community of sites.</p>
-
- <p>The certificate and key should be placed based on whether
- they will also be used for Apache's server cert. If they will
- be used as a server certificate as well, they should probably
- be in the Apache tree in the usual <span class="fixedwidth">mod_ssl</span> spot, and
- the SHAR can read them from there. If the SHAR is not running
- as <span class="fixedwidth">root</span>, permissions might need to be changed to
- allow this access. If the certificate and key will only be
- used for the SHAR, they can be put in the same folder with the
- <span class="fixedwidth">shibboleth.ini</span> file.</p>
-
- <p>The SHAR is assigned a key and a certificate using
- shibboleth.ini's <span class="fixedwidth">certFile</span>,
- <span class="fixedwidth">keyFile</span> and
- <span class="fixedwidth">keyPass</span>, described in <a href="#4.a.">4.a</a>. These
- files must currently be in PEM format. OpenSSL commands to
- generate a new keypair and a certificate request are shown
- here, assuming RSA keys are to be used:</p>
-
- <blockquote>
- <span class="fixedwidth">$ openssl genrsa -des3 -out ssl.key 2048<br>
- $ openssl req -new -key ssl.key -out ssl.csr</span>
- </blockquote>
-
- <p>The signed certificate file returned by the CA should be
- usable directly, or can be converted to PEM format using the
- <span class="fixedwidth">openssl x509</span> command.</p>
-
- <p>The key and certificate files can be placed anywhere,
- though in or beneath the <span class="fixedwidth">/usr/local/apache/conf</span>
- directory is a good choice. The Apache child processes,
- often running as <span class="fixedwidth">nobody</span>, must be able to read them
- while the server is running, which may require permission
- changes.</p>
-
- <p>This particularly applies when sharing the key and
- certificate used by mod_ssl, which are only readable by root
- by default. The password, if any, must be placed in the conf
- file, since the module cannot prompt for it as the initial
- startup of mod_ssl can. The issues surrounding how to
- securely obtain a key while running as <span class="fixedwidth">nobody</span>
- may be addressed in a later release. Since the password will be
- stored in clear text in a frequently examined file, it is
- suggested to use a password not used elsewhere.</p>
-
- <p>Finally, the <span class="fixedwidth">calist</span> command provides the SHAR
- with a set of CA roots to trust when validating AA server
- certificates. In all cases, the SHAR verifies that the
- certificate's Subject CN equals the AA's hostname, but the CA root
- bundle restricts the accepted signers to those permitted by
- the SHAR. The parameter can be omitted to skip such validation.</p>
+ <p><span class="fixed">$ openssl genrsa -des3 -out ssl.key 2048<br>
+ $ openssl req -new -key ssl.key -out ssl.csr</span> </p>
</blockquote>
-
- <h4><a name="4.d."></a>4.d. Protecting Webpages</h4>
-
- <blockquote>
- <p>Protection of webpages is primarily achieved through
- "mapping" attributes provided by an AA to a localized
- vocabulary for authorization rules. Each attribute can be
- mapped using the <span class="fixedwidth">ShibMapAttribute</span> command to an HTTP
- header name where it can subsequently be accessed by
- applications, and optionally to an <span class="fixedwidth">alias</span> that can be
- used in a <span class="fixedwidth">Require</span> command to search for a matching
- value. This mapping command must be in <span class="fixedwidth">httpd.conf</span>,
- while the rest of the commands described here appear in
- content-specific configuration or <span class="fixedwidth">.htaccess</span>
- files.</p>
-
- <p>Any of the typical ways of protecting content may be used
- (.htaccess, Directory, Location, Files, etc.). There are two
- ways to trigger Shibboleth authentication: specifying an
- <span class="fixedwidth">AuthType</span> of <span class="fixedwidth">shibboleth</span> to use Shibboleth
- directly, or specifying <span class="fixedwidth">ShibBasicHijack On</span> to
- process existing .htaccess files using Shibboleth instead.
- Support for authorization consists of mod_auth-style require
- directives, as well as support for mod_auth group files.</p>
-
- <p>A complete list of the directives and their values is
- below:</p>
-
- <dl>
- <dd class="attribute">
- <span class="fixedwidth">AuthType <string></span>
- </dd>
-
- <dd class="value">
- <p>Use <span class="fixedwidth">shibboleth</span> for direct invocation, or
- <span class="fixedwidth">Basic</span> plus the <span class="fixedwidth">ShibBasicHijack On</span>
- option described below.</p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">ShibSSLOnly<on/off></span>
- </dd>
-
- <dd class="value">
- <p>Controls whether Shibboleth will reject non-SSL
- requests from clients. Defaults to <span class="fixedwidth">off</span>.</p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">ShibBasicHijack <on/off></span>
- </dd>
-
- <dd class="value">
- <p>Controls whether Shibboleth should or should not
- ignore requests for <span class="fixedwidth">AuthType Basic</span>. Defaults
- to <span class="fixedwidth">off</span>.</p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">ShibExportAssertion <on/off></span>
- </dd>
-
- <dd class="value">
- <p>Controls whether the SAML attribute assertion
- provided by the AA is exported in a base64-encoded
- HTTP header, <span class="fixedwidth">Shib-Attributes</span>. Defaults to
- <span class="fixedwidth">off</span>. While this does require parsing the
- raw XML, it also permits an application to see attributes that may have
- been filtered by an AAP, or to forward the SAML assertion to a third party.</p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">ShibAuthLifetime <seconds></span>
- </dd>
-
- <dd class="value">
- <p>Sets the maximum lifetime in seconds that a user
- session can survive. Omission or zero results in
- arbitrary session lifetime.</p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">ShibAuthTimeout <seconds></span>
- </dd>
-
- <dd class="value">
- <p>Sets the maximum number of seconds without any
- user activity that a session will remain alive. After
- <span class="fixedwidth">seconds</span> seconds without activity, the
- session is considered dead. Omission or <span class="fixedwidth">0</span>
- results in an arbitrary session timeout.</p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">AuthGroupFile <pathname></span>
- </dd>
-
- <dd class="value">
- <p>Same as mod_auth; collects EPPN's into a named
- group for access control. Note that mod_auth will not
- support group files when mod_shibrm is loaded, since
- they share the same command.</p>
-
-
+ <p>The signed certificate file returned by the CA should be usable directly,
+ or can be converted to PEM format using the <span class="fixed">openssl x509</span>
+ command.</p>
+ <p>If the key is to be shared with Apache, the web server's child processes,
+ often running as <span class="fixed">nobody</span>, must be able to read
+ them while the server is running, which may require permission changes.</p>
+ <p>This particularly applies when sharing the key and certificate used by
+ mod_ssl, which are only readable by root by default. The password, if any,
+ must be placed in the <span class="fixed">shibboleth.ini</span> file, since
+ the Apache module cannot prompt for it during initial startup as mod_ssl
+ can. The issues surrounding how to securely obtain a key while running as
+ <span class="fixed">nobody</span> may be addressed in a later release. Since
+ the password will be stored in clear text in a frequently examined file, it
+ is suggested to use a password not used elsewhere.</p>
+ <p>Finally, the <span class="fixed">calist</span> command provides the SHAR
+ with a set of CA roots to trust when validating AA server certificates. In
+ all cases, the SHAR verifies that the certificate's Subject CN equals the
+ AA's hostname, but the CA list restricts the accepted signers to those
+ permitted by the SHAR. The parameter can be omitted to skip such validation,
+ but this is not secure.</p>
+</blockquote>
+<h4><a name="4.d."></a>4.d. Protecting Web Pages</h4>
+<blockquote>
+ <p>Protection of web pages is primarily achieved through "mapping"
+ attributes provided by an AA to a localized vocabulary for authorization
+ rules. This was formerly accomplished in Apache with the <span class="fixed">
+ ShibMapAttribute</span> command, but this has been replaced with additional
+ features in the AAP syntax, described in <a href="#4.e.">section 4.e.</a>
+ This applies to both Apache and IIS.</p>
+ <p><b><u>IIS</u></b></p>
+ <p>The IIS RM module supports the mapping of attributes via AAP files, but
+ it does not support rule-based policies and therefore cannot protect static
+ content at this time. In addition, all of the configuration settings are
+ managed globally or per-site and are pulled from the <span class="fixed">
+ shibboleth.ini</span> file, so there are no additional commands to document
+ at this time.<br>
+ </p>
+ <p><b><u>Apache</u></b></p>
+ <p>The Apache RM module provided can interpret AAP settings to map
+ attributes to HTTP request headers and to <span class="fixed">Require</span>
+ rules, permitting protecting of both static and dynamic content. The
+ commands described here can appear in content-specific configuration blocks
+ or <span class="fixed">.htaccess</span> files. They determine what content
+ is to be protected, session policies, and static access control rules.</p>
+ <p>Any of the typical ways of protecting content may be used (.htaccess,
+ Directory, Location, Files, etc.). There are two ways to trigger Shibboleth
+ authentication: specifying an <span class="fixed">AuthType</span> of
+ <span class="fixed">shibboleth</span> to use Shibboleth directly, or using
+ <span class="fixed">ShibBasicHijack</span> to process existing .htaccess
+ files using Shibboleth instead. Support for authorization consists of
+ mod_auth-style require directives, as well as support for mod_auth group
+ files.</p>
+ <p>A complete list of the directives and their values is below:</p>
+ <dl>
+ <dd class="attribute"><span class="fixed">AuthType <string></span></dd>
+ <dd class="value">Use <span class="fixed">shibboleth</span> for direct
+ invocation, or <span class="fixed">Basic</span> plus the
+ <span class="fixed">ShibBasicHijack</span> option described below.</dd>
+ <dd class="attribute"><span class="fixed">ShibSSLOnly <on/off></span></dd>
+ <dd class="value">Controls whether Shibboleth will reject non-SSL
+ requests for resources from clients. Defaults to <span class="fixed">off</span>.</dd>
+ <dd class="attribute"><span class="fixed">ShibBasicHijack <on/off></span></dd>
+ <dd class="value">Controls whether Shibboleth should or should not
+ ignore requests with <span class="fixed">AuthType Basic</span>. Defaults
+ to <span class="fixed">off</span>.</dd>
+ <dd class="attribute"><span class="fixed">ShibExportAssertion <on/off></span></dd>
+ <dd class="value">Controls whether the SAML attribute assertion provided
+ by the AA is exported in a base64-encoded HTTP header,
+ <span class="fixed">Shib-Attributes</span>. Defaults to
+ <span class="fixed">off</span>. While this does require parsing the raw
+ XML, it also permits an application to see attributes that may have been
+ filtered by an AAP, or to forward the SAML assertion to a third party.</dd>
+ <dd class="attribute"><span class="fixed">ShibAuthLifetime <seconds></span></dd>
+ <dd class="value">If set, sessions are always terminated after the
+ specified number of seconds, resulting in a new redirect and request for
+ authentication, just as if a new request without a session is received.
+ Defaults to infinite.</dd>
+ <dd class="attribute"><span class="fixed">ShibAuthTimeout <seconds></span></dd>
+ <dd class="value">If set, sessions are always terminated after the
+ specified number of seconds of inactivity (defined as no requests
+ received in that session), resulting in a new redirect and request for
+ authentication, just as if a new request without a session is received.
+ Defaults to infinite.</dd>
+ <dd class="attribute"><span class="fixed">AuthGroupFile <pathname></span></dd>
+ <dd class="value">Same as mod_auth; collects values found in REMOTE_USER
+ into a named group for access control. An attribute must be mapped to
+ REMOTE_USER for this to work. Note that mod_auth will not support group
+ files when mod_shibrm is loaded, since they share the same command.
+ <p><a href="http://httpd.apache.org/docs/mod/core.html#require">This is
+ implemented</a> by placing a <span class="fixed">.htaccess</span> file
+ that references a group file stored at <span class="fixed">/pathname</span>:</p>
+ <blockquote>
+ <p><span class="fixed">AuthGroupFile /pathname<br>
+ require group workgroup</span></p>
+ </blockquote>
+ <p>An
+ <a href="http://httpd.apache.org/docs/mod/mod_auth.html#authgroupfile">
+ AuthGroupFile</a> used by Shibboleth might resemble:<br>
+ <span class="fixed">workgroup: joe@example.edu, jane@demo.edu, jim@sample.edu</span>
+ </dd>
+ <dd class="attribute"><span class="fixed">Require <string></span></dd>
+ <dd class="value">Enforce authorization using one of the following
+ methods.<ul type="circle">
+ <li><span class="fixed">valid-user</span><blockquote>
+ <p>Any Shibboleth user from a trusted origin site is accepted,
+ even if no actual attributes are received. This is a very
+ minimal kind of policy, but is useful for testing or for
+ deferring real policy to an application.</p>
+ </blockquote>
+ </li>
+ <p><span class="fixed">user</span></p>
<blockquote>
- <p><a href=
- "http://httpd.apache.org/docs/mod/core.html#require">This
- is implemented</a> by placing a <span class="fixedwidth">.htaccess</span>
- file that references an <span class="fixedwidth">AuthGroupFile</span> stored
- at <span class="fixedwidth">/path</span>:</p>
-
- <blockquote>
- <span class="fixedwidth">authgroupfile /path<br>
- require group workgroup</span>
- </blockquote>
-
- <p>Note that an <a href=
- "http://httpd.apache.org/docs/mod/mod_auth.html#authgroupfile">
- AuthGroupFile</a> used by Shibboleth would resemble
- <span class="fixedwidth">workgroup: joe@example.edu, jane@demo.edu,
- jim@sample.edu</span>.</p>
+ <p>A space-delimited list of values, such as from the
+ <span class="fixed">
+ urn:mace:dir:attribute-def:eduPersonPrincipalName</span>
+ attribute. Actually, any attribute can be mapped to REMOTE_USER,
+ even if this doesn't always make sense.</p>
</blockquote>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">Require <string></span>
- </dd>
-
- <dd class="value">
- <p>Enforce authorization using one of the following methods.</p>
-
- <ul type="circle">
-
- <li>
- <span class="fixedwidth">valid-user</span>
-
- <blockquote>
- <p>Any Shibboleth user from a trusted origin site is accepted,
- even if no actual attributes are received. This is a very minimal
- kind of policy, but is useful for testing or for deferring real
- policy to an application.</p>
- </blockquote>
- </li>
-
- <span class="fixedwidth">user</span>
-
- <blockquote>
- <p>A space-delimited list of EPPN values, provided that the
- <span class="fixedwidth">urn:mace:dir:attribute-def:eduPersonPrincipalName</span>
- attribute has been mapped to the
- <span class="fixedwidth">REMOTE_USER</span> header (as per the earlier
- example configuration commands). Actually, any attribute can be mapped to
- REMOTE_USER, even if this doesn't always make sense.</p>
- </blockquote>
- </li>
-
- <li>
- <span class="fixedwidth">group</span>
-
- <blockquote>
- <p>A space-delimited list of group names defined
- within <span class="fixedwidth">AuthGroupFile</span> files, again
- provided that a mapping to <span class="fixedwidth">REMOTE_USER</span>
- exists.</p>
- </blockquote>
- </li>
-
- <li>
- <span class="fixedwidth"><alias></span>
-
- <blockquote>
- <p>An arbitrary rule tag that matches an alias
- defined in a <span class="fixedwidth">ShibMapAttribute</span> server
- command. The rule value is a space-delimited
- list of attribute values, whose format depends on
- the attribute in question (e.g. an affiliation
- rule might look like <span class="fixedwidth">require affiliation
- staff@osu.edu faculty@mit.edu</span>).</p>
- </blockquote>
- </li>
- </ul>
-
- <p>Additionally, for <span class="fixedwidth">user</span> and
- <span class="fixedwidth"><alias></span>-based rules, if a tilde character
- is placed immediately following <span class="fixedwidth">user</span> or
- <span class="fixedwidth"><alias></span>, the expressions that follow are
- treated as regular expressions.</p>
-
- <p>For example, the regular expression AAP <span
- class="fixedwidth">require affiliation ~
- ^member@.+\.edu$</span> would evaluate to allowing
- anyone with an <span
- class="fixedwidth">eduPersonScopedAffiliation</span> of
- <span class="fixedwidth">member</span> from a .edu
- domain.</p>
-
- </dd>
- </dl>
- <br>
- </blockquote>
-
- <h4><a name="4.e."></a>4.e. Designing AAP's</h4>
-
+ </li>
+ <li><span class="fixed">group</span><blockquote>
+ <p>A space-delimited list of group names defined within
+ <span class="fixed">AuthGroupFile</span> files, again provided
+ that a mapping to <span class="fixed">REMOTE_USER</span> exists.</p>
+ </blockquote>
+ </li>
+ <li><span class="fixed"><alias></span><blockquote>
+ <p>An arbitrary rule name that matches an Alias defined in an
+ AAP file. The rule value is a space-delimited list of attribute
+ values, whose format depends on the attribute in question (e.g.
+ an affiliation rule might look like:</p>
+ <p><span class="fixed">require affiliation staff@osu.edu
+ faculty@mit.edu</span></p>
+ </blockquote>
+ </li>
+ </ul>
+ <p>Additionally, for <span class="fixed">user</span> and
+ <span class="fixed"><alias></span>-based rules, if a tilde character is
+ placed immediately following <span class="fixed">user</span> or
+ <span class="fixed"><alias></span>, the expressions that follow are
+ treated as regular expressions. The syntax supported is generally based
+ on the one defined by <a href="http://www.w3.org/TR/xmlschema-2/#regexs">
+ XML Schema</a>. This specification borders on unreadable, but the syntax
+ is generally Perl-like. Expressions should generally be "anchored" with
+ the ^ and $ symbols to insure mid-string matches don't cause false
+ positives.</p>
+ <p>For example, the rule:<br>
+ <span class="fixed">require affiliation ~ ^member@.+\.edu$<br>
+ </span>would evaluate to allowing anyone with an <span class="fixed">
+ affiliation</span> of <span class="fixed">member</span> from a .edu
+ domain.</dd>
+ </dl>
+</blockquote>
+<h4><a name="4.e."></a>4.e. Defining Attributes and Acceptance Policies</h4>
+<blockquote>
+ <p>Shibboleth allows a user and a site to release a varying set of
+ attributes to a destination site, and does not impose restrictions on the
+ kinds of attribute information provided by an AA. Target implementations
+ must be prepared to examine the attributes they receive and filter them
+ based on policies about what information to permit an origin site to assert
+ about its users.</p>
+ <p>Attribute acceptance is the process of defining acceptable attributes and
+ filtering attribute values before passing them on to a resource manager,
+ such as the <span class="fixed">mod_shibrm</span> module. Data blocked by
+ AAP filters will not be passed to the CGI environment or used when enforcing
+ <span class="fixed">.htaccess</span> rules. Note that the attribute
+ assertion exported to the <span class="fixed">Shib-Attributes</span> header
+ is unfiltered.</p>
+ <p>The Shibboleth implementation supports Scoped and Simple attributes and
+ filtering policies for different kinds of attributes, and is potentially
+ extensible to more complex attributes in the future. An attribute is
+ considered Scoped if the XML representation of its values contains a "Scope"
+ attribute. As of 1.0.1, this is detected at runtime and requires no
+ configuration work.</p>
+ <p><b>An essential part of the Shibboleth trust fabric is ensuring that
+ sites only assert attributes for domains for which they are considered
+ authoritative by the target. Typically, this means that Brown University
+ will be trusted to assert attributes only scoped to <span class="fixed">
+ brown.edu</span>. Unless there are very specific circumstances requiring
+ this restriction be removed, it is strongly encouraged that such policies be
+ in place.</b></p>
+ <h4>Scoped:</h4>
<blockquote>
- <p>Shibboleth allows a user and a site to release a varying
- set of attributes to a destination site, and does not impose
- restrictions on the kinds of attribute information provided
- by an AA. Target implementations must also be prepared to
- examine the attributes they receive and filter them based on
- policies about what information to permit an origin site to
- assert about its users.</p>
-
- <p>Attribute acceptance is the process of filtering attribute
- values before passing them on to a resource manager, such as
- the <span class="fixedwidth">mod_shibrm</span> module. Data blocked by AAP filters
- will not be passed to the CGI environment or used when
- enforcing <span class="fixedwidth">.htaccess</span> rules.
- Note that the attribute assertion exported to the
- <span class="fixedwidth">Shib-Attributes</span> header is unfiltered.</p>
-
- <p>The Shibboleth distribution supports <span class="fixedwidth">scoped</span> and
- <span class="fixedwidth">simple</span> filtering policies for different kinds of
- attributes.</p>
-
- <p><b>An essential part of the Shibboleth trust fabric is ensuring
- that sites only assert attributes for domains for which they are
- considered authoritative by the target. Typically, this means
- that Brown University will be trusted to assert attributes only
- scoped to <span class="fixedwidth">brown.edu</span>. Unless
- there are very specific circumstances requiring this restriction
- be removed, it is strongly encouraged that such policies be in place.</b></p>
-
- <h4>Scoped:</h4>
- <blockquote>
- <p>Scoped attributes are a special kind of attribute whose
- values are a combination of a <span class="fixedwidth">value</span> and a
- <span class="fixedwidth">scope</span>, or <span class="fixedwidth">context</span> for the value. An
- example is <span class="fixedwidth">eduPersonScopedAffiliation</span>, which adds a
- scope to the defined set of <span class="fixedwidth">eduPersonAffiliation</span>
- values, such as <span class="fixedwidth">student</span>, <span class="fixedwidth">member</span>, or
- <span class="fixedwidth">faculty</span>. Scopes are expressed as DNS domains and
- subdomains.</p>
-
- <p>Any <span class="fixedwidth">scoped</span> attribute can be
- scoped only to the origin site's permitted domains. These
- domains are listed in the sites file that provides trust
- information to the system. Domains can be explicit or
- regular expressions, and can be changed by a target to meet
- its needs if a local version of the file is created. Thus,
- attribute acceptance processing for <span class="fixedwidth">scoped</span>
- attributes is based on the sites file, in addition to the mechanism described
- below for <span class="fixedwidth">simple</span> attributes.</p>
- </blockquote>
-
- <h4>Simple:</h4>
- <blockquote>
- <p>Simple attributes are attributes whose value is expressed
- in XML as a Text node; that is, the value is just a string.
- Multiple values are permitted.
- <span class="fixedwidth">eduPersonEntitlement</span>, in which the values are URIs,
- is one example of a simple attribute.</p>
- <p>In this release, simple (and scoped) attribute acceptance is
- controlled with an external policy file written in XML. The
- schema for the file is described by the
- <span class="fixedwidth">shibboleth.xsd</span> schema, and an example file is
- included, <span class="fixedwidth">AAP.xml</span>. If the <span class="fixedwidth">aap-uri</span>
- parameter in the <span class="fixedwidth">shibboleth.ini</span> file is left out,
- then no policy is applied, and no filtering is done.
- Otherwise, the rules encoded in the file are used.</p>
- <p>The policy is a default-deny algorithm that requires
- permissible attributes and values be listed explicitly. That
- is, an empty file permits nothing. Each attribute to be
- permitted must be listed in the file by name in an
- <span class="fixedwidth"><AttributeRule></span>. Each such rule is a
- collection of <span class="fixedwidth"><SiteRule></span> elements along with
- an optional <span class="fixedwidth"><AnySite></span> default rule. In turn
- each site rule is a set of <span class="fixedwidth"><Value></span> rules that
- specify matches to permit, either literal or regular
- expressions.</p>
- </blockquote>
-
- <p>A syntax summary follows:</p>
- <blockquote>
-
- <p><span class="fixedwidth"><AttributeAcceptancePolicy</span></p>
- <blockquote>The top level element in the
- file.</blockquote>
-
- <p><span class="fixedwidth"><AttributeRule Name="attribute
- URI"></span></p>
- <blockquote>Specifies a rule for an attribute, named with
- its URI.</blockquote>
-
- <p><span class="fixedwidth"><AnySite></span></p>
- <blockquote>Specifies a rule that always applies to the
- attribute, regardless of the asserting AA.</blockquote>
-
- <p><span class="fixedwidth"><SiteRule
- Name="site.domain.name"></span></p>
- <blockquote>A rule that applies to the origin site AA
- corresponding to the domain name.</blockquote>
-
- <p><span class="fixedwidth"><AnyValue></span></p>
- <blockquote>Specifies a rule that always applies to the
- attribute and site, regardless of the value(s).</blockquote>
-
- <p><span class="fixedwidth"><Value Type="type"></span></p>
- <blockquote>Specifies a value to permit, either directly
- using <span class="fixedwidth">type</span> <span class="fixedwidth">literal</span>, or using a set of
- matching expressions as <span class="fixedwidth">type</span> <span class="fixedwidth">regexp</span>.
- <span class="fixedwidth">literal</span> is the default if <span class="fixedwidth">Type</span> is not
- specified.</blockquote>
-
- </blockquote>
-
- <p>The regular expression syntax is a subset of the usual
- Perl and Unix syntaxes that is described in the XML Schema
- specification by the W3C. Most typical expressions should
- work. Be sure to anchor them using <span class="fixedwidth">^</span> and <span class="fixedwidth">$</span>
- to avoid unintentional matches midstring.</p>
-
- <p>Note that the AAP rules described in this section are not
- part of the Shibboleth architecture and are simply one
- possible set of approaches provided by this implementation.</p>
+ <p>Scoped attributes are a special kind of attribute whose values are a
+ combination of a <span class="fixed">value</span> and a
+ <span class="fixed">scope</span>, or <span class="fixed">context</span>
+ for the value. An example is <span class="fixed">
+ eduPersonScopedAffiliation</span>, which adds a scope to the defined set
+ of <span class="fixed">eduPersonAffiliation</span> values, such as
+ <span class="fixed">student</span>, <span class="fixed">member</span>,
+ or <span class="fixed">faculty</span>. Scopes are expressed as DNS
+ domains and subdomains.</p>
+ <p>Any <span class="fixed">scoped</span> attribute can be scoped only to
+ the origin site's permitted domains. These domains are listed in the
+ site metadata that provides policy information to the system. Domains
+ can be explicit or regular expressions, and can be changed by a target
+ to meet its needs. Thus, attribute acceptance processing for
+ <span class="fixed">scoped</span> attributes is based on site metadata,
+ in addition to the mechanism described below for <span class="fixed">
+ simple</span> attributes.</p>
</blockquote>
-
- <h4><a name="4.f."></a>4.f. Using Attributes in
- Applications</h4>
-
+ <h4>Simple:</h4>
<blockquote>
- <p>Apart from the simple RM functionality provided, attribute
- information may be made available directly to applications
- via the standard practice of creating custom HTTP request
- headers before passing control to the application.
- Applications should make no assumption about the presence of
- specific attributes for their use unless they have intimate
- knowledge of the attribute release policies in place.</p>
-
- <p>The <span class="fixedwidth">ShibMapAttribute</span> directive controls this
- interface, and maps a Shibboleth attribute (identified by an
- unambiguous URI) to a header name, such as
- <span class="fixedwidth">Shib-EP-Affiliation</span>. Using that example, any values
- of the mapped attribute will be placed in that header,
- delimited by spaces. An application that uses a CGI-like
- syntax to access the header will find the values in the
- <span class="fixedwidth">HTTP_SHIB_EP_AFFILIATION</span> variable. Using the
- command, any attribute can be placed in any header, to drive
- legacy applications that expect information in a particular
- header.</p>
-
- <p>The <span class="fixedwidth">REMOTE_USER</span> variable is a special case that
- is generally populated automatically by the web server based
- on an internal piece of data that represents the user's
- <span class="fixedwidth">username</span>. Unlike many authentication modules,
- Shibboleth does not guarantee that <span class="fixedwidth">REMOTE_USER</span> will
- have any value. If it does, it is set solely based on a
- <span class="fixedwidth">ShibMapAttribute</span> command. For many purposes, the
- <span class="fixedwidth">urn:mace:dir:attribute-def:eduPersonPrincipalName</span>
- attribute should be mapped to <span class="fixedwidth">REMOTE_USER</span>. Even so,
- EPPN may not be provided by the AA, and <span class="fixedwidth">REMOTE_USER</span>
- might still be empty.</p>
-
- <p>The <span class="fixedwidth">Shib-Origin-Site</span> variable will contain the
- unique name/identifier of the origin site of the user. Some applications may use this
- to lookup additional policy or application data. It normally takes the form of a URI
- but could be any string.</p>
-
- <p>Finally, the <span class="fixedwidth">ShibExportAssertion</span> flag instructs
- the module to place the entire XML message containing the
- SAML attribute information from the AA into a base64-encoded
- header called <span class="fixedwidth">Shib-Attributes</span>. This is a raw
- interface that provides an application with the entire AA
- response, and is not a filtered view based on any attribute
- acceptance rules or even based on what attributes are
- recognized by the target. What was sent is what you see.</p>
+ <p>Simple attributes are attributes whose value is expressed in XML as a
+ Text node; that is, the value is just a string. Multiple values are
+ permitted. <span class="fixed">eduPersonEntitlement</span>, in which the
+ values are URIs, is one example of a simple attribute.</p>
+ <p>Both Simple and Scoped attribute acceptance is controlled with an
+ external policy file written in XML. The schema for the file is
+ described by the <span class="fixed">shibboleth.xsd</span> schema, and
+ an example file is included, <span class="fixed">AAP.xml</span>. It is
+ mandatory to supply such a file, because attributes are recognized based
+ on their presence in this file, and not by separate configuration
+ processes. Only by listing an attribute in the file will it be accepted
+ and processed by the RM.</p>
+ <p>The policy is a default-deny algorithm that requires permissible
+ attributes and values be listed explicitly. That is, an empty file
+ permits nothing. Each attribute to be supported must be listed in the
+ file by name in an <span class="fixed"><AttributeRule></span>. Each such
+ rule is a collection of <span class="fixed"><SiteRule></span> elements
+ along with an optional <span class="fixed"><AnySite></span> default
+ rule. In turn each site rule is a set of <span class="fixed"><Value></span>
+ rules that specify matches to permit, either literal or regular
+ expressions, or a wildcarded <span class="fixed"><AnyValue></span>
+ default rule, which is equivalent to a single regular expression rule
+ allowing anything.</p>
</blockquote>
-
- <h4><a name="4.g."></a>4.g. <span
- class="fixedwidth">siterefresh</span></h4>
-
+ <p>A syntax summary follows:</p>
<blockquote>
- <p>Shibboleth provides a simple tool called <span
- class="fixedwidth">siterefresh</span> in the <span
- class="fixedwidth">/opt/shibboleth/bin</span> folder of the
- distribution to maintain metadata files referenced by <span
- class="fixedwidth">shibboleth.ini</span>. It will return 0 on
- success and a negative number on failure and log errors to <span
- class="fixedwidth">stderr</span>. If the data in the new metadata
- file is bad or the signature is invalid, the existing copy is
- kept. The SHAR and SHIRE stat the file each time the data is
- used, allowing them to detect and utilize updates in real-time
- operation.</p>
-
- <p><span class="fixedwidth">siterefresh</span> takes the following
- command-line parameters:</p>
-
- <dl>
- <dd class="attribute">
- <span class="fixedwidth">--url <URL></span>
- </dd>
-
- <dd class="value">
- <p>Specifies the <span class="fixedwidth">URL</span> of the
- remote metadata file to update the local file.</p>
- </dd>
-
- <dd class="attribute">
- <span class="fixedwidth">--out <pathname></span>
- </dd>
-
- <dd class="value">
- <p>Specifies the local file to write the new metadata to.</p>
- </dd>
-
- <dd class="attributeopt">
- <span class="fixedwidth">--cert <pathname></span>
- </dd>
-
- <dd class="valueopt">
- <p>Specifies the location of a certificate stored in <span
- class="fixedwidth">PEM</span> format used to validate the
- signature of the metadata file. Since much of Shibboleth's
- trust flows from this metadata file, this option is highly
- recommended.</p>
- </dd>
-
- <dd class="attributeopt">
- <span class="fixedwidth">--schema <pathname></span>
+ <p><span class="fixed"><AttributeAcceptancePolicy</span></p>
+ <blockquote>
+ <p>The top level element in the file.</p>
+ </blockquote>
+ <p><span class="fixed"><AttributeRule<br>
+ Name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation"<br>
+ Header="Shib-EP-Affiliation" Alias="affiliation"></span></p>
+ <blockquote>
+ <p>Specifies a rule for an attribute, named by its URI. The
+ following XML attributes can be supplied:</p>
+ <table border="1" cellpadding="5" cellspacing="5">
+ <tr>
+ <td><span class="fixed">Name</span></td>
+ <td>The name of the Shibboleth attribute, usually a URI.
+ This is the only required XML attribute.</td>
+ </tr>
+ <tr>
+ <td><span class="fixed">Namespace</span></td>
+ <td>If the attribute's name includes a SAML namespace,
+ supply it here. Normally this is unused.</td>
+ </tr>
+ <tr>
+ <td><span class="fixed">Header</span></td>
+ <td>The HTTP request header to map the attribute's values
+ to.</td>
+ </tr>
+ <tr>
+ <td><span class="fixed">Alias</span></td>
+ <td>A short name for the attribute, determines the name of
+ the Apache <span class="fixed">Requires</span> rule.</td>
+ </tr>
+ </table>
+ </blockquote>
+ <p><span class="fixed"><AnySite></span></p>
+ <blockquote>
+ <p>Specifies a rule that always applies to the attribute, regardless
+ of the asserting AA.</p>
+ </blockquote>
+ <p><span class="fixed"><SiteRule Name="host.domain.com"></span></p>
+ <blockquote>
+ <p>A rule that applies to the origin site AA corresponding to the
+ hostname.</p>
+ </blockquote>
+ <p><span class="fixed"><AnyValue></span></p>
+ <blockquote>
+ <p>Specifies a rule that always applies to the attribute and site,
+ regardless of the value(s).</p>
+ </blockquote>
+ <p><span class="fixed"><Value Type="type"></span></p>
+ <blockquote>
+ <p>Specifies a value to permit, either directly using
+ <span class="fixed">type</span> <span class="fixed">literal</span>,
+ or using a set of matching expressions as <span class="fixed">type</span>
+ <span class="fixed">regexp</span>. <span class="fixed">literal</span>
+ is the default if <span class="fixed">Type</span> is not specified.</p>
+ </blockquote>
+ </blockquote>
+ <p>The regular expression syntax is a subset of the usual Perl and Unix
+ syntaxes that is described in the XML Schema specification by the W3C. Most
+ typical expressions should work. Be sure to anchor them using
+ <span class="fixed">^</span> and <span class="fixed">$</span> to avoid
+ unintentional matches midstring.</p>
+</blockquote>
+<h4><a name="4.f."></a>4.f. Using Attributes in Applications</h4>
+<blockquote>
+ <p>Apart from the simple RM functionality provided, attribute information
+ may be made available directly to applications via the standard practice of
+ creating custom HTTP request headers before passing control to the
+ application. Applications should make no assumption about the presence of
+ specific attributes for their use unless they have intimate knowledge of the
+ attribute release policies in place.</p>
+ <p>The AAP metadata controls this interface, and maps a Shibboleth attribute
+ to a header name, such as <span class="fixed">Shib-EP-Affiliation</span>.
+ Using that example, any values of the mapped attribute will be placed in
+ that header, delimited by semicolons. An application that uses a CGI-like
+ syntax to access the header will find the values in the <span class="fixed">
+ HTTP_SHIB_EP_AFFILIATION</span> variable. Any attribute can be placed in any
+ header, to drive legacy applications that expect information in a particular
+ location.</p>
+ <p>The <span class="fixed">REMOTE_USER</span> variable is a special case
+ that is generally populated automatically by the web server based on an
+ internal piece of data that represents the current <span class="fixed">
+ username</span>. Unlike many authentication modules, Shibboleth does not
+ guarantee that <span class="fixed">REMOTE_USER</span> will have any value,
+ because users may remain anonymous in many cases. If it does have a value,
+ it is set solely because of an AAP file that maps an attribute to that
+ header name. For many purposes, the <span class="fixed">
+ urn:mace:dir:attribute-def:eduPersonPrincipalName</span> attribute should be
+ mapped to <span class="fixed">REMOTE_USER</span>. Even so, EPPN may not be
+ provided by the AA, and <span class="fixed">REMOTE_USER</span> might still
+ be empty.</p>
+ <p>The <span class="fixed">Shib-Origin-Site</span> variable will contain the
+ unique name/identifier of the origin site of the user. Some applications may
+ use this to lookup additional policy or application data. It normally takes
+ the form of a URI but could be any string in some deployments.</p>
+ <p>Finally, configuration may instruct the web server to place the entire
+ XML message containing the SAML attribute information from the AA into a
+ base64-encoded header called <span class="fixed">Shib-Attributes</span>.
+ This is a raw interface that provides an application with the entire AA
+ response, and is not a filtered view based on any attribute acceptance rules
+ or even based on what attributes are recognized by the target. What was sent
+ is what you see.</p>
+</blockquote>
+<h4><a name="4.g."></a>4.g. <span class="fixed">siterefresh</span></h4>
+<blockquote>
+ <p>Shibboleth provides a simple tool called <span class="fixed">siterefresh</span>
+ in the <span class="fixed">/opt/shibboleth/bin</span> folder of the
+ distribution to maintain metadata files referenced by <span class="fixed">
+ shibboleth.ini</span>. It will return 0 on success and a negative number on
+ failure and log errors to <span class="fixed">stderr</span>. If the data in
+ the new metadata file is bad or the signature is invalid, the existing copy
+ is kept. The SHAR and SHIRE stat all metadata files each time the data is
+ used, allowing them to detect and utilize updates in real-time operation.</p>
+ <p><span class="fixed">siterefresh</span> takes the following command-line
+ parameters:</p>
+ <dl>
+ <dd class="attribute"><span class="fixed">--url <URL></span> </dd>
+ <dd class="value">Specifies the <span class="fixed">URL</span> of the
+ remote metadata file with which to update the local file.</dd>
+ <dd class="attribute"><span class="fixed">--out <pathname></span> </dd>
+ <dd class="value">Specifies the local file to which to write the new
+ metadata.</dd>
+ <dd class="attributeopt"><span class="fixed">--cert <pathname></span>
</dd>
-
- <dd class="valueopt">
- <p>Optionally defines a base path for schemas. Defaults to
- <span
- class="fixedwidth">/opt/shibboleth/etc/shibboleth/</span>.</p>
+ <dd class="valueopt">Specifies the location of a certificate stored in
+ <span class="fixed">PEM</span> format used to validate the signature of
+ the metadata file. Since much of Shibboleth's security flows from
+ metadata files, this option is highly recommended, and the certificate
+ used should be verified independently.</dd>
+ <dd class="attributeopt"><span class="fixed">--schema <pathname></span>
</dd>
- </dl>
-
- <p>A complete command issued to <span
- class="fixedwidth">siterefresh</span> would take the form:</p>
-
- <blockquote><span class="fixedwidth">
- /opt/shibboleth/bin/siterefresh --out sites.xml --cert internet2.pem \<br>
- --url http://wayf.internet2.edu/InQueue/sites.xml
- </span></blockquote>
-
- <p>It is recommended that similar commands be added to a <span
- class="fixedwidth">crontab</span> to keep the sites and trust files refreshed.</p>
+ <dd class="valueopt">Optionally defines a base path for schemas to use
+ when validating the file. Defaults to <span class="fixed">
+ /opt/shibboleth/etc/shibboleth/</span>.</dd>
+ </dl>
+ <p>A complete command issued to <span class="fixed">siterefresh</span> might
+ take the form:</p>
+ <blockquote>
+ <p><span class="fixed">/opt/shibboleth/bin/siterefresh --out sites.xml
+ --cert internet2.pem \<br>
+ --url http://wayf.internet2.edu/InQueue/sites.xml </span></p>
</blockquote>
-
-
- <br>
- <hr>
- <br>
-
- <h3><a name="5."></a>5. Troubleshooting</h3>
-
- <p>This section provides basic information about testing
- Shibboleth targets. This information is not intended to be
- comprehensive, but instead rudimentary guidelines for basic
- configuration tests and problems. For more detailed information
- or answers to specific problems not addressed in this section,
- please mail <a href=
- "mailto:mace-shib-users@internet2.edu">mace-shib-users@internet2.edu</a>
- with a thorough description of errors and configurations
- used.</p>
-
- <h4><a name="5.a."></a>5.a. Basic Testing</h4>
-
+ <p>It is recommended that similar commands be added to a <span class="fixed">
+ crontab</span> to keep the site and trust files refreshed. AAP files tend to
+ be site-specific, but could be maintained and distributed centrally. If the
+ command is invoked in a script that writes the file to a new location and
+ compares it with the old contents before overwriting the original, the
+ command could be run very often without impacting target operations,
+ providing a high degree of currency in case sites become compromised.</p>
+</blockquote>
+<p><br>
+</p>
+<hr>
+<h3><a name="5."></a>5. Troubleshooting</h3>
+<p>This section provides basic information about testing Shibboleth targets.
+This information is not intended to be comprehensive, but instead rudimentary
+guidelines for basic configuration tests and problems. For more detailed
+information or answers to specific problems not addressed in this section,
+please mail <a href="mailto:mace-shib-users@internet2.edu">
+mace-shib-users@internet2.edu</a> with a thorough description of errors and
+configurations used.</p>
+<h4><a name="5.a."></a>5.a. Basic Testing</h4>
+<blockquote>
+ <p>The target may be tested by generating a folder with very basic access
+ controls on it, and accessing it using a web browser. Place a simple webpage
+ such as <span class="fixed">index.html</span> in <span class="fixed">
+ /secure/</span>. Then, add the following lines to <span class="fixed">
+ httpd.conf</span>, which should be removed when testing is over:</p>
<blockquote>
- <p>The target may be tested by generating a folder with very
- basic access controls on it, and accessing it using a web
- browser. Place a simple webpage such as <span class="fixedwidth">index.html</span>
- in <span class="fixedwidth">/secure/</span>. Then, add the following lines to
- <span class="fixedwidth">httpd.conf</span>, which should be removed when testing is
- over:</p>
-
- <blockquote>
- <span class="fixedwidth"># Configure a test directory<br>
+ <p><span class="fixed"># Configure a test directory<br>
<Location /secure><br>
AuthType shibboleth<br>
require valid-user<br>
#AuthGroupFile /foo<br>
#ShibExportAssertion On<br>
</Location><br>
- </span>
- </blockquote>
-
- <p><b>For information regarding specific error messages that
- may be generated if the target does not work successfully,
- please refer to section <a href="#4.b.">4.b</a>, or write <a
- href=
- "mailto:mace-shib-users@internet2.edu">mace-shib-users@internet2.edu</a>.</b></p>
+ </span></p>
</blockquote>
+ <p><b>For information regarding specific error messages that may be
+ generated if the target does not work successfully, please refer to section
+ <a href="#5.b.">5.b.</a>, or write
+ <a href="mailto:mace-shib-users@internet2.edu">mace-shib-users@internet2.edu</a>.</b></p>
+</blockquote>
+<h4><a name="5.b."></a>5.b. Common Problems</h4>
+<blockquote>
+ <p>A knowledge base is being developed in the
+ <a href="http://www.columbia.edu/~wassa/shib.faq/shibboleth-faq.%20%20%20%20%20%20html">
+ Shibboleth Deployer's FAQ</a>. Please mail
+ <a href="mailto:mace-shib-users@internet2.edu">mace-shib-users@
+ internet2.edu</a> with any additional questions or problems encountered that
+ are not answered by this basic guide.</p>
+</blockquote>
+
+</body>
- <h4><a name="5.b."></a>5.b. Common Problems</h4>
-
- <blockquote>
- <p>A knowledge base is being developed in the <a
- href="http://www.columbia.edu/~wassa/shib.faq/shibboleth-faq.
- html">Shibboleth Deployer's FAQ</a>. Please mail <a href=
- "mailto:mace-shib-users@internet2.edu">mace-shib-users@
- internet2.edu</a> with any additional questions or problems
- encountered that are not answered by this basic guide.</p>
- </blockquote>
- </body>
</html>
projects / shibboleth / sp.git / commitdiff