Re: [OT] olipmic rings metaphor - LDAP?
Frank W. Zammetti wrote: Not sure I have an answer for that :) My guess would be because of the first letter in the acronynm: Lightweight. Otherwise, your question seems reasonable to me. Yep, the 'lightweight' is certainly a key factor. LDAP is optimized toward high read volume, low write volume applications so directories can genereally serve queries faster than RDBMSs at the expense of slower updates. In practice, though, LDAP is non-transactional and a poor substitute for a database if you need to do more than provide a repository for user profile information. LDAP directories are typically used for identity management solutions, for centralizing user profile data and for 'white pages' type contact databases. L. -- Laurie, Open Source advocate, Java geek and novice blogger: http://www.holoweb.net/~laurie/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] olipmic rings metaphor - LDAP?
Not sure I have an answer for that :) My guess would be because of the first letter in the acronynm: Lightweight. Otherwise, your question seems reasonable to me. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Fri, July 15, 2005 6:41 am, Adam Hardy said: > Frank W. Zammetti on 14/07/05 17:39, wrote: > 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. > > > Going slightly OT but the thread's OT anyway, why does LDAP exist or why > does it get used so much? What advantages does it have over a database, > which all applications have anyway? Why add another technology to the mix? > > - > 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]
Re: [OT] olipmic rings metaphor - LDAP?
LDAP is commonly used for security systems (for example: M$ Active Directory and Novell's NDS are both LDAP implementations), and so using them for applications (instead of a database) lets you leverage existing security settings so you do not have to duplicate them. Larry On 7/15/05, Adam Hardy <[EMAIL PROTECTED]> wrote: > Frank W. Zammetti on 14/07/05 17:39, wrote: > 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. > > > Going slightly OT but the thread's OT anyway, why does LDAP exist or why > does it get used so much? What advantages does it have over a database, > which all applications have anyway? Why add another technology to the mix? > > - > 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]
Re: [OT] olipmic rings metaphor - LDAP?
Frank W. Zammetti on 14/07/05 17:39, wrote: 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. Going slightly OT but the thread's OT anyway, why does LDAP exist or why does it get used so much? What advantages does it have over a database, which all applications have anyway? Why add another technology to the mix? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] olipmic rings metaphor
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]
Re: [OT] olipmic rings metaphor
Martin Gainty wrote: Boris- I see Security as implemented by RingBearer Frodo in Lord of the Rings The caretaker of the ring travels thru all domains and access to the other dimension (portal which contains final results) regardless of any domain he travels thru Begreife? Martin- Since I'm not a big fan of Frodo and company, I like the Ted's methaphor of torch much understandable (at least for me) :-) Anyway the idea behind is the same. BTW, i often use ThreadLocals to save such objects that have to make a round trip through all the layers - but this is not a universal approcah. Regards Borislav (or Boris) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] olipmic rings metaphor
On 7/14/05, Ted Husted <[EMAIL PROTECTED]> wrote: > One way to address customization is to build the notion of a user > profile into the application. The user profile can contain the > information each ring might require to customize the user experience. Which to further the olympics metaphor, would make the profile a torch that each ring hands off to the next :) -T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] olipmic rings metaphor
On 7/14/05, Borislav Sabev <[EMAIL PROTECTED]> wrote: > I fully agree here, that's why I consider Authorization as a ring that > intersect all other rings, and this means it depend on each of them. > But it fact better metaphor for it is that is a small ring inside every > other ring, i.e. not seen as one monolithic ring. Another word for authorization might be customization. In the case of authorization, we are imposing customization, but many applications have users that wish to customize how the application behaves. They might want to use a different skin, or have a different number of items appear in a result list, or start on a different page of the application. One way to address customization is to build the notion of a user profile into the application. The user profile can contain the information each ring might require to customize the user experience. We are doing this at work now. If a user agent doesn't already have a profile, the first thing we do is create one. The profile is passed up to the business layer with each business request, and the business commands make some decisions based on the user's profile. Of course, profiles are not for everyone. You have to store the profile somewhere, and that usually means using session state (if you want it to be secure). Now that we have sticky bits, session isn't the red flag it used to be, but some applications still have to choose between scalability and customization. And, that's what engineering is about: choosing. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] olipmic rings metaphor
Leon Rosenberg wrote: ---Ursprüngliche Nachricht- Von: Borislav Sabev [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 13. Juli 2005 18:54 An: Struts Users Mailing List Betreff: [OT] olipmic rings metaphor 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. I think each layer has its own security and authorization sublayers (a layer itself can be composed of multiple layers) in the corba world better known as interruptors. But each layer should only make decision based on the knowledge which the layer itself posseses. I fully agree here, that's why I consider Authorization as a ring that intersect all other rings, and this means it depend on each of them. But it fact better metaphor for it is that is a small ring inside every other ring, i.e. not seen as one monolithic ring. So the presentation layer decides whether a user is allowed to execute a specific use case by checking user's permissions and roles. The business layer decides whether the specific method can be called from specific caller (a host for example), and the persistence layer decides which process/host can access the database. If you think about what you want to protect from whom, and act accordingly. These are System Authorization activities, but I mean Business Authorization activities. For example I have companies with some persmisions and their employees inherit and extend them. There are 3 types of Business Roles: suppliers, consumers and controlers. (think the names are enough to explain what they do more or less) There are different BO that suppliers put in the system, controlers check them and publish them (i.e. make the "visible" to the consumers) Suppliers can read all BO, but can change (edit, delete) only owned objects. Controler can do all that Supplier can do + publishing. Consumers can only read and make requests. So let's imagine I have to show a single list of some BO by some search criteria. The result list can be a mixture of BO owned and not owned objects. So here is list of checks that has to be performed to acomplish this: 1. Can the user see the list -> this should be enforced by the controler and view layers 2. Which BO will be collected from persistence (or cache) layer - only owned, owned + published etc -> this should be enforced by the model and persistance layer. 3. Check for every item in the list if it can be edited/published by the user -> this should be in the view only ( to show a link or button for each item for edit ) So now you see how such "simple" usecase spread authorization logic over all the layers ( not conserning hosts, db connections etc). Regards Borislav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] olipmic rings metaphor
> -Ursprüngliche Nachricht- > Von: Borislav Sabev [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 13. Juli 2005 18:54 > An: Struts Users Mailing List > Betreff: [OT] olipmic rings metaphor > > 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. > I think each layer has its own security and authorization sublayers (a layer itself can be composed of multiple layers) in the corba world better known as interruptors. But each layer should only make decision based on the knowledge which the layer itself posseses. So the presentation layer decides whether a user is allowed to execute a specific use case by checking user's permissions and roles. The business layer decides whether the specific method can be called from specific caller (a host for example), and the persistence layer decides which process/host can access the database. If you think about what you want to protect from whom, and act accordingly. I think it makes little sense to have a per-user check in the business layer, since access controls are best in front of something not behind it or within. But its just an opinion. Regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] olipmic rings metaphor
> -Ursprüngliche Nachricht- > Von: Borislav Sabev [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 13. Juli 2005 18:54 > An: Struts Users Mailing List > Betreff: [OT] olipmic rings metaphor > > 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. > I think each layer has its own security and authorization sublayers (a layer itself can be composed of multiple layers) in the corba world better known as interruptors. But each layer should only make decision based on the knowledge which the layer itself posseses. So the presentation layer decides whether a user is allowed to execute a specific use case by checking user's permissions and roles. The business layer decides whether the specific method can be called from specific caller (a host for example), and the persistence layer decides which process/host can access the database. If you think about what you want to protect from whom, and act accordingly. I think it makes little sense to have a per-user check in the business layer, since access controls are best in front of something not behind it or within. But its just an opinion. Regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] olipmic rings metaphor
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]
Re: [OT] olipmic rings metaphor
Boris- I see Security as implemented by RingBearer Frodo in Lord of the Rings The caretaker of the ring travels thru all domains and access to the other dimension (portal which contains final results) regardless of any domain he travels thru Begreife? Martin- - Original Message - From: "Borislav Sabev" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" Sent: Wednesday, July 13, 2005 12:54 PM Subject: [OT] olipmic rings metaphor Ted Husted wrote: In my own work, I tend to think of an enterprise-grade application as a set of overlapping rings, like the Olympics logo. * http://www.olympic.org/ In the Blue ring live the view members, like custom tags or UI components, and the HTTP request and response objects. This is the layer where our appliction interacts with the rest of the world. Some of the Blue ring members also interact with the presentation controller components that live in the Gold ring, like the Struts Actions, ActionForms, and JSF backing beans. This is the layer that "interprets user gestures" to decide which view to display next, and may also convert or format data as needed. In turn, Gold ring components interact with your own business objects, which live in the Black ring. The business compnents could also be chains of commands, representing services, rather than conventional object representing domain entities. This layer often acts as a "liaison" between the view-centric Blue and Gold rings, and the data-centric Green and Red rings. To be useful, most business objects need to access persistent data. Rather than talk to the native database API, most of us use data access objects, that live in the Green ring. Here we find components like iBATIS or Hibernate, JDO, or just plain JDBC. This layer links specific business methods to general-purpose persistence methods. Finally, in the Red ring, we find our dragon -- the physical database. In some applications, the database is a deep crimson that represents our solution to the domain's problems. Other times, the domain logic lives in the black ring, and the red ring is a pale pink shoebox. In some applications, the rings are separated by framework or package lines, like Struts and iBATIS. In other applications, the rings may exist as separate classes in the same package, or even different methods on the same class. But, eventually, in my experience, any long-lived, well-factored application will find itself using all five rings, or all five separations of concern, in one way or the other. Of course, in a conventional MVC application, the Black and Blue rings intersect, forming a triad, and the Green and Red rings are not described. Though, I expect, the other rings did still exist, but were simply hidden behind the event horizon of MVC's Black ring. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Ted, 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. Regards Borislav - 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]
[OT] olipmic rings metaphor
Ted Husted wrote: In my own work, I tend to think of an enterprise-grade application as a set of overlapping rings, like the Olympics logo. * http://www.olympic.org/ In the Blue ring live the view members, like custom tags or UI components, and the HTTP request and response objects. This is the layer where our appliction interacts with the rest of the world. Some of the Blue ring members also interact with the presentation controller components that live in the Gold ring, like the Struts Actions, ActionForms, and JSF backing beans. This is the layer that "interprets user gestures" to decide which view to display next, and may also convert or format data as needed. In turn, Gold ring components interact with your own business objects, which live in the Black ring. The business compnents could also be chains of commands, representing services, rather than conventional object representing domain entities. This layer often acts as a "liaison" between the view-centric Blue and Gold rings, and the data-centric Green and Red rings. To be useful, most business objects need to access persistent data. Rather than talk to the native database API, most of us use data access objects, that live in the Green ring. Here we find components like iBATIS or Hibernate, JDO, or just plain JDBC. This layer links specific business methods to general-purpose persistence methods. Finally, in the Red ring, we find our dragon -- the physical database. In some applications, the database is a deep crimson that represents our solution to the domain's problems. Other times, the domain logic lives in the black ring, and the red ring is a pale pink shoebox. In some applications, the rings are separated by framework or package lines, like Struts and iBATIS. In other applications, the rings may exist as separate classes in the same package, or even different methods on the same class. But, eventually, in my experience, any long-lived, well-factored application will find itself using all five rings, or all five separations of concern, in one way or the other. Of course, in a conventional MVC application, the Black and Blue rings intersect, forming a triad, and the Green and Red rings are not described. Though, I expect, the other rings did still exist, but were simply hidden behind the event horizon of MVC's Black ring. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Ted, 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. Regards Borislav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
