[OPEN-ILS-GENERAL] Help with Security

[Stuart Miller]

Thank you. I think (?) I understand what the drop-down list of "location "types" labeled "Depth" does. We did our original location setup just so we could create items. I'm going to have to figure out what that means for security.

In order to use the User Permission Editor, you have to have a barcode to find the user so the admin login I have is not "registered". I assume there is a table where I could find it and all the others. But I assume that the admin login must be "hard coded" since it is not like the others.

Now I know what is meant by the "Permission Editor in the bootstrap interface"--thanks. The terminology was confusing.

Thank you again for your help. I'm sure we will be posting more questions in the future.

Stuart Miller


-----Original Message-----
From: open-ils-general-bounces at list.georgialibraries.org [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of Mike Rylander
Sent: Monday, June 30, 2008 4:13 PM
To: Evergreen Discussion Group
Subject: Re: [OPEN-ILS-GENERAL] Help with Security

On Mon, Jun 30, 2008 at 4:01 PM, Stuart Miller <stuartwm at uchicago.edu> wrote:
> Our Library is attempting to evaluate Evergreen functionality for a large
> academic. I have been trying to figure out how security is set up and am
> running into some walls. Answers to any of the following would be
> helpful-any assistance/advice  would be greatly appreciated. I have a
> feeling that the administrative features/configuration options of Evergreen
> are not particularly intuitive and that getting some  basic training from a
> support vendor would be the easiest way to answer these questions. If anyone
> out there thinks that really is the best approach, we'd appreciate your
> frank advice. Thanks.
>

The setup instructions are detailed here* (particularly, the second
paragraph in the Overview section).  I'll answer the questions in-line
below.

* http://open-ils.org/dokuwiki/doku.php?id=evergreen-admin:policies

>
>
> Stuart Miller
>
> Library Systems Analyst
>
> University of Chicago
>
>
>
>
>
> 1. I assume that the "user group" is a feature that allows for grouping of
> various individual permissions into one setting so that upon registration, a
> user (meaning either patrons or staff members) could be assigned to a group
> and nothing more would be needed. If in fact that is true, I cannot find
> what the documentation wiki identifies as the "Permission Editor in the
> bootstrap interface" which is where I assume I can see what permissions are
> attached to what groups-and where I could create new groups. Is this
> anywhere near correct? If so, where is the bootstrap interface to be found?
> I asked our programmer/installer about this and he had no idea what this
> meant.
>

When configuring Apache, there's a setup stanza for the /cgi-bin/
location.  The configuration bootstrapping scripts live there.  You're
correct that the Groups and Group Permissions section of that
interface allows you to configure the user (staff and patron) group
hierarchy, as well as the the permissions that those groups will have.

>
>
> 2. I found a list of permissions and what they mean in the documentation
> wiki and also found where these can be applied in the client. However, it is
> not exactly clear as to how these work in conjunction with the defined
> locations. I see a location list as we have defined them and then for each
> permission, there is a drop-down under the label "Depth" which contains only
> a few locations. It could well be that we do not understand the location
> structure, but from what I see, only the working location makes sense. I
> further assume that the working location enables the user to perform the
> designated functions for items AT that location from a workstation linked to
> that location--is that correct? And if if there is a link between a
> permission and a user that involves the location, what does the client
> workstation link/location have to do with anything?  Is it intended as an
> extra layer of security?
>

Those depths are not locations, but /types/ of locations.  Say you
have a hierarchy with a type hierarchy of
Consortium->University->Branch, and that you may want to give certain
staff members University-wide permissions for some things (that is,
permissions at all Branches that belong to the university at which
they work, even if they only nominally "work" from one Branch) --
that's how you'd do that.  Most permissions for regular, front-line
staff would be restricted to the Branch (or equivalent) depth, so that
a staff member would only have permissions when logging in from a
workstation registered at that one location where they work.

Additionally, if certain staff should have permissions at some but not
all branches, you can add Work Org Units to the staff member through
the User Permission Editor interface, which would extend their
permissions from their one branch to all those selected.

>
>
> 3. For each permission, there is checkbox for "Applied". If the group to
> which the user is assigned actually contains permissions, then why am I not
> seeing the boxes checked since the user is already assigned to a group when
> s/he was registered? But maybe the user group enables OTHER actions? I did
> figure out that you had to use Circulation's Register Patron feature to
> establish a staff record in order to use the User Permission Editor.
>

The user permission editor is separate from the group permission
editor by design.  A user can be a member of a group that has a more
limited permission set than that one user should have, and their group
permissions can be overridden by user-specific ones.  This includes
permissions that the group already provides, but with a more
restrictive Depth (Branch when the user needs Consortium, say) or
without the grantable flag when the user needs it.

>
>
> 4. I assume "Grantable" means that the user so-granted can come in and
> assign the same permission to another user. Is that correct?
>

Exactly correct.  (With the restriction that they can only assign that
permission to other users that work at a location within their granted
permissions range, as defined by the depth of the permission, and only
assign at the same depth or deeper (more restrictive).)

>
>
> 5. How is it that the admin login we have is NOT also a patron? Or is this a
> hard-coded feature?
>
>

How do you mean?  The admin login is a standard user, though I don't
believe it's in the Patron group.  The one special thing about the
admin user is that it has (by default) the EVERYTHING permission,
which is a special perm that short-circuts all permission testing at
all locations.  Any user can be turned into an admin if they are given
this permission.

--
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone: 1-877-OPEN-ILS (673-6457)
 | email: miker at esilibrary.com
 | web: http://www.esilibrary.com