Skip to Content.
Sympa Menu

shibboleth-dev - Re: Shibboleth v1.3 beta, additional information

Subject: Shibboleth Developers

List archive

Re: Shibboleth v1.3 beta, additional information


Chronological Thread 
  • From: Tom Scavo <>
  • To: Walter Hoehn <>
  • Cc: Jim Fox <>, Steven Carmody <>, Shibboleth Development <>
  • Subject: Re: Shibboleth v1.3 beta, additional information
  • Date: Tue, 7 Jun 2005 08:51:06 -0400
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Su0K9ag0S71ZSEEO4ON70VDg8sPmg/5mL1+MbSlvrnf7Xvgac50tKks2jJU5c7sz5OEoqxDvrVa/jU+AWK7KPB0jXxnMPdZWIK4B0O8O7xvYKIji+l65qsnBaOTKC28CmDD8e1o8Jj3q7YXrinBOPdYEoTYzjJgU49McmGFNqgw=

On 6/2/05, Walter Hoehn
<>
wrote:
> There are a couple of historical reasons for our previous
> recommendations that folks front-end tomcat with apache.
>
> 1) Efficiency...
>
> 2) It used to be the case with apache 1.x that one could run the SSO
> and AA endpoints on a single vhost and use SSL re-negotiation to
> force the client authentication for the AA path alone. This meant
> that all shibboleth endpoints could be run on the standard ports.
> Apache 2 does not support this configuration.

Nor does Tomcat AFAIK. By the way, if that's true, why does 1.3 ship
with both IdP endpoints configured to run on a single port?

> 3) Logging...
>
> So, all of our historical reasons may be a wash, but there is a new
> twist. The 1.3 IdP validates SSL clients against the SAML2 metadata
> and it is advantageous to be able to configure the web-server to not
> do the validation. I'm not %100 sure(I haven't dug into this code in
> a long time), but I don't think that tomcat can do this.

Well, the Connector element in server.xml has a clientAuth attribute
with possible values false|want|true. Setting it to false, a test
flow in 1.3 runs to completion but the following output is appended to
the IdP shib-access.log:

2005-06-06 20:01:06,184 Attribute assertion generated for provider
(null) on behalf of principal (gridshib) with the following
attributes: (urn:mace:dir:attribute-def:eduPersonAffiliation)
2005-06-06 20:01:06,204 Attribute assertion issued to anonymous legacy
provider at (127.0.0.1) on behalf of principal (gridshib).

Does this suggest the attribute exchange is not being conducted over
SSL? (There's not much else in the logs to suggest one or the other.)

> Aside from
> the extra pkix validation required, the fallout is that
> configurations using tomcat would probably need have a process for
> taking the union of all anchors from the metadata and stuffing them
> into tomcat's trust store.

Well, setting clientAuth="want" in server.xml, we get the errors
reported in thread "Tomcat 5.0.28, Java 1.4, Shib java SP, Mac OS
10.3" now running in shibboleth-users, so server validation is not
working at this point.

Tom



Archive powered by MHonArc 2.6.16.

Top of Page