Enterprise deployments: servicing both web requests and non-web RPC calls simultaneously

[Les Hazlewood <lh...@apache.org>]

In web-enabled environments that also service RPC calls
(RMI/RMI-over-JMS/SOAP/REST/etc), the DefaultWebSecurityManager and some of
its default components (WebRememberMeManager, WebSubjectFactory, etc) use
the following calls:

WebUtils.getRequiredServletRequest()
WebUtils.getRequiredServletResponse()

The problem here is if an RPC call comes in and the transport layer is _not_
HTTP, there will not be any thread-bound servlet request or response.  In
these cases, these calls always throw an IllegalStateException.

But the scenario is logical in enterprise installations - where the
SecurityManager needs to service both web requests and non-web-based RPC
calls simultaneously.  We definitely should support this cleanly.

Question:  Should we continue to force the 'required' check?  Or is it OK
instead to just check to see if the thread-bound objects are null and assume
in these cases the call came in on a non-http remoting invocation?

I think I prefer not requiring the thread-bound request/response pair and
checking for null.  It is certainly the least impact on the code base.  But
this opens up the issue that during test cases, the end-user doesn't need to
set up request/response mocks.  If they don't set up req/resp mocks, they
wouldn't accurately reflect the web-based environment that would exist for
them at runtime when using the JSecurityFilter.

What do you think?

Re: Enterprise deployments: servicing both web requests and non-web RPC calls simultaneously

[Les Hazlewood <lh...@apache.org>]

Keep in mind that the important thing is not an 'either/or' scenario.  Both
web requests and non-web rpc calls should be handled by the same
SecurityManager.  Its my personal opinion that the required check to ensure
valid configuration is mostly unnecessary - you either use the
JSecurityFilter or not.  If you do, you'll have the request/response pair
automatically bound to the thread.

If you can overlook that point, the only thing remaining is test cases -
where you want to guarantee the test writer has bound the pair to the thread
before running the test.  I don't know if that desire trumps a flexible
SecurityManager - I also have to think about it more for a clean way to have
the best of both worlds...

On Wed, Feb 18, 2009 at 4:25 PM, Jeremy Haile <jh...@fastmail.fm> wrote:

> I like keeping the required check - in HTTP web environments, those would
> highlight a misconfiguration problem.  I'm ok renaming WebRememberMeManager
> to HttpRememberMeManager or something if "web" is too broad.  I really think
> RPC scenarios should be need some sort of different ways of accessing
> things.
>
> That being said, I think our model might could be configured better.  For
> example, rather than configuring a WebRememberMeManager, maybe you should
> just configure a DefaultRememberMeManager that can have a set of accessors
> configured - one could be an RmiRememberMeAccessor and another an
> HttpRememberMeAccessor.  Need to think about it more.
>
>
>
>
> On Feb 18, 2009, at 3:38 PM, Les Hazlewood wrote:
>
>  In web-enabled environments that also service RPC calls
>> (RMI/RMI-over-JMS/SOAP/REST/etc), the DefaultWebSecurityManager and some
>> of
>> its default components (WebRememberMeManager, WebSubjectFactory, etc) use
>> the following calls:
>>
>> WebUtils.getRequiredServletRequest()
>> WebUtils.getRequiredServletResponse()
>>
>> The problem here is if an RPC call comes in and the transport layer is
>> _not_
>> HTTP, there will not be any thread-bound servlet request or response.  In
>> these cases, these calls always throw an IllegalStateException.
>>
>> But the scenario is logical in enterprise installations - where the
>> SecurityManager needs to service both web requests and non-web-based RPC
>> calls simultaneously.  We definitely should support this cleanly.
>>
>> Question:  Should we continue to force the 'required' check?  Or is it OK
>> instead to just check to see if the thread-bound objects are null and
>> assume
>> in these cases the call came in on a non-http remoting invocation?
>>
>> I think I prefer not requiring the thread-bound request/response pair and
>> checking for null.  It is certainly the least impact on the code base.
>>  But
>> this opens up the issue that during test cases, the end-user doesn't need
>> to
>> set up request/response mocks.  If they don't set up req/resp mocks, they
>> wouldn't accurately reflect the web-based environment that would exist for
>> them at runtime when using the JSecurityFilter.
>>
>> What do you think?
>>
>
>

Re: Enterprise deployments: servicing both web requests and non-web RPC calls simultaneously

[Jeremy Haile <jh...@fastmail.fm>]

I like keeping the required check - in HTTP web environments, those  
would highlight a misconfiguration problem.  I'm ok renaming  
WebRememberMeManager to HttpRememberMeManager or something if "web" is  
too broad.  I really think RPC scenarios should be need some sort of  
different ways of accessing things.

That being said, I think our model might could be configured better.   
For example, rather than configuring a WebRememberMeManager, maybe you  
should just configure a DefaultRememberMeManager that can have a set  
of accessors configured - one could be an RmiRememberMeAccessor and  
another an HttpRememberMeAccessor.  Need to think about it more.



On Feb 18, 2009, at 3:38 PM, Les Hazlewood wrote:

> In web-enabled environments that also service RPC calls
> (RMI/RMI-over-JMS/SOAP/REST/etc), the DefaultWebSecurityManager and  
> some of
> its default components (WebRememberMeManager, WebSubjectFactory,  
> etc) use
> the following calls:
>
> WebUtils.getRequiredServletRequest()
> WebUtils.getRequiredServletResponse()
>
> The problem here is if an RPC call comes in and the transport layer  
> is _not_
> HTTP, there will not be any thread-bound servlet request or  
> response.  In
> these cases, these calls always throw an IllegalStateException.
>
> But the scenario is logical in enterprise installations - where the
> SecurityManager needs to service both web requests and non-web-based  
> RPC
> calls simultaneously.  We definitely should support this cleanly.
>
> Question:  Should we continue to force the 'required' check?  Or is  
> it OK
> instead to just check to see if the thread-bound objects are null  
> and assume
> in these cases the call came in on a non-http remoting invocation?
>
> I think I prefer not requiring the thread-bound request/response  
> pair and
> checking for null.  It is certainly the least impact on the code  
> base.  But
> this opens up the issue that during test cases, the end-user doesn't  
> need to
> set up request/response mocks.  If they don't set up req/resp mocks,  
> they
> wouldn't accurately reflect the web-based environment that would  
> exist for
> them at runtime when using the JSecurityFilter.
>
> What do you think?