Hi Alexander,
In data mercoledì, 22 agosto 2012 13.06:16, Alexander Wagner ha scritto:
> Hope you enjoyed those well deserved days off :)
Wonderful holidays :-) But is also great to be back hacking :-)
> Ok. And I understand that I can not have
>
> role: 'Institues-Role-ID'
> role: 'hgfstaff'
>
> either as only one stanza is allowed and role does not allow the comma
> syntax you describe below for firerules, ie.
>
> role: 'Institutes-Role-ID','hgfstaff'
>
> Right?
Precisely. The comma-syntax is available only as part of the firerole language
> Maybe, this however is just thinking out loud now, our main issue stems
> from the connection of roles and the concepts of a group of people that
> should get this role. Together with certain rights on documents in a
> collection. It is a similar to the thesis-example except that we do not
> have document types specified (noting that I didn't really understand
> how this is done in your thesis example, it seems a bit special) but on
> collection membership.
The thesis example is implemented via native WebAccess authorization of a role
to the action "viewrestrcoll" with the parameter "collection" THESIS. You can
in principle achieve similar BibDoc level of restriction via native WebAccess
authorization if you set the "status" of a document to a certain plain string
(provided it's not prefixed by role/firerole/group etc.) and you authorize a
role to the action "viewrestrdoc" with the parameter "status" set to this
particular plain string. It's a bit complex :-) and that's why we extended the
authorization of BibDoc to also directly allow explicit roles/fireroles etc.
> Say, we use external auth via LDAP, I get people belonging to group X.
> On our systems this should trigger to have the right to see a certain
> restricted collection and have access to the (sometimes otherwise
> locked) full texts there. Now a document could belong to the collections
> of group X, Y, Z, so we have the necessity for specifying several groups
> with logical OR. In other words we want to have personal collections for
> groups of people who log in via external auth and who should be able to
> see everything in their collection and other open collections.
If we put a side for a second the problem of restricted documents, and we
focus on restricted collection, I think one possible solution would be to have
one role per LDAP group (exploiting FireRole rules, e.g. "allow group "ldap-
group-foo"), and then have collections based on set of groups of people
authorized to access the corresponding documents. So if the collection "foo"
should be authorized to group X, Y, Z, you can simply authorize these group
(for which it exists each time a role) explicitly via "viewrestrcoll" action.
In this way it will suffice for a person to be member of either X or Y or Z,
and consequently belong to the corresponding role to access the collection,
and all the inner records and documents. Documents are automatically protected
to anybody not authorized to the collection - but the owner of the record (who
always can access attached documents).
In order to enforce this you might wish to create some script that be run
regularly (e.g. via BibTasklet in case of recent Invenio), that looks for all
the groups in the group table (e.g. via
invenio.webgroup_dblayer.get_all_groups_description API) and populate
automatically new roles (e.g. via invenio.access_control_admin.acc_add_role
API).
> Ok, sounds the way to go. As I understan it this would allow all users
> belonging to the group InstitutesID or the group STAFF access to the
> full text. Right?
Exactly.
Hope this helps :-)
Cheers!
Sam
--
Samuele Kaplun
Invenio Developer ** <http://invenio-software.org/>
