Re: Brainstorming: Security Requirements/Scenarios

[Adrian Crum <ad...@hlmksw.com>]

I'm bumping this because I would like to begin working on it.

I've been updating the design document when I have time - 
http://docs.ofbiz.org/x/Ch8.

There are two design issues that I would like to get finalized soon, so 
that work can begin:

1. The document proposes converting the Security abstract class to an 
interface, and adding new methods to the interface that will implement 
the new security design. If there are no objections to changing Security 
to an interface, then I will design and document the new Security API.

2. The document describes two artifact hierarchies - static and dynamic. 
  The pros and cons of each is demonstrated in the Access Control 
Scenarios portion of the document. We need to decide which approach to 
use. Once that decision is made, we can build out more of the design.

-Adrian

Adrian Crum wrote:
> --- On Sun, 5/17/09, David E Jones <da...@hotwaxmedia.com> wrote:
>> If I understand correctly what you are describing above it
>> is simply  
>> record level permissions. And yes, I agree that is a
>> common  
>> requirement that we've discussed quite a bit. I'm worried
>> I'm  
>> misunderstanding though because I'm not sure how that fits
>> with  
>> comment...
> 
> It fits into the design objective because it takes the record-level filtering out of code and puts it in assigned permissions. Isn't that one of the objectives? Remove the security checking that is embedded in code and put it in the database where an administrator can assign it to a user.
> 
> Instead of hard-coding record-level permission checking inside some other service, extract the record-level permission checking code, make it a service, and assign the service as part of a user's permissions.
> 
> It's clear we have disconnected somewhere. The existing entity engine doesn't know about security. It works with not-logged-in users and anonymous users and whatever else comes along. I'm not suggesting we change any of that. Keep it all the same. But add the ability to restrict records based on the user. If there is no user, then it does what it has always done. I don't know how else I can say it. *shrug*
> 
> -Adrian
> 
> 
> 
>       
> 

Re: Brainstorming: Security Requirements/Scenarios

[David E Jones <de...@me.com>]

On Jul 9, 2009, at 9:40 AM, Adrian Crum wrote:

> I'm bumping this because I would like to begin working on it.
>
> I've been updating the design document when I have time - http://docs.ofbiz.org/x/Ch8 
> .
>
> There are two design issues that I would like to get finalized soon,  
> so that work can begin:
>
> 1. The document proposes converting the Security abstract class to  
> an interface, and adding new methods to the interface that will  
> implement the new security design. If there are no objections to  
> changing Security to an interface, then I will design and document  
> the new Security API.

What would go in the new security API? Isn't the idea to externalize  
this and make it configurable?

> 2. The document describes two artifact hierarchies - static and  
> dynamic.  The pros and cons of each is demonstrated in the Access  
> Control Scenarios portion of the document. We need to decide which  
> approach to use. Once that decision is made, we can build out more  
> of the design.

In the examples you've done for static and dynamic I don't think the  
dynamic ones really show how it is meant to be used. What I mean by  
that is that the point of the dynamic ones is that the "path" as it  
were doesn't depend at all on where the artifact is located, it only  
depends on how the artifact is referred to or "invoked" at run time.

In fact, to be frank, I don't think there is any reason we should  
consider not using the "dynamic" method. There are a couple of big  
problems I see with the current security, or the most common complaints:

1. you have to modify "code" (usually XML files) to change how  
permissions are used and which are available

2. the current permissions checking at runtime limits reuse of  
artifacts because the permissions are often determined by artifact and  
you can't change the permission (implicitly or explicitly) when the  
artifact is used in another application that has a different security  
setup (and/or you don't want to give users permissions to the base  
applications)

The solutions to these are:

1. configure permissions in the database and not directly in  
artifacts, or even in configuration files independent of artifacts

2. use the "dynamic" way of determining the context for an artifact  
instead of using where it is located for the context

BTW, to do this one thing that will need to be done is to implement  
the "ExecutionContext" object, and on that note I think that will help  
with the multi-tenancy and deployment flexibility things that have  
been discussed on the list recently (especially by Marc and Henning).  
The idea is that nothing would keep a local reference to the delegator  
or dispatcher, not even the service engine, control servlet, and other  
framework components too.

-David


> Adrian Crum wrote:
>> --- On Sun, 5/17/09, David E Jones <da...@hotwaxmedia.com>  
>> wrote:
>>> If I understand correctly what you are describing above it
>>> is simply  record level permissions. And yes, I agree that is a
>>> common  requirement that we've discussed quite a bit. I'm worried
>>> I'm  misunderstanding though because I'm not sure how that fits
>>> with  comment...
>> It fits into the design objective because it takes the record-level  
>> filtering out of code and puts it in assigned permissions. Isn't  
>> that one of the objectives? Remove the security checking that is  
>> embedded in code and put it in the database where an administrator  
>> can assign it to a user.
>> Instead of hard-coding record-level permission checking inside some  
>> other service, extract the record-level permission checking code,  
>> make it a service, and assign the service as part of a user's  
>> permissions.
>> It's clear we have disconnected somewhere. The existing entity  
>> engine doesn't know about security. It works with not-logged-in  
>> users and anonymous users and whatever else comes along. I'm not  
>> suggesting we change any of that. Keep it all the same. But add the  
>> ability to restrict records based on the user. If there is no user,  
>> then it does what it has always done. I don't know how else I can  
>> say it. *shrug*
>> -Adrian
>>