On 22.08.2012 13:34, Samuele Kaplun wrote:
Hi Samuele!
Wonderful holidays :-) But is also great to be back hacking :-)
:) Nice to hear both of that :)
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.
I saw this but there is also some parameter for viewrestrdoc
involved at some point if I remember correctly...
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 :-)
Yes. It seems I see a bit clearer now.
Let me summarize if I get it right. viewrestrdoc gets a
parameter. This parameter is a free form string, I can use
whatever I want here. Then I can add the action viewrestrdoc
to a role and specify this very string to get some access to
the full text in a way orthogonal to the collection
association. I'm not yet sure if this solves an issue for
our case but options are always interesting. ;)
Let me make a real world example what we have. Some Marc
stub:
001 123
245 $aMy important paper
980 $aI:(DE-Juel1)ZB-20090406
980 $aVDB
Now we have a collection named ZB-20090406 with
collection:"I:(DE-Juel1)ZB-20090406" as query, so this
record belongs to this very collection. And a collection
named VDB with collection:"VDB" as query.
Now I want collection ZB-20090406 to be restricted, so I set
up a role I-ZB-20090406 with these firerules:
allow groups 'I:(DE-Juel1)ZB-20090406 [FZJ eMail-Account]'
allow groups 'STAFF'
And I add viewrestrcol with parameter ZB-20090406, ie. the
colletctions internal name.
All this magic restricts access to my collection
ZB-20090406 to all users belonging to the group
'I:(DE-Juel1)ZB-20090406 [FZJ eMail-Account]' (this is from
LDAP auth) and additionally allows all users in the group
STAFF access to the records of this collection and as such
to my very important record 123 above.
If I now attach a pdf to my record 123 this is, however, not
restricted till now. Only the record as such has a
restriction, but if someone would know the direct url to the
pdf no restriction would apply. (Is this right?)
Now, you say I could set the status of this document to say
"I:(DE-Juel1)ZB-20090406" in some way I don't yet know, but
surely our websubmit guru (aka Tomek) knows and could pass
this string to the viewrestrdoc action. Add this action to
my above defined role could gives access to all users of my
group I-ZB-20090406 to the document.
I could shortcut much of this fuzz woudn't be there the open
collection VDB above which should actually see the
bibliographic record, but may not (yet) have access to the
full text for some reasons.
and that's why we extended the authorization of BibDoc to
also directly allow explicit roles/fireroles etc.
This is the $r-subfield in the fft-tag. Right?
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.
This is what we actually do. We set up a collection for each
institute (as outlined above) and add a role with actions
attached.
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.
Right. But then I do not yet have the full texts restricted
but only the bibliographic record.
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).
This would suffice indeed if we didn't have an open
collection that our records belong to in many cases. You
might remember that you prepared a patch for us that allows
for "if any rule matches" in the firerules block.
In order to enforce this you might wish to create some
script that be run regularly
Done :) I think we have everything in place except the the
doc restrictions (which wouln't be necessary in the first
place if Science would really be free <scnr> ;)
(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).
This is a bit more involved here as we acutally need to
harvest the LDAP (or a similar) system and also need to
generate a bunch of "bibliographic" records thereof. You
probably remember our discussion @CERN about authority
control where we use authority records living in MARC
instead of knowledge bases. (I think we should definitely
take a cup of tea over these issues in the near future, ie.
as soon as our stuff went publicly online.)
Anyway, basically we need to set up those records in this
step as well. For those following this far and wondering
"why the h... does he use so complex naming schemes", this
is the very reason: mapping institute histories, hierarchies
and rights with a bunch of collections living in t=now and
not valid for t=tomorrow in a managable way.
--
Kind regards,
Alexander Wagner
Subject Specialist
Central Library
52425 Juelich
mail : [email protected]
phone: +49 2461 61-1586
Fax : +49 2461 61-6103
www.fz-juelich.de/zb/DE/zb-fi
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Kennen Sie schon unsere app? http://www.fz-juelich.de/app
