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