> <Mitch>
> > The goal here is to allow selective access to THEORETICALLY
> secure services
> > without opening them to the world JUST IN CASE.
>
> Mind if I steal that for my presentation.  I just love how that
> sounds!  I guess that pegs me as a security nut.
>

no worries... ;-)

> <Mitch>
> > How will the session be maintained for the remote user?
>
> I'm thinking HTTP 1.1 keep alive.  I don't know if that works over SSL
> but seeing as SSL is a streaming encryption service I can't imagine it
> would change HTTP 1.1 specs too much.  Time for some RFC reading.
>

Don't think keep alive is a good idea - you'd need one apache thread for
every user.... the refresh to the portal keeps the portal from closing down
access until the user either logs out or times out as defined by the captive
portal setup - right dinesh?

> <Mitch>
> > Assumed actions:
>
> Your list is good.
>

Let's see what Dinesh thinks - he knows the existing code and could tell us
how easy it will be.

> <Mitch>
> > SO - here is my quandry... how does the user maintain their session? By
> > keeping the https:// login page option (which could have some sort of
> > meta-refresh to provide a "keep-alive"?)
>
> Do we have to have a meta-refresh?  Doesn't HTTP 1.1 provide a keep
> alive function or does it close the port after a period of inactivity?
>
> <Mitch>
> > I sure see the value in this - just not sure how hard it would be to do.
>
> Close to impossible.  <grin>  Now no matter how hard it is its so much
> easier than I thought!
>
> I really appreciate you guys bouncing this around.  I'm sure it can be
> done and I'm willing to put some effort into it.  I'm pretty good with
> the protocol standards and research and I'm not too shabby at hacking
> on someone else's great work.
>
> Thanks,
>
> Mike
>

I'd like to put this into practice too... I'm just in a position where I
have to put a few MS application servers on the net, and have been fretting
about the best security methods... I like my odds with this idea in play.

thanks!

m/