Shibboleth Developers

[Walter Hoehn <>]

Hi Nate,

As requested, comments on some of Steven's comments.

-Walter


On Apr 27, 2004, at 12:45 PM, 

 wrote:
> 2) In the intro, para 5, is the "for your operating system" correct?
>
> Please ensure that you have the appropriate .tarball for your 
> operating system.

No, there is a single file that is intended to work across all 
platforms.

> 4) section 2.a, last bullet.. replace this
>
> 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.
>
> with something like -- A Java servlet container. Shibboleth has been 
> extensively tested with Tomcat.

Right, also the "that can host Java servlets" part is confusing... just 
strip that out.

> 6) section 2.d, first sentence  -- does the SHIRE use cert's?

How about we just say "origin and target"?

> 7) section 2.e, 1st para, sentence 3 - " The SHAR provides its own 
> name and the URL of the resource on behalf of which it is making the 
> request." -- update for v1.2

Right, there are actually a few "old" references in this paragraph.

> 9) section 3.a  - mod_jk currently comes with a build glitch.... 
> should we mention this?

I wouldn't here.

> 12) section 3.b, point 8 -- change optional to required?
>
>         SSLVerifyClient optional

I personally think this is the most reasonable default for most folks.  
Anyone else have an opinion?

> 14) section 4.a  remove the 6666 ... we don't want to  encourage 
> anything like that..
>
> AAUrl="http://therock.cc.columbia.edu:6666/shibboleth/AA";

Actually, totally removing the reference to my old workstation at 
Columbia would be nice!

> 15) section 4.a -- I've got a question -- the only RelyingParty 
> element in the sample is named urn:mace:inqueue, but would clearly 
> seem  to be for localhost testing.... is the use of this name going to 
> confuse people, when they move to step 2 (adding an IQ definition to 
> this file....)?

Not sure I understand how it is "clearly for localhost testing".  Looks 
like a standard inqueue setup to me.
> 16) section 4.a - changes to interop in a federation section
>
> -- is the intent to leave localhost operation  intact?

Definitely not in production, but maybe during the "get inqueue working 
phase".  Not sure it matters that much.

> -- Log4JConfig mentions log4j.properties file -- I don't think this is 
> still in the distribution?

So, yes.  We have a default logging mechanism in order make it easier 
to jump right into shib.  With this system, we configure log4j for the 
user, based on some stuff in the origin.xml.  It is also possible for 
the user to point to their own log4j configuration, though.  There is a 
dangling reference to the old system in section 6.b, so please update 
that.


> -- nameMapping, type  description -- "dictates how handles are passed 
> FROM THE HS to the AA.

This is not exactly right.  The identifiers exchanged between origin 
and target can be shibboleth handles, but the purpose of the mapping 
mechanism is to allow support for things other than shibboleth handles.

> -- nameMaping, under principal, add NOTE: if this method  is used, 
> Shibboleth will NOT be providing any privacy protection. The user's 
> identify will  be  transferred to the target by the HS.

Might be good to also note that this wouldn't be a good thing to add to 
the default relying party, for obvious reasons.

> -- RP, point 4, 2nd sentence --  If the providerId value matches a 
> DestinationSite entry in the metadata, and there is a RelyingParty 
> element that has the same providerId as the URI of the the federation, 
> that RelyingParty is used. If not, the default relying party handles 
> the request. (make sure this sentence  is correct....)

Almost.  The Relying Party's "Name" is what is matched against, not its 
providerId.

> -- RP, passthruErrors -- define "relay", and  describe the 
> alernative.....

What happens is that java exception messages get passed in the error 
messages.  The alternative (which should be used in almost all cases), 
is that a generic error message will be sent.  The point here is to not 
leak private information to the target.

> -- RP, current text -> signAttrResponses: If this boolean attribute 
> has a value of true, the attribute response itself will be signed in 
> addition to the security and authentication provided by the SSL 
> session. SAML responses contain one or more assertions. Defaults to 
> false; if true, an https:// AAUrl may be redundant.
>
> is that  last part about https really true? isn't that how the AA 
> validates the SHAR's credentials against what can be used with the 
> supplied providerId?

Right, that text should come out.  SSL provides service provider 
authentication and confidentiality to the transaction.

> -- maxHSThreads -- do we have a "best practice" recommendation value 
> for this?

Yeah, leave it at the default unless you do a bunch of testing to find 
a more optimal value.

> -- passThruErrors -- how would I decide on a reasonable setting for 
> this?

The default, false.  This is generally only used for inter-site 
debugging.

> 24) 5.b.i, sentence 1, 2 - change to?  When a request arrives from a 
> particular relying party, an effective ARP is constructed as follows:

I wouldn't say from a relying party, but from an "application".  NOTE: 
The relying party thing is only a mechanism to select configuration 
data.  It is not an identifier for the requester.