Shibboleth Developers

["Scott Cantor" <>]

> With IIS7 making a move on FastCGI (to support components using dynamic
> language bindings, a la PHP), its worth spending some investigate-grade
> effort here - to see how a very simple impersonation model will works in
the
> CGI/FastCGI handoff cases

The ISAPI filter already supports those languages because it doesn't rely on
APIs. FastCGI requires that applications themselves use it, and it's not all
that popular.
 
> Still working on having the high-level shib/opensaml/tooling/... packages
> import the log4shib package, in cygwin. How hard can it be to auto-config
an
> include/ and lib/ ?

If you're talking about autoconf, that isn't a function of autoconf, it's
from automake, and it works fine everywhere else. I don't support cygwin, so
if there are bugs there, not much I can say about it.

> 1. Our RDF/SPARQL server can invoke CGIs, and has its query language
script
> has the API call to then impersonate the security context using NT tokens,
> and therefore kerberos tokens.

If you're talking about a web server that isn't a standard server and
doesn't support modules like IIS or Apache, then I couldn't say one way or
the other whether there's any hope of getting the SP to work there. I'm not
trying to implement SAML for everybody.

> CGI may be a way to easily get Shib to
> integrate with that server, rather than the current way (using Ping
> Identity's OpenToken gatewaying/rediecting concept). An alternative would
be
> to put a COM wrapper around the FastCGI entry points so any COM consumer
can
> use the Shib work, including all the .NET world.

Shibboleth only "supports" CGI by integrating with web servers. FastCGI is
not really an exception, because the web server has to support FCGI
authenticators, which are kind of a hack.

The shibsp library isolates the server-specific parts so that you can write
facades for other web servers. But it still requires the web server have an
API to code to. It couldn't operate in a pure CGI environment very easily.
It's possible, but would be a fair amount of work, and would be very
difficult without a lot of wrapper code to make something that was
swiggable.

It's simply not the intended use case for this code.
 
> 2. Has anyone in practice ever operated a shibd on a network port,
> supporting to a variety of handlers over IP? Can Shib multiplex clients
like
> this, with different SP metadata for each?

Yes, but it isn't meant to run that way. Take a look at ADFS. It runs as an
ISAPI filter and talks via RPC to a service locally on the box with IIS to
maintain state. Shibboleth has had the same design.
 
shibd also does not expose an API. It has them, but they are internal to the
implementations of the components that live inside the shibsp library or
extensions. It's a remoting layer that requires each component to provide
both the client and the server in order to remote itself.

-- Scott