What is Shib Daemon used for?
Yaowen Tu
yaowen.tu at gmail.com
Tue Jul 10 22:34:27 BST 2012
Thank you so much Scott. That is a really awesome answer, which also
addressed some other questions in my mind.
Really appreciated.
Best,
Yaowen
On Tue, Jul 10, 2012 at 12:26 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 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
>
> --
> To unsubscribe from this list send an email to
> dev-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20120710/7a5bbe11/attachment.html
More information about the dev
mailing list