Re: Securing DispatchActions

[Dave Newton <ne...@pingsite.com>]

Frank W. Zammetti wrote:
> What if you simply are not allowed to include security
> mechanisms in your application? (configuring groups isn't considered "in
> the application").  

Not allowed? Don't tell 'em ;)

> Well, I can kind of answer my own question... of
> course we *are* allowed to see what group a user is in and act
> accordingly, so yes, I *could* code that sort of thing in a Dispatch-type
> Action.  But then, (a) the benefit of externalized security decreases
> because it isn't quite so external any more, and 

I don't really see any reasonable way around that, though... what if
you're mandated to use a single-URI param-based webapp and only have
LDAP? Well, you work around the limitations of the environment. How? You
can always(-ish) intercept behavior at a higher level, whether through a
filter, URL-rewriting, weberver module, etc.

In any case, I'd be more likely to handle this at a higher, more
abstract level than inside my actual dispatch-style actions via a
request processor, filter, etc. and configure it via a plug-in/etc. that
can deal with whatever external mechanism being used and set things up
appropriately.

> (b) the request isn't
> getting stopped at the boundary, which is what we want, it's still getting
> into my application code to some degree.
>   

Eh, IMO if it gets in to your code but can't execute (much of) anything
I don't see the issue(s), at least on a practical level.

I think we could debate mandate-based "what-if" scenarios until we both
died but ultimately the answer will be the same: you work with or around
whatever you have to work with or around.

Dave



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Securing DispatchActions

["Frank W. Zammetti" <fz...@omnytex.com>]

On Thu, May 4, 2006 2:37 pm, Dave Newton said:
> Frank W. Zammetti wrote:
>> What if you simply are not allowed to include security
>> mechanisms in your application? (configuring groups isn't considered "in
>> the application").
>
> Not allowed? Don't tell 'em ;)

I've done plenty of that :)  Sometimes I actually try to play good
corporate citizen though!

>> Well, I can kind of answer my own question... of
>> course we *are* allowed to see what group a user is in and act
>> accordingly, so yes, I *could* code that sort of thing in a
>> Dispatch-type
>> Action.  But then, (a) the benefit of externalized security decreases
>> because it isn't quite so external any more, and
>
> I don't really see any reasonable way around that, though... what if
> you're mandated to use a single-URI param-based webapp and only have
> LDAP? Well, you work around the limitations of the environment. How? You
> can always(-ish) intercept behavior at a higher level, whether through a
> filter, URL-rewriting, weberver module, etc.

The problem I ran in to is that we have a rather robust security framework
built on top of J2EE security.  It externalizes all our security concerns
from our applications and makes them quite secure and robust.  The other
issue is that while we have our own in-house hosting environment, because
I work for a large corporation, that hosting environment is essentially a
separate entity, and they place a lot of constraints on what we can and
can't do...

<tangent>Oh, how I long for the days when we were a little 250-person shop
and I could walk into the server room and do whatever I wanted, and could
code whatever I wanted, so long as it supported the business :(  But, two
corporate acquisitions later, that is no longer the environment I find
myself in.  There are rules that can't (easily) be broken, lest the
security group sick the hounds on me.</tangent>

> In any case, I'd be more likely to handle this at a higher, more
> abstract level than inside my actual dispatch-style actions via a
> request processor, filter, etc. and configure it via a plug-in/etc. that
> can deal with whatever external mechanism being used and set things up
> appropriately.

I agree, and ultimately I wound up using a filter to deal with the issues
I had at the time.  The problem though is that ultimately, audits throw it
up as a red flag because there is a part of the security mechanism that
now belongs to the application code and not the security framework and
more importantly is managed by the container (both of which are heavily
audited and thus preferred by corporate security).  I can get away with it
once, but I can't push my luck, hence the question about securing multiple
paths, because I know I am not the only one working in such an
environment.

>> (b) the request isn't
>> getting stopped at the boundary, which is what we want, it's still
>> getting
>> into my application code to some degree.
>>
>
> Eh, IMO if it gets in to your code but can't execute (much of) anything
> I don't see the issue(s), at least on a practical level.

This is one place I actually agree with the corporate mandates... if it
were nothing else, it would be a question of liability... if Websphere is
doing all the security, and some hacker gets through, we can place the
blame on IBM.  If it turns out we left a hole, even a very minute one,
then it's on us.  So, if you keep a request from getting into *any*
application code, and allow the container to do that constraining,
liability-wise, it isn't on us.  It's sad that corporations have to think
that way, I don't as a developer in general, but I can certainly
understand their perspective.

> I think we could debate mandate-based "what-if" scenarios until we both
> died but ultimately the answer will be the same: you work with or around
> whatever you have to work with or around.

I agree, but that's why I raised the issue... maybe there *is* a good way
to work around it, but if not, it's worth knowing about the problem. :)

> Dave

Frank

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org