What is Shib Daemon used for?

[Cantor, Scott]

On 7/10/12 2:58 PM, "Yaowen Tu" <yaowen.tu at gmail.com> wrote:
>
>Per Scott's request, I am ask the question again in the dev list.

Thank you.

>Can you explain a little bit more about this?
>    Nevertheless it is required because I don't have the luxury of
>relying on
>language-specific, proprietary session mechanisms.
>
>I not quite sure that I understand this.

How would you propose to maintain a session for a web application if you
can make no assumption about the application environment, language, or
tools, and that consists of arbitrarily large data that needs to be kept
protected from exposure?

One option is to chunk, encrypt, and sign data into cookies. That is not
generically feasible unless you assume the data size you're dealing with,
or ignore clients of certain types, and it's complex and fairly
inefficient in bandwidth and performance.

The other option is server-side state indexed by a cookie or form field or
whatever.

Server-side state is impossible in most commodity web servers because
they're multi-process. So you have to put the state somewhere. In the SP,
it's in a storage service that is by default a memory cache in shibd. It
can be in memcache, a database, or anywhere else a plugin sends it.

Architecturally, it's possible to build the SP in a manner that relies on
an external storage plugin, but runs everything that is normally in shibd
in-process. That would obviate the need for shibd. The code can do this,
apart from flushing out bugs I'm sure, it's just not something the build I
maintain supports.

>Also can you give me a small explain why you choose to implement SP in
>C++ while IdP in Java? Is there any specific reason to do that?

Many reasons. I strongly prefer C++ to any other language. I can get more
done in C++ than I can in languages I don't like or know well. It's also a
lot faster without special effort, which means I can focus on writing code
and not worrying about speed much.

Most importantly, Java solves one problem, Java. With its fragmented
security model, it doesn't have one integration strategy, so I can't even
address every Java case with one solution. The same is more or less true
of most Java alternatives.

C++ solves problems for practically any web language because it works in
Apache, IIS, and FastCGI. I'm not trying to solve every problem in the
world, and I can't. I can solve more problems at once, as a single
developer, using this approach than I can by writing in other languages,
and at the same time I limit people to an integration model that, whether
they like it or not, gives them the freedom to rip out my solution and
plugin another. I value that more than I value locking in people with APIs
in the guise of "better platform coverage".

One of the decisions that comes up a lot is whether to invest time in
wrappers that would expose what I did to other languages. The problem is
that I don't perceive a willingness by such language adopters to accept
native code. That's not a surprise since losing the ability to deploy "on
top" of the stack with no root access or ability to install packages on an
OS is one of the big drivers for those environments.

Hope that answers some of your questions.

-- Scott