Shibboleth Developers

[Chad La Joie <>]

Tom Scavo wrote:
> On 6/2/05, Walter Hoehn 
> <>
>  wrote:
>>
>>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?

Actually I think it does, if I'm understand the issue correctly (which I
probably don't).  You can use security constraints to protect different
paths in the same webapp context.  So, in this case, the AA (/AA) can be
protected with a client-cert authentication while the HS (/SSO) can be
protected with BASIC auth over a standard SSL connection, for example.
So, the request for both can go to port 443 (or whatever you're using
for SSL connections) and each can be handled in the "correct" way, based
on the constraints you define.

>>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.

Out of the box Tomcat probably can't do this, but I'm guessing a
connector/socket factory could be written to do this pretty easily if
this is desired behavior.

> 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.)

I'm not sure what the code does, but this need not be the case.  It
could be transmitting it over a normal SSL connection (where just the
server side is validated).
-- 
Chad La Joie             315Q St. Mary's Hall
Project Sentinel         202.687.0124