Menu
▾
▴
springframework-developer
|
From: Stephane B. <sba...@ap...> - 2004-07-08 09:10:46
|
I have been talking yesterday with a client that has a need for a strong display component security (viewable/editable depending on roles). Of course these roles are mostly dynamic and there will be a need for some kind of 'delegation' or flexibility on object and attributes. It is not doable to modelize the roles strictly based on the real-life roles or as a set of information (as they will complain that the role is too strict and this will lead to a security issue where the supervisor will need to give full access to subalterns). They must be be fine-grained. There are a couple of frameworks that deals with display policy for components based on taglibs, more or less they just rewrite all visual components and there is a display policy (that could look similar to the declarative approache on EJBs) that decide whether or not they SKIP_BODY. Frameworks that seem to do that are: SweetDev, http://www.ideotechnologies.com/ Framework based on Struts developped for BNP Paribas Securities. From what I can see, it seems to include typical Springesque approach on component configuration (yet another container) I seem to remember it is $3000 per developper and I think same price per CPU Improve Struts Layout: http://struts.application-servers.com/ A display policy can be used on visual components. If you know of any other please.. bring them to my attention :) I strikes me that this kind of visual component policy could be an interesting application of a security interceptor. Not displaying the visual component does not seem to be the solution to me. I think it is better not to display the 'value' of the component (typically by using '****' when it is not viewable and disabling the component if it is not editable). Not displaying the component (or a row in a table) may ruin the layout and pause massive problems of design to me. (especially as you have to deal with the labels of the component) That means basically that we could have an interceptor (or aspect ?) simply modifying the visual components. - We need to intercept expression evaluation (display) - We need to intercept taglib evaluation (edit box must be enabled/disabled) What do you people think about this ? Cheers, Stephane |
|
From: Andy D. <an...@ma...> - 2004-07-08 15:09:42
|
This is something I too am interested in.... though we will ultimately be using Spring + JSF with the addition of some rich clients when the time comes. I will need a solution that can work for both the web and rich client UIs. - Andy On Thursday 08 July 2004 01:59 am, Stephane Bailliez wrote: > I have been talking yesterday with a client that has a need for a strong > display component security (viewable/editable depending on roles). > > Of course these roles are mostly dynamic and there will be a need for > some kind of 'delegation' or flexibility on object and attributes. > ... > Cheers, > > Stephane > > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Stephane B. <sba...@ap...> - 2004-07-08 16:47:53
|
Andy Depue wrote: > This is something I too am interested in.... though we will ultimately be > using Spring + JSF with the addition of some rich clients when the time > comes. I will need a solution that can work for both the web and rich client > UIs. I think that the AOP approach should work particulary well with JSF as everything is normally a component. There are a couple of issues to solve though (which are also valid for Struts html taglibs) - it means that we must have an object filter that replaces for example the sensitive value returned via get methods with a "***". This makes sense in place where the information is visible on a shared page and where it would be difficult to actually modify the whole page layout. Otherwise if everything is separated in a different page it is solved very easily anyway. - When the object is not editable, it means that basically we need to disable the component which value is the sensitive one. So we must have a filter on the visual component. - The problem to solve is also when we update the object. If we just filtered the object by adding "***" and it is not editable..we of course need to avoid this object being updated with the "***" value. So we need to intercept here again. The problem is also in the case when an 'action' wraps a hidden component. For example an hyperlink over a "***" value. This is a special case though that could be solve as well with an interceptor but that's starts to be tricky. I can definitely see however how it would simplify development dramatically... that would be an extremely powerful application of AOP on something that is definitely cross cutting. Stephane |
|
From: Andy D. <an...@ma...> - 2004-07-08 17:49:58
|
Our current plan is to adapt something we already have in place for our service interfaces. Basically, we have an aspect for our services that allows you to declaratively define the roles allowed to access properties on data objects (this is done on a Java class + property name basis). So, for example, I may say that only the hr_management role can access the "salary" property of the "com.mypackage.Employee" class. All objects returned from a service method are filtered based on these declarative access rules. For protected properties, the property setter method is used to change the value of the property to a "secured" value (also defined in the configuration). Thus, no secure values ever leave a service. This is important for remote service invocation, as it is not enough to simply deny access to a property via an aspect - you must also be sure that the value of the property is not transmitted over the wire. There is also a service available to get a "security map" for a particular data object class (basically a Map that uses the property name as key and the allowed access for the current user as value). We are thinking of integrating this security map into the UI in some sleek automatic fashion.. but if someone out there has an already cooked up solution, we would be open to changing our plans. :-) - Andy PS the challenge for us when we implemented this type of security was when the client sends those modified data objects back to the service (to an 'update' method, for example). You really wouldn't want Hibernate to persist the modified property values back to the DB. On Thursday 08 July 2004 09:47 am, Stephane Bailliez wrote: > - it means that we must have an object filter that replaces for example > the sensitive value returned via get methods with a "***".... > ... > Stephane > > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
