[OPEN-ILS-DEV] ofbiz users and permissions

[Bill Erickson]

I've been digging through the OFBiz permissions infrastructure to better
understanding the workflow.  Thought I'd share some thoughts and findings...

A permission is a combination of an application (entity) and an action: e.g.
FACILITY_UPDATE.  There is the typical approach of user X has permission Y,
so let the action proceed.  There is an additional concept of
context-specific permission roles.  For example, if user X needs permission
to update certain facilities, but not all of them, user X would be given the
FACILITY_ROLE_UPDATE permission and one or more Roles would be created which
link the user to a specific set of facilities.   Role based permissions are
not quite as common from what I can tell, but they will give us a way to
limit what data librarians are able to create/view/update/delete, both from
the UI perspective as well as in the business logic.

As far as users go, OFBiz has Party's, which can be thought of as abstract
entities, manifesting themselves as Person's or PartyGroups.

How do we integrate users and permissions with Evergreen?

1. Is single sign-on a requirement between the staff client and the ACQ
system?

Yes

2. Is it a requirement that Evergreen user objects "magically exist" inside
the ACQ system?  Meaning, it should not be necessary for an admin to
manually create users in the ACQ system if they already exist in EG.

I'd say yes.

3. As an addendum, should it be impossible for an admin to create a user in
the ACQ system if the user does not exist in Evergreen DB?

I'd say yes, if the above is true.

4. Should the system avoid duplication of information by /not/ storing user
objects directly in the ACQ system.

I'd say NO to this, mainly because I'm concerned about the development
effort required to extract these heavily used objects from the OFBiz core.
There is a whitepaper at
http://docs.ofbiz.org/download/attachments/440/EELDAP-analysis-finaldraft.pdf,
which posits an LDAP plugin could be built for OFBiz, which would allow an
external user database, by a competent engineer in 60-80 hours.  Evergreen
isn't LDAP, but the mapping process would be similar.  Given that none of us
(that I know of) are experts in OFBiz internals,  I'd say that's an
optimistic time estimate.


What I'm imagining is the Evergreen staff client passing the usual Evergreen
auth token as a URL param to the OFBiz interface.  A pre-login process will
perform the following:

- load the user from the EG database
- make sure the user is active and has ACQ_LOGIN (or similar) perms.
- check to make sure this user is represented in the OFBiz DB and, if not,
create a record for the user in the OFBiz DB.
- continue with login

Make sense?

I'm not sure how this will work exactly, but I'm confident it can be done.

Let me know if I'm being short-sighted, unnecessarily complex, or completely
off base with any of this.

This email is getting too long :) We haven't even gotten into groups and
perms yet.  More questions to come...

-bill

-- 
Bill Erickson
Equinox Software, Inc.
erickson at esilibrary.com
http://esilibrary.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.georgialibraries.org/pipermail/open-ils-dev/attachments/20070809/7fbf921c/attachment-0001.html