Shibboleth Developers

and off we go  again..... fewer comments here, tho.... again, I 
haven't proofed this note.....

1) needs new 1.e etc sections, copied over from the origin guide. 
Actually, my origin comments included some comments on parts of 
section 1; if included, those should also be  copied over.

2) several  places in section 3 reference the mod_cgi, mod_cgid 
mess... since Derek has now fixed this... we can remove all this 
text.... I found this text in:

-- apache 2.0.x

-- RH 9

-- RH Enterprise linux

3) section 3, RH7.2,  bullet one - "The most recent Red Hat RPM 
(1.3.27-2 as of this writing) is sufficient for use with Shibboleth. 
You can use the older version of OpenSSL included, for this release, 
but be advised this may change in the future."

-- I assume  that's a RH RPM for openSSL? Or is the number 
sufficient to identify it?

-- bullet two has an  extra blank line at the start.....

4) section 3.c, number 4 - "By default, the Shibboleth modules are 
configured to log information on behalf of Apache to the file 
/opt/shibboleth/var/log/shibboleth/shire.log, though this can be 
changed."

-- can we point readers  to the section where we describe how to 
change logging parameters?

5) section 3.c,new point 6 -- can we suggest that at this point 
people try the localhost test?

6) section 4.a -- should we move the reference-like description of 
all  the shibboleth.xml elements to section 5 (as we did in the 
origin guide), and leave in section 4.a a description of the minimal 
changes required to get into a federation, followed by a 
recommendation to test that minimal config against the Fed's test 
target?

7) Application, Applications element, providerId attribute value..... 
my current understanding is that this value will  have to be provided 
to the Federation, for  inclusion in the metadata? If that's true, I 
think we should mention that likelihood.....

8) Applications element; "The Applications element must appear once 
and contains default settings for requests handled by the target 
whose applicable request mapping using matching Host and Path 
elements has no declared applicationId attribute."

-- it also provides default values, in case an Application element 
doesn't override particular values.....

9) Audience -- "The Audience element is used in the Policy element to 
specify one or more SAML audience URIs to treat as valid while 
processing assertions."

-- worth explicitly stating that these are audience values included 
by origins, in the assertions?

10) Credentials -- "This element is the container for credentials 
used by the XML-based credentials provider with type 
"edu.internet2.middleware.shibboleth.common.Credentials" It must 
contain one or more FileResolver elements."

-- thinking of our typical audience members .... I'd suggest  we 
state explicitly that these are the credentials the target uses for 
signing and for creating SSL sessions.

11) CredentialUse -- "Required in the Applications element or 
overridden in Application elements, ..."

-- I'd suggest "... or used within an Application element to override 
the defaults"

"May also contain RelyingParty elements that override the credentials 
to use for specific origins or federations."

I'd suggest replacing override with specify

12) Errors - last sentence...  "The last two attributes are examples 
of tags that can be inserted at runtime into the templates. Arbitrary 
attributes can be used."

-- not sure what the last sentence  means.....

13) FederationProvider  .. "This should be updated regularly" suggest 
changing updated to refreshed.

14) Path  -- requireSession -- "If false (the default), applications 
are responsible for ensuring that a session exists if necessary, 
so-called lazy session establishment."

-- ummmm... do we really want the default here to be  FALSE?

15) RequestMap

-- "Each RequestMap element contains a set of hosts, URLs, and 
applications that all share the same rules on session and assertion 
requirements in the form of individual Host elements."

perhaps... The RequestMap element is a container holding Host and 
Path elements. The requesting URL is parsed and then mapped into this 
setof elements, in order to determine how to process the request. 
Attributes on the RequestMap, Host, and Path elements  specify 
whether to require a Shibboleth session, and  how  to locate the 
associated Application element.

-- again... right default  on requireSession?

-- there's no description of the uri attribute.....

16) RelyingParty

-- no trailing " after the TLS value

-- "name: Identifies the origin site or group of sites to which the 
credentials specified in the element apply."

I suppose I'm supposed to know this by this point...... but I 
don't.... where does the target obtain the value that it compares 
against the name value of this  element?

17) Sessions -- "If default ports are used (and thus left 
unspecified), browsers will generally return cookies set via SSL to a 
non-SSL server."

-- should the last word be port, not server?

-- "cookieName: Optionally specifies the name given to in-memory 
session cookies that are associated with this application. If 
ommitted, Shibboleth will generate a cookie name for you of the form"

-- too many mmmm's in omitted

18) TCPListener -- "This element must be contained by the SHAR 
element and is mutually exclusive with the TCPListener and Listener 
elements."

change TCPListener to UnixListener

-- "address: Specifies the address of the listener."  IP address?

19) TrustProvider

change updated -> refreshed

20) Section 4b

<shibmlp tag-name /> -- does case matter?

--- "The value of the logoLocation 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."

-- ? "This is provided as a convenience for filling in the template 
error page; if a custom error page is created, then the image should 
be linked to statically"

21) section 4.c - last paragraph -- does calist still exist?  replaced?

22) section4.d - "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  ShibMapAttribute command, but this has been replaced 
with additional features in the AAP syntax, described in section 4.e. 
This applies to both Apache and IIS."

-- I think at this point we can  safely drop the "formerly" stuff....

-- under Apache... suggest replacing first paragraph with:

The Apache RM module provided can interpret AAP settings to map 
attributes to HTTP request headers and to Require rules, permitting 
protecting of both static and dynamic content. Any of the typical 
ways of protecting content may be used (.htaccess, Directory, 
Location, Files, etc.). They define what content is to be protected 
and static access control rules.

and removing 1st sentence of second para

whew -- that's as far as I got.......