Instead of attaching this to a Party RoleType, it would be better to
attach it to a SecurityPermission or SecurityGroup. Access to
resources like pages and such is governed by permissions in OFBiz, and
roles are used for record-level security (like which parties a user
can view/edit/etc as opposed to being able to use the view profile
screen).
-David
On Dec 10, 2008, at 3:54 AM, Jacques Le Roux wrote:
After a discussion with Ray I finally changed my mind and we would
like to commit more changes.
It will be an entity with demo data. Nobody will be harmed since we
will put large enough values on an example view.
Entity name :
ConstrainViewByRole, fields :
partyRole = a party role
viewName = name of view to check for constraint
maxHit = number of hit before tarpitting the view for the login
maxHitDuration = period of time associated with maxHit (no more than
1000 hits in 3 mins, for instance)
tarpitDuration = period of time the login will not be able to acces
this view again
Example :
partyRole = consultant
view = confidentialDataView
maxHit = 1000
duration = 360 (seconds = 3 mins)
tarpitDuration = 360000 (seconds = 100 hours)
If a login with consultant role has more than 1000 hits in 6 mins on
the confidentialDataView it will be tarpitted for 100 heures
I will also commit the BlockingWorker used by the prepocessor event.
I have not written it yet but I suppose with at least 2 methods :
one to count hits called by the main one which takes the decision
and send informations (return status, possible msg) to the
Controller (RequestHandler.doRequest)
Since nobody objected, I will soon open a Jira issue with a 1st
patch version with only the RequestHandler.doRequest changes for now.
Thanks
Jacques
From: "Jacques Le Roux" <[EMAIL PROTECTED]>
From: "BJ Freeman" <[EMAIL PROTECTED]>
sorry I have not responded till now
Inline:
Thanks for your interest
Jacques Le Roux sent the following on 12/9/2008 7:37 AM:
From: "Jacques Le Roux" <[EMAIL PROTECTED]>
BJ,
The client concern is in case a login/pwd couple is used but not
by
the right person (lost, stolen, etc.). Only biometric security
could deal with that I guess.
have to think on this one.
using encrypted USB devices for login works with PGP.
I did not think about that. Anyway it's not the thing the client is
looking for (too much turnover I imagine)
By limiting the number of time a page can be visited in a period
of
time you don't really prevent using UI to pull out confidential
data but you make it so long (years) that it's not usable. It's
something used in spam fighting known as tarpitting. It has proven
to be very efficient and is now used in the gray list concept
wich
works great. Anyway for the moment it's the requirement I have
BTW I wonder if it should not better block the account and send a
message to the admin in such case. He/she would then be able to
reset
the login/pwd to secure anew the login.
yes use tarpitting works very well. I found it really slows down the
spammers. However if there is a heavy use of tarpitting, you are
using
up a lot of threads and memory.
I think blocking the account, and sending a email to the person's
registered email with a link back to the login would validate them.
the link would let them validate the email then another email
would send
them their logging information.
CC the Admin would be an option as well.
Actually we have also to deal with the rare case of an authorised
person who reachs the limit. So we will redirect this person to an
explicit screen where will ask him/her to request the admin him/
herself. Thieves will be tarpitted, that's all.
I will put the check in at end of RequestHandler.renderView just
after
the block where ServerHitBin.countView is used. This would
clearly separate this new security aspect. And having it at the
framework level is clearly easier : you only have to define a list
of pages to constrain by PartyRoles.
have to review code before I comment.
Forget it : obsolete
I had a better idea : to use a preprocessor event. I will though
need to
make a small change to allow to return a specific message from the
event. I guess it will be the only thing I will commit, except if
some
people are interested in the tarpitting feature.
interested but not knowledgeable enough to understand how it works.
Really simple, I will create a Jira with a patch and hopefully a 3
lines explanation. It's much simpler and clean. So much things are
already there, you just have to be patient enough to discover them
at the rigth place, the right moment ;o)
Jacques
Jacques
In the check I will need
. PartyRole(s),
. The list of pages to constrain access by PartyRoles. I will be
an
ConstrainViewByRole entity with 2 fields : partyRole viewName
(pages are actually views in OFBiz)
. Max number of page access allowed, and the period of time for
counting the number of page accesses in security.properties
. An AccessedPage entity with fields loginId viewAccessed
dateTimeOfAccess. (note : I changed UrlAccessed to viewAccessed)
I think it's a feature generic enough to be used in Framework if
someone is interested in future (if nothing is defined in
security.properties the block would be simply skipped so it's
harmful). So if nobody see a problem with that I will implement
and
commit. Any comments welcome
Thanks
Jacques
From: "BJ Freeman" <[EMAIL PROTECTED]>
Jacques:
my first reaction is if a robot can pull out confidential data
then
ofbiz would not pass the PCI audit.
the focus should be to not allow log in to confidential data,
unless a
strict protocol is followed.
The other is to find all the ways a hack can be done, like DOS
that may
also allow access into the system.
SATAN (Security Administrator Tool for Analyzing Networks)
(1990)test
very thoroughly. using it as a basis of testing would further
ofbiz.
http://d4rk-c0de.org/2008/11/15/satan-securitry-administrator/.
Jacques Le Roux sent the following on 12/5/2008 8:25 AM:
I have another requirement : being able to dissalow acces to
some pages
for some users if a number of hits in a pre-defined period of
time is
exceeded. I have an idea of how to do that but do you thing it
could be
interesting to be commited ? Maybe in a more generic way ?
The purpose is security : this would prevent any kind of robot
to pull
out confidential data from the system.
Thanks
Jacques
From: "Jacques Le Roux" <[EMAIL PROTECTED]>
So refering to defintions in
http://docs.ofbiz.org/display/OFBTECH/OFBiz+security this
would be
between the component menu level and
the screen level (which use "<if-has-permission" and
"<if-service-permission" tags), that's it ?
It would be great to be able to hide menus as Bruno suggested
(having
a parameter in menu-item like David sugested for screens
def). It could be then named the menu level permission (we
should
then rename the component menu level to component level or even
application level)
In a 1st and generic approach we could use 2 user
categories : experts
and novices. By default the expert mode would be used (all
shown OOTB) but users could change this in their preferences
to novice
mode. So this would need to define what novice could and
should not see in all OFBiz (and should be updated later,
being
visible by default).
Later contributors could defines specific categories and they
could be
added to users's preferences choice. Could not roles be used
for that or is it really orthogonal ? (customer service
can't see
some accounting screens, but are able to view some other etc.).
My 2 cts
Jacques
From: "Bruno Busco" <[EMAIL PROTECTED]>
David,
I like this idea.
So we should add a screen property to specify a permission.
The same permission should be checked to render the menu
item that
takes to
that screen (sub-screen).
Is this what you mean?
This could be done even without the "getAllPermissions"
service
proposed, am
I right?
-Bruno
2008/12/3 David E Jones <[EMAIL PROTECTED]>
One option for this (or at least part of it), and one that
I think
has been
discussed before, would be to introduce a convention for
naming
permissions
(or more to the point, "ID-ing" permissions) based on screen
names and
locations. A few aspects of this:
1. We could configure specific screens to always require the
screen-specific permission, or to require either a general
permission
(probably specified in the screen def) or the screen-specific
permission
2. this would be a view-only permission for rendering the
screen
3. doing it for each screen defined would allow for
permissions on
sub-screens and such as well
-David
On Nov 30, 2008, at 12:32 AM, Bruno Busco wrote:
I need to simplify the UI has I described.
To do this I think the Map should contain ALL user
permissions, not
restricted to a single application.
Could we think to specific permissions to hide the TabBar
options?
I understand that OFBiz UI is designed to have ALL there
because at
least
everybody sees that a feature is available but this
creates a
problem when
deplying to end user.
I understand also that the perfect UI is the one that
reproduces
the very
specific users workflow and so it must be written ad hoc.
But having an 80% fitting UI with only permissions setting
(user
profiling)
could be a good result.
This IMO is another key factor for spreading OFBiz and
having more
people
using it.
I would like to hear other idea about this and, possibly,
some user
profiling pattern ideas.
For sure the Portlet system will help in this direction
but could
we think
to a UI profiling through permission too?
-Bruno
2008/11/30 Adrian Crum <[EMAIL PROTECTED]>
Bruno,
I never got around to implementing that idea. I would
still like
to work
on
it though.
-Adrian
--- On Sat, 11/29/08, Bruno Busco <[EMAIL PROTECTED]>
wrote:
From: Bruno Busco <[EMAIL PROTECTED]>
Subject: Re: Discussion: Permissions Checking Enhancement
To: dev@ofbiz.apache.org
Date: Saturday, November 29, 2008, 10:30 AM
Hi Adrian,
I am thinking to something similar to what you proposed in
this thread.
What I would like to do is to simplify the UI to users who
should not
perform some operations.
For instance, in the catalog application, when looking to
the EditProduct
screen, I would like that the following tabmenus:
Geos, IDs, Keywords, Associations, Manufacturing, Costs,
Attributes,
Agreements, Accounts, Maintenance, Meters, Workefforts
should not be visible to standard users while they should
be visible to
admin.
I am thinking to implement several permissions (may be
some
are already
there) and to check for them in the menu items.
What do you think?
Did you implement something about it?
Thank you,
-Bruno
2008/6/6 Adrian Crum <[EMAIL PROTECTED]>
Correct.
Bruno Busco wrote:
Thank you,
it make sense; so a CREATE permission check will
be sufficient for the
CREATE button rendering.
-Bruno
2008/6/6 Adrian Crum <[EMAIL PROTECTED]>:
The pattern used so far is that the ADMIN
permission is checked first,
then
the other permissions. So if a user has the
ADMIN permission, they don't
need the additional permissions.
I'll probably have all of the permissions
Map elements set to true if the
user has the ADMIN permission.
-Adrian
Bruno Busco wrote:
Adrian,
may be a newbie question but...
...in the example you give what will
happen if a user has the ADMIN
permission but not the CREATE one?
Will the Create New button be rendered?
In other words who is responsible for the
permission hierarchy ?
In order to display the CREATE button,
should a user be given with the
CREATE permission explicitly or the ADMIN
is sufficient?
Thank you
-Bruno
2008/6/6 Adrian Crum
<[EMAIL PROTECTED]>:
I'll work on it this weekend.
-Adrian
Ashish Vijaywargiya wrote:
+1
Adrian I liked your idea.
On Thu, Jun 5, 2008 at 12:46 AM,
Sumit Pandit <
[EMAIL PROTECTED]>
wrote:
+1
--
Sumit Pandit
On Jun 5, 2008, at 3:04 AM,
Jacques Le Roux wrote:
Yes this sounds good to me
too
Jacques
From: "Bruno
Busco" <[EMAIL PROTECTED]>
Wonderfull !!!!
Looking forward to having
it !!! ;-)
This will let me also
define a more granular permissions to
simplify
the
interface for
not-so-skilled users.
-Bruno
2008/6/4 Adrian Crum
<[EMAIL PROTECTED]>:
In the screen
widgets, you can check permissions with the
<if-has-permission> or <if-service-permission>
elements. That's
fine
if
you
only need to check
a single permission to control access to the
entire
screen.
Things get
complicated when a screen's elements are
controlled by
more
than
one permission.
Let's say you have a typical Edit Item screen.
The
screen
should be viewable
only to users who have the VIEW permission.
Users
who
have the UPDATE
permission can edit the item. Users who have the
CREATE
permission see a
"New Item" button. Users who have DELETE
permission
see
a
"Delete
Item" button. Users who have the ADMIN
permission have
unrestricted
access to the
screen. Wow. Five permission elements (and five
service
calls)
are needed to
control one screen.
Here's my
idea: have a permission service that returns
ALL of the
user's
permissions in a
Map. You call the service with the permission to
check
-
"ACCOUNTING" for example. The service returns a
Map containing all
of
the
user's
ACCOUNTING permissions stored as Boolean
objects. Let's
say
the
returned Map is
called permissionsMap and the user has
ACCOUNTING_VIEW
and
ACCOUNTING_UPDATE
permissions, then the Map would contain these
elements:
CREATE=false
UPDATE=true
DELETE=false
VIEW=true
ADMIN=false
If the service
call is put in the screen's <actions> element,
then
the
Map
elements could be
used to control the display of screen widget
sections,
menu items, and
form fields.
Freemarker code
would be simpler too:
<#if
permissionsMap.CREATE>
<!-- Render a
Create New button -->
</#if>
<#if
permissionsMap.DELETE>
<!-- Render a
Delete button -->
</#if>
What do you think?
-Adrian
