Fixes to chapter 2.
authorndk <ndk@ab3bd59b-922f-494d-bb5f-6f0a3c29deca>
Mon, 3 May 2004 03:05:39 +0000 (03:05 +0000)
committerndk <ndk@ab3bd59b-922f-494d-bb5f-6f0a3c29deca>
Mon, 3 May 2004 03:05:39 +0000 (03:05 +0000)
git-svn-id: https://subversion.switch.ch/svn/shibboleth/java-idp/trunk@1046 ab3bd59b-922f-494d-bb5f-6f0a3c29deca

doc/DEPLOY-GUIDE-TARGET.html

index 2ddbad6..fbdc64a 100644 (file)
@@ -427,32 +427,43 @@ requesting attributes.</p>
 <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>
+to ensure Shibboleth functions well, both political and technical. Shibboleth is 
+entirely written in Java on the origin side. These are the recommendations and 
+requirements for a successful implementation of a Shibboleth origin.</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 Sun/ONC RPC mechanism to communicate 
-    with the SHAR over Unix domain or TCP sockets. The target&#39;s web servers must 
-    be running <a href="http://http://www.apache.org/dist/httpd/">Apache</a> 
-    1.3+, 2.0+, or Microsoft IIS 4.0+ More precise technical 
-    details are discussed in <a href="#3.a.">3.a</a>.</p>
-</blockquote>
+<ul>
+    <li>A common institutional directory service should be operational; 
+    Shibboleth comes with LDAP and SQL capabilities built in, and the Attribute 
+    Authority has a Java API which will allow specification of interfaces with 
+    legacy directories. This is discussed further in <a href="#4.d.">section 4.d</a>.</li>
+    <li>A method to authenticate browser users must be in place, preferably in 
+    the form of an enterprise authentication service. Some form of an SSO or a 
+    WebISO service is not explicitly necessary for Shibboleth; however, it is 
+    highly recommended. Implementation details of this are discussed in
+    <a href="#4.c.">section 4.c</a>.</li>
+    <li>Shibboleth is known to work on Windows, Linux, and Solaris, but should
+    function on any platform that has a Tomcat implementation.</li>
+    <li>A Java servlet container; Shibboleth has been tested extensively with
+    Tomcat.</li>
+    <li>It is recommended that a web server such as Apache be deployed in front
+    of Tomcat to provide authentication services and to control the flow of
+    requests to Tomcat.  There may be issues surrounding the number of maximum
+    connections to the web server and to the servlet container.</li>
+</ul>
 <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>For testing in a private environment, Shibboleth comes with a default
-    configuration that demonstrates how to implement a local peered agreement
-    and supports testing both origin and target on the same box using localhost
-    URLs. The sample key and certificate is for ease of testing only, and should
-    always be replaced for real world use.</p>
+    relationships. Each federation will have a different application process. 
+    When an origin is accepted into a federation, its information is added to 
+    the sites file used by the WAYF and target sites.</p>
+    <p>Attribute release and acceptance policies, the use and caching of
+    attributes, and definition of commonly traded attributes are examples of
+    specifications a federation may make.  <b>The default configuration that
+    ships with Shibboleth is intended for use in testing against a <span
+    class="fixed">localhost</span> target.  In order to interoperate with other
+    relying parties, such as a federation, consult the steps provided by the
+    guidelines of that relying party.</b></p>
 </blockquote>
 <h4><a name="2.c."></a>2.c. Security Considerations</h4>
 <blockquote>
@@ -462,9 +473,7 @@ and requirements for a successful implementation of a Shibboleth target.</p>
     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 
+        <li>SSL use is optional for origin 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 
@@ -477,59 +486,76 @@ and requirements for a successful implementation of a Shibboleth target.</p>
         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 domain name lookups
+        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>
+        provides is accurate. Proper security measures should also be in place 
+        on directory access and population(see
+        <a href="http://www.georgetown.edu/giia/internet2/ldap-recipe/#AccessControl">
+        Access Control</a> in the
+        <a href="http://www.georgetown.edu/giia/internet2/ldap-recipe/">LDAP 
+        recipe</a> for more information). 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&#39;s other security 
-        services, and cookie stores on client machines should be well protected.</li>
+        level that would be expected for a campus&#39; 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 
+    <p>In the Shibboleth architecture, the origin and target must each 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&#39;s 
-    acceptible to your federations, consult chapter <a href="#4.c.">4.c</a> for 
-    information on certificate and key generation.</p>
+    which may be stipulated by some Federation rules. Different federations may 
+    require the use of different CA&#39;s.</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&#39;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 a specifically desired subset. The SHAR provides a client
-    certificate with its request (assuming SSL is used) so the AA can further
-    refine the information the SHAR is allowed to know. The AA 
-    processes this request using all applicable ARP&#39;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>
+    <p>The Attribute Authority maintains a set of policies called Attribute 
+    Release Policies (or ARP&#39;s) that govern the sharing of user attributes with 
+    Shibboleth target sites. When a user attempts to access a 
+    Shibboleth-protected resource, that resource&#39;s SHAR queries the user&#39;s AA 
+    for all attributes to which it is entitled. The SHAR provides its own name 
+    and the URI of the requesting application. The 
+    AA finds the attributes associated with the browser user, determines an 
+    &quot;Effective ARP&quot; for this user, and then sends to the SHAR only the 
+    attribute-value pairs allowed in this policy.</p>
+    <p>An ARP may be thought of as a sort of filter for outbound attributes; it 
+    cannot create attributes or data that aren&#39;t originally present, but it can 
+    limit the attributes released and the values those attributes may have when 
+    released. It does not change the information in the data sources in any way.</p>
+    <p>Each ARP is comprised of one or more rules that specify which attributes
+    and values may be released to a given application and that SHAR. The
+    assignment of rules to various targets is quite flexible and includes
+    mechanisms for specifying: that a rule should affect all targets (default
+    rule), exact SHAR names for which a rule is applicable, regular expressions
+    against which SHAR names should be matched to determine if a rule is
+    applicable, and individual applications that may span hosts and URL's as
+    necessary.</p>
+    <p>For each request, an Effective ARP is determined by locating all ARP&#39;s 
+    applicable to the designated user and extracting each rule that matches the 
+    querying SHAR and resource. Attributes and values that are specified for 
+    release are included in the effective ARP, while those specified for denial 
+    are blocked from release. See section <a href="#5.b.i.">5.b.i</a> for 
+    details on how ARP&#39;s are processed.</p>
+    <p>Various ARP&#39;s may be combined in forming the Effective ARP. For instance, 
+    the Site ARP is administratively maintained and applies to all users for 
+    which the AA is answerable. User ARP&#39;s apply to a specific user only, and 
+    can be maintained either administratively or by the users themselves. All 
+    ARP&#39;s are specified using the same syntax and semantics.</p>
 </blockquote>
-<h4><a name="2.f."></a>2.f. Attribute Acceptance Policies</h4>
+<h4><a name="2.f."></a>2.f. Designate Contacts</h4>
 <blockquote>
-    <p>When a target receives a set of attributes, it must evaluate them in the 
-    context of the Attribute Authority that is providing them, to assess their 
-    &quot;reasonableness&quot;. For example, if the value of an attribute is expected to 
-    be from a small set of enumerated choices, the value should be compared 
-    against that list. If a particular attribute or value is only trusted when 
-    asserted by specific origins, that too should be checked.</p>
-    <p>Targets are configured to accept specific attributes that they understand 
-    and care about, and are also configured with the rules to apply before 
-    accepting the attributes for use by the RM or an application. Attributes and 
-    values that don&#39;t meet the target&#39;s requirements are filtered out. The set 
-    of configuration rules to make these decisions is called an Attribute 
-    Acceptance Policy (AAP).</p>
+    <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.  These contacts are then supplied to
+    the federation and optionally to relying parties individually to facilitate
+    communications and troubleshooting.</p>
 </blockquote>
 <h4><a name="2.g."></a>2.g. Browser Requirements</h4>
 <blockquote>
@@ -541,12 +567,12 @@ and requirements for a successful implementation of a Shibboleth target.</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 assertion acceptance window to protect 
+    <p><a href="http://www.ntp.org/">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>
+<h4><a name="2.i."></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 
@@ -558,8 +584,6 @@ and requirements for a successful implementation of a Shibboleth target.</p>
     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>