<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>
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 "relying party". 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 "providerId". 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 "applications" 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 "providerId" 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>
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>
<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>
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 "relying party". 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 "providerId". 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 "applications" 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 "providerId" 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
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
<br>
# Per-directory SHIRE Configuration<br>
#ShibBasicHijack On<br>
- #ShibSSLOnly On<br>
- #ShibAuthLifetime 60<br>
- #ShibAuthTimeout 600<br>
<br>
# RM Configuration<br>
#AuthGroupFile /foo<br>
+ #ShibRequireSession On<br>
#ShibExportAssertion On<br>
</Location><br>
</span></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'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>
projects / java-idp.git / commitdiff