Just for discussion convenience, here are the links in Confluence and Jira I
think are related to this discussion so far
https://issues.apache.org/jira/browse/OFBIZ-2380 (main task)
http://docs.ofbiz.org/x/-B0 (Andrew's proposition)
http://docs.ofbiz.org/x/JR4 (detailed persmissions)
http://docs.ofbiz.org/x/bR4 (David's comments)
http://docs.ofbiz.org/display/OFBTECH/OFBiz+security (Doc on security so far)
BTW, we should take care of updating the last link.
Jacques
From: "Andrew Zeneski" <andrew.zene...@hotwaxmedia.com>
Adrian,
Thank you very much for your comments. Minor point, you misread what I
said. I said "NOT ONCE have I had the masochistic urge to work on
something which did not already have some sort of design"... meaning
everything has had some sort of design even if its some sticky notes
on my wall, or a drawing on the whiteboard describing a
ContentMapFacade, or a full blown document like I put together in this
case. Also, it is my experience that a prototype of some sort is often
a good way to prove the concept and something I am often asked to
provide.
While I have nothing against working as in a community, hell isn't
that why OFBiz is here? This is my way of working with the community,
what you will see are proposals and prototypes like what you have
right now. I have NEVER implied that my designs or implementations
were ever superior, however I don't see any other proposals on the
table right now. If was trying to avoid discussing and collaborating,
you would hear nothing about it from me except for a some commits and
more than half the applications would be finished already...
Now that everyone has expressed themselves, I think we can move on to
business. What we have in front of us today is a proposal and
prototype of a new security enhancement which is really based several
things. We have an API which can be implemented for various different
methods of authorization. The design was careful to not require
anything specific to the internal security functionality. I do plan to
implement a Crowd version of this as well, which would end up being a
hybrid LDAP via Crowd/OFBiz combination. A pure LDAP implementation
can be developed as well, which is one thing I was certain you would
be interested in.
The designs are really very similar to those we discussed 2 years ago
when the PermissionService stuff was implemented. For some reason
however I let others influence my decision at that time and let it go.
There was some discussion about more granular permissions for forums
and I would personally like to implement much more granular
permissions in Project Manager and SFA applications. Which is were
this entire effort branched from.
I find it frustrating that authorization is handled in so many
different places and looking at it now, to me it looks like a total
mess. I will want to customize the access control for the applications
we use internally, no I need to. I don't want to patch or extend
service definitions b/c that makes upgrading all that much more
complicated. Finally, I want one single API which I can use throughout
the system to check permission.
I wrote a security prototype using JSecurity and Hibernate to get a
feel for some other tools. Even considered integrating JSecurity into
OFBiz. However, the major limitation to that API is that all
permissions are loaded for a user when they authenticate. So, if we
were to write custom logic to handle very granular permissions we
could end up with millions or billions of permissions loaded into
memory. This didn't seem scalable.
I spent about a week writing down thoughts about what an ideal
authorization scheme would look like. I compared that to what we have
and came up with the designs that were posted last Friday.
Last weekend, a received a few comments regarding the designs posted
in Confluence and on Monday when I heard nothing more decided to start
working on implementing the API. Only took a few hours, but after
another day or so of testing I was then able to check it in for
comments.
The main points in this design is that is brings about a new
permission format which provides a simple way to create very granular
permissions. This is actually the main draw, the whole API is based
around the permission format. Next, the pains in keeping up with <has-
permission>, <permission-service> the various different things which
need to be called. The PermissionService implementation never became
the "center". It was always still tied with the Security object, so
now I think its time to address it completely and really centralize
authorization.
Now that there is proposal and a prototype, I would like to know if
there are any requirements I did not account for. Like the
findMatchingPermissions() idea was fantastic, and that is now part of
the API and document. Let's review what we have and see what can make
it better, but let's do it quickly...
Andrew
p.s. The one thing I don't care about is the fact that this is big and
will require a lot of work, one of the reasons I am trying to move
quickly on this is so that *I* have enough time to complete it. I'm
not expecting everyone to jump in and help, and I don't want to leave
it half done.
On May 2, 2009, at 12:35 AM, Adrian Crum wrote:
Understood.
I remember sitting next to you at the developer's conference, and
watching you work. I experienced firsthand your "masochistic urge to
work on something which did not already have some sort of design." I
asked you for help, and you gave me links that pointed me right to
the answer. I really appreciated that. I admire you and I respect
you. Please understand that.
Before I got involved with OFBiz I worked as an independent
programmer - I didn't have to answer to anyone. I could do my own
thing. Like you, I had the "masochistic urge to work on something
which did not already have some sort of design." I didn't consult
with anyone - I just came up with a design and wrote the code for it.
Working with the OFBiz community has taught me the value of
community. It has changed my ways. I started off with suggesting my
"superior designs" (that I emailed to David, and I am embarrassed to
read today) and they were critiqued, in a stern yet polite way. Yet
I accepted those critiques. In the years that followed, David and I
would disagree about many things, but I never ignored his advice or
his opinions - I would always consider them carefully.
So that's all I'm suggesting now. Please understand that you are
respected for who you are - one of the founders of the project.
Please understand that you are respected for your talent. But also,
please understand that we are a community.
I want to help with this effort. There is nothing that would satisfy
me more than all of us working together on the refactoring of OFBiz
security. All I ask is that we back off for a little while and let
the community offer their comments, suggestions, and recommendations
- even if it means discarding "superior designs." Together, we can
take those comments, suggestions, and recommendations, and use them
to redesign OFBiz security in a way that will meet the needs of the
community and impress the world at large.
-Adrian
