Revised 1.e-1.g in concepts section of both docs.
authorcantor <cantor@ab3bd59b-922f-494d-bb5f-6f0a3c29deca>
Tue, 27 Apr 2004 03:51:47 +0000 (03:51 +0000)
committercantor <cantor@ab3bd59b-922f-494d-bb5f-6f0a3c29deca>
Tue, 27 Apr 2004 03:51:47 +0000 (03:51 +0000)
git-svn-id: https://subversion.switch.ch/svn/shibboleth/java-idp/trunk@1017 ab3bd59b-922f-494d-bb5f-6f0a3c29deca

doc/DEPLOY-GUIDE-ORIGIN.html
doc/DEPLOY-GUIDE-TARGET.html

index 27ab471..41ef8e9 100644 (file)
@@ -178,8 +178,9 @@ that arises. Please ensure that you have the
         <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>
-        <li><a href="#1.e."><font color="black">Relying Parties and Applications</font></a></li>
-        <li><a href="#1.f."><font color="black">Sessions</font></a></li>
+        <li><a href="#1.e."><font color="black">Relying Parties</font></a></li>
+        <li><a href="#1.f."><font color="black">Applications</font></a></li>
+        <li><a href="#1.g."><font color="black">Sessions</font></a></li>
     </ol>
     </li>
     <li>
@@ -376,69 +377,86 @@ requesting attributes.</p>
     information on local authentication and authorization practices for 
     federation members.</p>
 </blockquote>
-<h4><a name="1.e."></a>1.e. Relying Parties and Applications</h4>
+<h4><a name="1.e."></a>1.e. Relying Parties</h4>
 <blockquote>
-    <p>A Shibboleth relying party allows a deployment to select a particular
-    configuration to use when processing a request.  Certificates, policies, and
-    other aspects of an interaction are specified on a relying party basis, and
-    may or may not vary between relying parties depending on the deployment's
-    needs.  Each relying party may support a number of different
-    applications.</p>
-    <p>Frequently, an entire federation will be viewed by an origin or target as
-    a single relying party; however, there is no necessary binding between
-    these.  An individual origin or target with which this deployment exchanges
-    information may sometimes be part of multiple relying parties if there are
-    multiple trust agreements under which these transactions are performed.</p>
-    <p>Applications as viewed from Shibboleth are not necessarily defined by the
-    same metrics as in other contexts.  An individual application represents a
-    service or set of services that operates using the same attribute and trust
-    features and shares common <a href="#1.f.">Shibboleth sessions</a>.
-    Attributes are released to targets on the basis of individual applications,
-    while other transactional details such as certificates and timeouts will be
-    specified by relying party.  An application may span multiple URL trees and
-    servers depending on the architecture of the service.  Each application is
-    assigned an individual application identifier URN which must be recognized
-    by both the origin and the target.  In any individual request, both the
-    relying party and application are consulted to acquire a complete set of
-    configuration to ensure proper release.</p>
+    <p>Some aspects of both origin and target configuration can vary and be
+    expressed in terms of the &quot;relying party&quot;. To an origin, a target
+    is a relying party, while targets consider origins to be relying
+    parties (it's a matter of perspective). Certificates, policies, and
+    other aspects of an interaction are specified on the basis of the relying
+    party, and may or may not vary between relying parties depending on the
+    deployment's needs.</p>
+    <p>Each origin and target is assigned a URI, a unique identifier to enable
+    control over configuration down to the level of an individual partner (a single
+    relying party). By convention, this is termed a &quot;providerId&quot;. More
+    frequently, an entire federation will be viewed by an origin or target as a
+    single relying party to simplify management. An individual origin or target
+    with which this deployment exchanges information may sometimes be part of
+    multiple relying parties if there are multiple trust agreements
+    under which these transactions are performed. Care should be taken to avoid
+    conflicting or inconsistent configuration in such cases.</p>
 </blockquote>
-<h4><a name="1.f."></a>1.f. Sessions</h4>
+<h4><a name="1.f."></a>1.f. Applications</h4>
 <blockquote>
-    <p>There are many different types of sessions that can be established within
-    the context of the access of Shibboleth-protected webspace.  This webspace
-    is subdivided by the target into individual <a
-    href="#1.e.">applications</a>, each of which maintains separate sessions
-    with the user's browser using cookies.  However, the HS never interacts with
-    these applications; it views the webspace partitioned by providerId.  It is
-    important to note that all sessions in this section are all independent and
+    <p>Shibboleth &quot;applications&quot; are the primary unit of target
+    configuration. Applications as viewed by the target implementation
+    are not necessarily defined by the same metrics as in other contexts.  An
+    individual application represents a set of web resources that operates
+    using the same attribute handling and trust configuration and shares a common
+    <a href="#1.g.">session</a> with the browser user. As a user navigates between
+    resources on a server that cross an application boundary, a new session is
+    established, though user interaction may not be required. As a consequence of
+    the relationship between applications and sessions (which are tracked with
+    a cookie), an application usually does not span more than one virtual host.
+    Apart from cookie-based constraints, web resources can be aggregated into
+    applications in arbitrary ways.</p>
+    <p>A single target deployment may support a large number of applications,
+    but it need not register or publish information about each one with the
+    origins it accepts information from. Instead it can communicate using a
+    more limited set of distinct &quot;providerId&quot; values (often just a
+    single one). This allows targets with a complex internal configuration
+    to be treated as a single entity by origins for the purposes of attribute
+    release.</p>
+</blockquote>
+<h4><a name="1.g."></a>1.g. Sessions</h4>
+<blockquote>
+    <p>Much of the target implementation is concerned with establishing, and
+    subsequently maintaining, sessions with the browser user on behalf of the
+    <a href="#1.f.">applications</a> at the target. A session consists of a
+    cookie passed between the browser and web server, associated with a
+    security context. The context contains the user's authentication information,
+    and generally a set of attributes that make up the user's identity. Each
+    application maintains distinct sessions with the browser by means of separate
+    cookies. It is important to note that all such sessions are independent and
     distinct: any session can exist with or without any other session, and the
     expiration of any one session does not imply the expiration of any other
-    session.  Shibboleth does not support any logout functionality beyond the
+    session.  Shibboleth also does not support any logout functionality beyond the
     termination of individual application sessions by deletion of respective
-    cookies; there is no way for the target to cause origin-side sessions, such
-    as a user's SSO login, to expire.</p>
-    <p>The successful access of a Shibboleth-protected resource by a browser
-    user may have two outcomes: standard session establishment, and lazy session
+    cookies; also, there is no way for the target to cause origin-side sessions,
+    such as a user's SSO login, to expire.</p>
+    <p>A browser user accessing a Shibboleth-protected resource may have two
+    outcomes: standard session establishment, and lazy session
     establishment.  The standard session establishment mechanism in which
     Shibboleth protects the resource in all circumstances results in the
     establishment of a cookie-based browser session and a set of attributes
     cached for that application. Shibboleth 1.2 also supports so-called lazy
     session establishment, in which the resource may be accessed without prior
     authentication.  This means the application must be intelligent enough to
-    determine whether authentication necessary, and then construct proper URL's
-    to initiate the browser redirect to request authentication; if the
+    determine whether authentication is necessary, and then construct the proper URL
+    to initiate a browser redirect to request authentication; if the
     application determines none is necessary or uses other authorization
-    mechanisms, then an attribute request does not need to be triggered.  This
-    complex functionality is mostly useful to protect a single URL with
-    different access mechanisms, or to require attribute requests only in the
-    instance where the application deems it necessary.</p>
+    mechanisms, then the request for authentication may not need to be triggered.
+    This complex functionality is mostly useful to protect a single URL with
+    different access mechanisms, or to require authenticated access only in
+    instances where the application deems it necessary.</p>
     <p>Independently of this, a web-based application protected by Shibboleth
     may have a need to establish its own session with the user.  This session
-    may persist well beyond either Shibboleth session, and logouts from this
-    session, if supported, will not terminate Shibboleth sessions initiated to
+    may persist well beyond the Shibboleth session, and logouts from this
+    session, if supported, will not terminate a Shibboleth session initiated to
     access the resource.  Application administrators should carefully evaluate
     the expiration of all sessions to limit vulnerability to attacks or user
-    negligence.</p>
+    negligence. Logging out of the entire desktop session is usually the
+    only (relatively) foolproof logout mechanism on the web.</p>
 </blockquote>
 <hr>
 <h3><a name="2."></a>2. Planning</h3>
@@ -457,8 +475,8 @@ requirements for a successful implementation of a Shibboleth origin.</p>
     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 Linux and Solaris, but should function on 
-    any platform that has a Tomcat implementation.</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>It is recommended that a web server must be deployed that can host Java 
     servlets and Tomcat, although not explicitly necessary, as Tomcat can still 
     host an origin without it.</li>
index 07f4f52..1051d22 100644 (file)
@@ -174,6 +174,9 @@ that arises.</p>
         <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>
+        <li><a href="#1.e."><font color="black">Relying Parties</font></a></li>
+        <li><a href="#1.f."><font color="black">Applications</font></a></li>
+        <li><a href="#1.g."><font color="black">Sessions</font></a></li>
     </ol>
     </li>
     <li>
@@ -340,6 +343,87 @@ requesting attributes.</p>
     there should be a way to find information on local authentication and 
     authorization practices for federation members.</p>
 </blockquote>
+<h4><a name="1.e."></a>1.e. Relying Parties</h4>
+<blockquote>
+    <p>Some aspects of both origin and target configuration can vary and be
+    expressed in terms of the &quot;relying party&quot;. To an origin, a target
+    is a relying party, while targets consider origins to be relying
+    parties (it's a matter of perspective). Certificates, policies, and
+    other aspects of an interaction are specified on the basis of the relying
+    party, and may or may not vary between relying parties depending on the
+    deployment's needs.</p>
+    <p>Each origin and target is assigned a URI, a unique identifier to enable
+    control over configuration down to the level of an individual partner (a single
+    relying party). By convention, this is termed a &quot;providerId&quot;. More
+    frequently, an entire federation will be viewed by an origin or target as a
+    single relying party to simplify management. An individual origin or target
+    with which this deployment exchanges information may sometimes be part of
+    multiple relying parties if there are multiple trust agreements
+    under which these transactions are performed. Care should be taken to avoid
+    conflicting or inconsistent configuration in such cases.</p>
+</blockquote>
+<h4><a name="1.f."></a>1.f. Applications</h4>
+<blockquote>
+    <p>Shibboleth &quot;applications&quot; are the primary unit of target
+    configuration. Applications as viewed by the target implementation
+    are not necessarily defined by the same metrics as in other contexts.  An
+    individual application represents a set of web resources that operates
+    using the same attribute handling and trust configuration and shares a common
+    <a href="#1.g.">session</a> with the browser user. As a user navigates between
+    resources on a server that cross an application boundary, a new session is
+    established, though user interaction may not be required. As a consequence of
+    the relationship between applications and sessions (which are tracked with
+    a cookie), an application usually does not span more than one virtual host.
+    Apart from cookie-based constraints, web resources can be aggregated into
+    applications in arbitrary ways.</p>
+    <p>A single target deployment may support a large number of applications,
+    but it need not register or publish information about each one with the
+    origins it accepts information from. Instead it can communicate using a
+    more limited set of distinct &quot;providerId&quot; values (often just a
+    single one). This allows targets with a complex internal configuration
+    to be treated as a single entity by origins for the purposes of attribute
+    release.</p>
+</blockquote>
+<h4><a name="1.g."></a>1.g. Sessions</h4>
+<blockquote>
+    <p>Much of the target implementation is concerned with establishing, and
+    subsequently maintaining, sessions with the browser user on behalf of the
+    <a href="#1.f.">applications</a> at the target. A session consists of a
+    cookie passed between the browser and web server, associated with a
+    security context. The context contains the user's authentication information,
+    and generally a set of attributes that make up the user's identity. Each
+    application maintains distinct sessions with the browser by means of separate
+    cookies. It is important to note that all such sessions are independent and
+    distinct: any session can exist with or without any other session, and the
+    expiration of any one session does not imply the expiration of any other
+    session.  Shibboleth also does not support any logout functionality beyond the
+    termination of individual application sessions by deletion of respective
+    cookies; also, there is no way for the target to cause origin-side sessions,
+    such as a user's SSO login, to expire.</p>
+    <p>A browser user accessing a Shibboleth-protected resource may have two
+    outcomes: standard session establishment, and lazy session
+    establishment.  The standard session establishment mechanism in which
+    Shibboleth protects the resource in all circumstances results in the
+    establishment of a cookie-based browser session and a set of attributes
+    cached for that application. Shibboleth 1.2 also supports so-called lazy
+    session establishment, in which the resource may be accessed without prior
+    authentication.  This means the application must be intelligent enough to
+    determine whether authentication is necessary, and then construct the proper URL
+    to initiate a browser redirect to request authentication; if the
+    application determines none is necessary or uses other authorization
+    mechanisms, then the request for authentication may not need to be triggered.
+    This complex functionality is mostly useful to protect a single URL with
+    different access mechanisms, or to require authenticated access only in
+    instances where the application deems it necessary.</p>
+    <p>Independently of this, a web-based application protected by Shibboleth
+    may have a need to establish its own session with the user.  This session
+    may persist well beyond the Shibboleth session, and logouts from this
+    session, if supported, will not terminate a Shibboleth session initiated to
+    access the resource.  Application administrators should carefully evaluate
+    the expiration of all sessions to limit vulnerability to attacks or user
+    negligence. Logging out of the entire desktop session is usually the
+    only (relatively) foolproof logout mechanism on the web.</p>
+</blockquote>
 <hr>
 <h3><a name="2."></a>2. Planning</h3>
 <p>There are several essential elements that must be present in the environment 
@@ -1739,9 +1823,8 @@ checkAddress=&quot;<i>true/false</i>&quot;&gt;</span></dd>
 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>
+please mail <a href="mailto:shibboleth-users@internet2.edu">shibboleth-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 
@@ -1757,12 +1840,10 @@ configurations used.</p>
         <br>
         &nbsp;&nbsp;# Per-directory SHIRE Configuration<br>
         &nbsp;&nbsp;#ShibBasicHijack On<br>
-        &nbsp;&nbsp;#ShibSSLOnly On<br>
-        &nbsp;&nbsp;#ShibAuthLifetime 60<br>
-        &nbsp;&nbsp;#ShibAuthTimeout 600<br>
         <br>
         &nbsp;&nbsp;# RM Configuration<br>
         &nbsp;&nbsp;#AuthGroupFile /foo<br>
+        &nbsp;&nbsp;#ShibRequireSession On<br>
         &nbsp;&nbsp;#ShibExportAssertion On<br>
         &lt;/Location&gt;<br>
         </span></p>
@@ -1775,9 +1856,9 @@ configurations used.</p>
 <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">
+    <a href="https://umdrive.memphis.edu/wassa/public/shib.faq/shibboleth-faq.html">
     Shibboleth Deployer&#39;s FAQ</a>. Please mail
-    <a href="mailto:mace-shib-users@internet2.edu">mace-shib-users@internet2.edu</a> 
+    <a href="mailto:shibboleth-users@internet2.edu">shibboleth-users@internet2.edu</a> 
     with any additional questions or problems encountered that are not answered 
     by this basic guide.</p>
 </blockquote>