You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by Jasha Joachimsthal <j....@onehippo.com> on 2011/09/21 14:56:49 UTC
Shibboleth login
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?
[1] https://manager.aaf.edu.au/wiki/display/mgtpac/Home
Jasha Joachimsthal
Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466
US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll free)
www.onehippo.com
Re: Shibboleth login
Posted by Stein Welberg <st...@everett.nl>.
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<at...@douma.nu> 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
>>
>
Re: Shibboleth login
Posted by Ate Douma <at...@douma.nu>.
On 09/21/2011 03:52 PM, Jasha Joachimsthal wrote:
> On 21 September 2011 15:38, Ate Douma<at...@douma.nu> 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?
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.
>
> Jasha
>
Re: Shibboleth login
Posted by Jasha Joachimsthal <j....@onehippo.com>.
On 21 September 2011 15:38, Ate Douma <at...@douma.nu> 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.
Jasha
Re: Shibboleth login
Posted by Ate Douma <at...@douma.nu>.
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?
Ate
>
> [1] https://manager.aaf.edu.au/wiki/display/mgtpac/Home
>
> Jasha Joachimsthal
>
> Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466
> US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll free)
>
> www.onehippo.com
>