Shibboleth Developers

["RL 'Bob' Morgan" <>]

On Fri, 31 Oct 2003, Howard Gilbert wrote:

> Sometimes it is not good enough to maybe share classes. Sometimes you
> even want to share objects.

So I think you're asking here whether we have requirements for two apps
relying on the same SHIRE/SHAR (hmm, we really need a proper name for
this, like "Shibboleth target service" or something) to share objects with
each other via the SHIRE/SHAR?  I don't see that this is a requirement,
but maybe others do.

> If you go with the first model, where the SHIRE/SHARE represent some
> classes that form basically a "layer" in the request processing, then
> Shibboleth processing can be done through a Servlet Filter that
> front-ends the application and there is no need for a final redirection.

Hmm, I'm not an expert on this, but it's my impression that if a
browser/app interaction is supposed to be done via a GET, turning it into
a POST is likely to break things.  More generally I think the Shib model
is that the post-POST redirection (as it were) uses whatever the original
(or application-desired) method is, in order to be as transparent to the
app as possible.  Shib doesn't currently support that final method being a
POST, but I think this is very desirable at some point.  So we should
design with this generality in mind, IMHO.

> The alternate design is to create a single Web Service model used both
> locally and remotely.

Seems to me the right design is to provide an API that apps use, and
provide both efficient-local and transportable-remote implementations of
it.  Which I think you describe somewhere else in your note?

> 1) What does the getUserAttribute() method look like and how is it
> chained to the extended Request object? Do we need any other methods to
> force session termination or other lifecycle things?

I think we do, or we will eventually when logout is supported in some
form.  What are the operations provided by the current ONC RPC interface?

 - RL "Bob"