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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]