Skip to Content.
Sympa Menu

shibboleth-dev - RE: SHIRE/SHAR Communication

Subject: Shibboleth Developers

List archive

RE: SHIRE/SHAR Communication


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: "'RL 'Bob' Morgan'" <>
  • Cc: "'Shibboleth Design Team'" <>
  • Subject: RE: SHIRE/SHAR Communication
  • Date: Thu, 24 Jan 2002 22:57:28 -0500
  • Importance: Normal
  • Organization: The Ohio State University

> Along this line, folks here were concerned about how a
> servlet-based SHIRE/SHAR (hmm, probly need a name for The
> Whole Thing) would communicate with a non-Java target
> application (aka RM, I guess), since Java/servlet stuff
> generally doesn't do that. Thoughts?

I'll try and clarify (and Sridhar can jump in if he has any other
opinions).

The SHIRE "acceptance point" is a servlet for now because:

A) It has to respond directly to an HTTP POST, the way any other CGI
response would do, and Java + CGI = servlet.
B) It has to verify an XML signature, practically mandating Java for at
least that one piece.
C) Launching a Java VM per handle acceptance is ugly though possibly
doable.

The rest of the SHIRE and the SHAR are going to be in an Apache module,
in C/C++, the same as any other normal security related
filter/processing agent would be.

In no normal circumstance does a server module ever communicate directly
with any web page or application, except by augmenting the HTTP request
or response with headers (like REMOTE_USER, COOKIE, or others). There
are exceptions but they're not worth discussing.

There is no issue to address with respect to the language of the
SHIRE/SHAR vs. the language of the target application if the RM is
inside the application, whether either, both, or neither are in Java,
Fortran, or RPG. They don't interface directly anyway.

There is a problem to solve for the Java part of the SHIRE to pass state
into the C++ part of the SHIRE/SHAR, but it's similar to the problems of
building Apache modules that share state between forked children anyway,
so it's mandatory to deal with eventually even if we could build the
whole thing in C.

All that said, if there's a shared memory toolkit out there that
supports both C and Java, that would be cool to hear about, but I don't
know of one.

-- Scott

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at

http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--




Archive powered by MHonArc 2.6.16.

Top of Page