Hi Guys, I've been helping Jasha with the shibboleth integration for Rave. See my comments inline :).
On Sep 21, 2011, at 4:21 PM, Ate Douma wrote: > On 09/21/2011 03:52 PM, Jasha Joachimsthal wrote: >> On 21 September 2011 15:38, Ate Douma<[email protected]> wrote: >> >>> On 09/21/2011 02:56 PM, Jasha Joachimsthal wrote: >>> >>>> We've configured Rave to use our (internal) Shibboleth for authentication >>>> using [1] as example. >>>> The configuration is not something we can add to the demo portal to work >>>> out >>>> of the box but it can be documented. Are there any objections if I would >>>> add >>>> the (slightly modified) java code to the Rave portal? >>>> >>> >>> I'd like to see Shibboleth *supported* by Rave. >>> If we add code for this in "core" Rave, we should be able to use and >>> demonstrate it, so I'd want "full" (even if only limited) support ;) >>> Otherwise, it will not be possible by the Rave team itself to ensure and >>> validate proper operation and behavior and actually could then become more >>> of a problem than a benefit. >>> >>> If however you only can provide a "half-way" solution, I think it might be >>> better to keep it outside "core" Rave, e.g. only as exemplar >>> code/configuration. >>> >> >>> Can you enlighten us why you can't provide a complete functionality? >>> Is it just too much work, or too dependent on the custom environment. In >>> the latter case, what would be effort to generalize your solution which >>> would work both for Rave and in your own environment? >>> >> >> It depends on response headers returned by Shibboleth so you need a running >> instance. Of course it is possible to create some demo URL that returns >> these headers with predefined values. > That, or having a demo/test Shibboleth server available to connect to maybe? There aren't any test shibboleth servers since it closely integrates with a number of web servers (e.g. apache httpd). You normally run an httpd server that has a Shibboleth module. This module handles the authentication and sets a number of apache header attributes. The actual web application is behind the httpd server (e.g. using mod_proxy) so that the web application can read the headers. It is very important that a user cannot access the web application directly, for header forgery is possible that way. Hence, for a successful test setup somewhere on the internet you would have to have access to the httpd configuration. > For instance, for OpenId authentication we don't have that running ourselves > either... > > And, AFAIK it should be relatively easy to install/incorporate a simple > OpenId server ourselves inside Rave but I suspect that might not be so > trivial with Shibboleth. In my opinion the best way to locally test the shibboleth configuration is to run a small servlet that fakes shibboleth and sets some (configurable) headers. Regards, Stein Welberg > > >> >> Jasha >> >
