As far as security and authorization goes, where I work we very much view it as, I suppose, a ring around the Olympic rings... perhaps a 100m track? :)
We have completely externalized security from all our applications and have built a fairly robust Security Framework, on top of J2EE security and LDAP. Further, we are now taking customization and adding it in. Currently, once a user is authenticated and authorized, it is only THEN that the application code begins. The application can make simple queries to get basic user info (name, group, whatever attributes are stored in LDAP), but things like "what can this particular user do within this particular app" is still within each app. This is what we are generalizing and moving out to the framework now. We have some good ideas about doing this, and keeping it generic enough to work across-the-board, but I suppose we'll know if we succeeded in a few months. I think validation gets into a whole other problem domain. We haven't come up with that answer yet, Olympic analogy or not :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, July 13, 2005 3:20 pm, Ted Husted said: > On 7/13/05, Borislav Sabev <[EMAIL PROTECTED]> wrote: >> How do you classify Security and Authorization issues in this metaphor? >> >> In my current project I have troubles since code that is related somehow >> to Authorization is spread over all "rings. Still it's difficult to me >> to have a clear understanding how to implement in a nice, consistent >> way. I'll appreciate any suggestions or recommendations about this >> problem. > > The classic Layers pattern describes a systems layer that runs along > all the layers, so that it is adjacent to each one. > > Many Struts applications run into this problem not only with > authorization but with validation. We often want to have some > validation on the client-side, to enhance the user experience and to > reduce load on the server, but, we can't do all the validation > client-side, because there are things that only the server can know. > (Like if the credentials tendered are valid.) > > -Ted. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
