Protect-view pre-processor

[Jacques Le Roux]

As you may seen in the last patch I updloaded in https://issues.apache.org/jira/browse/OFBIZ-2074 I use a standard preprocesor to deal with the protect-view feature.
In concerned request-maps, error responses should be associated with each protected views. This has advantages and drawbacks

Advantages : it's flexible, you can define the view you want, if you define none, a blanck page is rendered (using ":none")
Drawbacks : they are 2 parts to protect a view. You must define the view to protect from Party/Security in a (definitive name ;o) ProtectedView entity (was ConstrainviewByRole before) *and* set an error response in the corresponding request-map. Not a clear process, if you forgot the error response a protective blank page is rendered but without any information in case of false tarpitting.

I think now we could provide a default error response view for all request-map. I guess most of the time this view will be used instead of a specific one. It could then favourably replace the blank rendered page.

Thanks

Jacques

[David E Jones-3]

Why not keep it super-simple at just add a field to the  
SecurityGroupPermission entity with the limit of times per time period  
that a user in that group can access that permission. Then in the low-
level permission checking code keep a count...

That would probably total less than 100 lines of changes (unless you  
got really fancy).

-David


On Dec 11, 2008, at 11:25 PM, Jacques Le Roux wrote:

> As you may seen in the last patch I updloaded in https://issues.apache.org/jira/browse/OFBIZ-2074 
>  I use a standard preprocesor to deal with the protect-view feature.
> In concerned request-maps, error responses should be associated with  
> each protected views. This has advantages and drawbacks
>
> Advantages : it's flexible, you can define the view you want, if you  
> define none, a blanck page is rendered (using ":none")
> Drawbacks : they are 2 parts to protect a view. You must define the  
> view to protect from Party/Security in a (definitive name ;o)  
> ProtectedView entity (was ConstrainviewByRole before) *and* set an  
> error response in the corresponding request-map. Not a clear  
> process, if you forgot the error response a protective blank page is  
> rendered but without any information in case of false tarpitting.
>
> I think now we could provide a default error response view for all  
> request-map. I guess most of the time this view will be used instead  
> of a specific one. It could then favourably replace the blank  
> rendered page.
>
> Thanks
>
> Jacques
>

[Jacques Le Roux]

From: "David E Jones" <[hidden email]>
>
> Why not keep it super-simple at just add a field to the  SecurityGroupPermission entity with the limit of times per time period
> that a user in that group can access that permission. Then in the low- level permission checking code keep a count...

I suppose you meaned "with the limit of hits per time period ".
I'm not sure this would allow the other requirements we have :
1) redirect to an explaining page (directions to ask admin, etc.), being error response, blanck (":none") or a general default as I
suggested recently;
2) allow the admin to reset the tarpitted (greyed or grayed ) login in case of false protection (false protection being a person
needed really to do as much hits, without any security information compromised)
3) keep traces of the abuse
4) Ray ?

Also I'm pretty advanced now and it fits well in the architecture, pre-processing is relevant for this case I guess... The only
drawback being this ugly code (harcoded method name) I have still in RequestHandler.doRequest() if I want to optimise pre-processing

Thanks

Jacques

> That would probably total less than 100 lines of changes (unless you  got really fancy).
>
> -David
>
>
> On Dec 11, 2008, at 11:25 PM, Jacques Le Roux wrote:
>
>> As you may seen in the last patch I updloaded in https://issues.apache.org/jira/browse/OFBIZ-2074 I use a standard preprocesor to
>> deal with the protect-view feature.
>> In concerned request-maps, error responses should be associated with  each protected views. This has advantages and drawbacks
>>
>> Advantages : it's flexible, you can define the view you want, if you  define none, a blanck page is rendered (using ":none")
>> Drawbacks : they are 2 parts to protect a view. You must define the  view to protect from Party/Security in a (definitive name
>> ;o)  ProtectedView entity (was ConstrainviewByRole before) *and* set an  error response in the corresponding request-map. Not a
>> clear  process, if you forgot the error response a protective blank page is  rendered but without any information in case of
>> false tarpitting.
>>
>> I think now we could provide a default error response view for all  request-map. I guess most of the time this view will be used
>> instead  of a specific one. It could then favourably replace the blank  rendered page.
>>
>> Thanks
>>
>> Jacques
>>
>

[Jacques Le Roux]

I finally thought about this a bit more, and yes this will be simpler for me (no need to have a relation with SecurityGroup), but
then I would have to add more than 1 field to SecurityGroupPermission.
I would need to add fields for
* view-name (or did I miss something); because this must done view by view not only for all views of a component. BTW shoud we not
remove the <!-- Tax Rate security --> block in ProductSecurityData.xml (if no answers I will remove insome days) ? I guess I forgot
it when I removed old tax fields in edit Store view.
* maxHit =  number of hit before tarpitting the view for the login
* maxHitDuration = period of time associated with maxHit
* tarpitDuration = period of time the login will not be able to acces  this view again

For the moment I will create a ProtectedView entity, listable and editable from a Party/Security/4th menu I'm adding (from ftl
tabbar to xml), with the fields above + a field groupId (primay Key) in relations with SecurityGroup entity. No needs to
specifically define permissions for this feature. But of course to be able to have access to a view the user should have the right
permissions. It's another security level, not really security because few leaks may appear, but statistically the view will
protected.

Note that the mechanism I propose is used at the lower level (in request-map, by default you will only need to add
protected-view=true to protect a view from data leackage). You don't need to edit your screen, use if-has-permission, fail-widget,
etc.

Thanks

Jacques

From: "Jacques Le Roux" <[hidden email]>

> From: "David E Jones" <[hidden email]>
>>
>> Why not keep it super-simple at just add a field to the  SecurityGroupPermission entity with the limit of times per time period
>> that a user in that group can access that permission. Then in the low- level permission checking code keep a count...
>
> I suppose you meaned "with the limit of hits per time period ".
> I'm not sure this would allow the other requirements we have :
> 1) redirect to an explaining page (directions to ask admin, etc.), being error response, blanck (":none") or a general default as
> I
> suggested recently;
> 2) allow the admin to reset the tarpitted (greyed or grayed ) login in case of false protection (false protection being a person
> needed really to do as much hits, without any security information compromised)
> 3) keep traces of the abuse
> 4) Ray ?
>
> Also I'm pretty advanced now and it fits well in the architecture, pre-processing is relevant for this case I guess... The only
> drawback being this ugly code (harcoded method name) I have still in RequestHandler.doRequest() if I want to optimise
> pre-processing
>
> Thanks
>
> Jacques
>
>
>> That would probably total less than 100 lines of changes (unless you  got really fancy).
>>
>> -David
>>
>>
>> On Dec 11, 2008, at 11:25 PM, Jacques Le Roux wrote:
>>
>>> As you may seen in the last patch I updloaded in https://issues.apache.org/jira/browse/OFBIZ-2074 I use a standard preprocesor
>>> to
>>> deal with the protect-view feature.
>>> In concerned request-maps, error responses should be associated with  each protected views. This has advantages and drawbacks
>>>
>>> Advantages : it's flexible, you can define the view you want, if you  define none, a blanck page is rendered (using ":none")
>>> Drawbacks : they are 2 parts to protect a view. You must define the  view to protect from Party/Security in a (definitive name
>>> ;o)  ProtectedView entity (was ConstrainviewByRole before) *and* set an  error response in the corresponding request-map. Not a
>>> clear  process, if you forgot the error response a protective blank page is  rendered but without any information in case of
>>> false tarpitting.
>>>
>>> I think now we could provide a default error response view for all  request-map. I guess most of the time this view will be used
>>> instead  of a specific one. It could then favourably replace the blank  rendered page.
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>
>

[Jacques Le Roux]

I have submitted a last patch in https://issues.apache.org/jira/browse/OFBIZ-2074. In this patch I left the ProtectedViewAccessed
entity defintion but I will remove it as it not used. All is done in the session, I guess it's enough for our need.

It's finally pretty simple to use.
You define the views you want to protect under a security group using the protected view menu.
There you define the
    * viewName using one uri atribute of in request-map element of the controller.xml files
    * Maximum number of visits (per period)
    * Duration during which the visits are considered (in seconds)
    * Duration during which the view will not be accessible (in seconds)
The last parameter defines the tarpitting period.

You don't have to define anything else for the protected views mechanism to work. If you don't define a "protect" response, in case
of blocking the screen rendered will be blank by default. But you may define a generic "protect" response view which will be
rendered by default using the default.error.response.view parameter in security.properties.

The code use a simple strategy as we don't need something very sophisticated to trap malignants. It's all in ProtectViewWorker.java.

Jacques

From: "Jacques Le Roux" <[hidden email]>

>I finally thought about this a bit more, and yes this will be simpler for me (no need to have a relation with SecurityGroup), but
>then I would have to add more than 1 field to SecurityGroupPermission.
> I would need to add fields for
> * view-name (or did I miss something); because this must done view by view not only for all views of a component. BTW shoud we not
> remove the <!-- Tax Rate security --> block in ProductSecurityData.xml (if no answers I will remove insome days) ? I guess I
> forgot it when I removed old tax fields in edit Store view.
> * maxHit =  number of hit before tarpitting the view for the login
> * maxHitDuration = period of time associated with maxHit
> * tarpitDuration = period of time the login will not be able to acces  this view again
>
> For the moment I will create a ProtectedView entity, listable and editable from a Party/Security/4th menu I'm adding (from ftl
> tabbar to xml), with the fields above + a field groupId (primay Key) in relations with SecurityGroup entity. No needs to
> specifically define permissions for this feature. But of course to be able to have access to a view the user should have the right
> permissions. It's another security level, not really security because few leaks may appear, but statistically the view will
> protected.
>
> Note that the mechanism I propose is used at the lower level (in request-map, by default you will only need to add
> protected-view=true to protect a view from data leackage). You don't need to edit your screen, use if-has-permission, fail-widget,
> etc.
>
> Thanks
>
> Jacques
>
> From: "Jacques Le Roux" <[hidden email]>
>> From: "David E Jones" <[hidden email]>
>>>
>>> Why not keep it super-simple at just add a field to the  SecurityGroupPermission entity with the limit of times per time period
>>> that a user in that group can access that permission. Then in the low- level permission checking code keep a count...
>>
>> I suppose you meaned "with the limit of hits per time period ".
>> I'm not sure this would allow the other requirements we have :
>> 1) redirect to an explaining page (directions to ask admin, etc.), being error response, blanck (":none") or a general default as
>> I
>> suggested recently;
>> 2) allow the admin to reset the tarpitted (greyed or grayed ) login in case of false protection (false protection being a person
>> needed really to do as much hits, without any security information compromised)
>> 3) keep traces of the abuse
>> 4) Ray ?
>>
>> Also I'm pretty advanced now and it fits well in the architecture, pre-processing is relevant for this case I guess... The only
>> drawback being this ugly code (harcoded method name) I have still in RequestHandler.doRequest() if I want to optimise
>> pre-processing
>>
>> Thanks
>>
>> Jacques
>>
>>
>>> That would probably total less than 100 lines of changes (unless you  got really fancy).
>>>
>>> -David
>>>
>>>
>>> On Dec 11, 2008, at 11:25 PM, Jacques Le Roux wrote:
>>>
>>>> As you may seen in the last patch I updloaded in https://issues.apache.org/jira/browse/OFBIZ-2074 I use a standard preprocesor
>>>> to
>>>> deal with the protect-view feature.
>>>> In concerned request-maps, error responses should be associated with  each protected views. This has advantages and drawbacks
>>>>
>>>> Advantages : it's flexible, you can define the view you want, if you  define none, a blanck page is rendered (using ":none")
>>>> Drawbacks : they are 2 parts to protect a view. You must define the  view to protect from Party/Security in a (definitive name
>>>> ;o)  ProtectedView entity (was ConstrainviewByRole before) *and* set an  error response in the corresponding request-map. Not a
>>>> clear  process, if you forgot the error response a protective blank page is  rendered but without any information in case of
>>>> false tarpitting.
>>>>
>>>> I think now we could provide a default error response view for all  request-map. I guess most of the time this view will be
>>>> used
>>>> instead  of a specific one. It could then favourably replace the blank  rendered page.
>>>>
>>>> Thanks
>>>>
>>>> Jacques
>>>>
>>>
>>
>