Rm meeting february 3, 2012

Agenda

1. Security: I propose a potential change in the way we do Islandora security and would like to get some feedback: I would like to have Fedora live behind a firewall, so that we don't have to handle security at the Fedora level. The biggest thing that this allows us is that we can move away from the Fedora security model, where every object has a policy, to a model where we can inherit security from say parent collections. This would assume that only authorized applications have access to Fedora, it is not open to the public.
2. Final Decision on Supported OSes: Ubuntu LTS and CentOS 5.7. Any objections?
3. Update on Solr Views from Donald and Kirsta

• Further discussion on how we should use Views.

5. Progress update
6. Timing of next meeting

Meeting Minutes

This meeting got a bit off track because of the lack of attendees.

1. Discussed security. Didn't discuss Jonathans idea of Fedora behind a firewall, because everyone at the meeting had already talked about it. Discussed Ben's idea of using objects in Fedora to manage security. Each user created in Drupal would have an object in Fedora. Could possible hook the user creation system in Drupal.

Hi Ben, Sorry I had to leave our meeting early today. I've been thinking a little about security and what you mentioned regarding the fedora objects. I think it's an interesting concept and may also work with what we are calling our Authority module (which is really a bunch of objects in Fedora that represent authors or institutions, then when filling out forms this list could help populate dropdowns etc.). Since we need to represent people in the repo anyway it may make sense to use the same or similar objects for authentication and authorization. We would still need a servlet filter of some kind to query the Fedora objects and a way to sync the drupal users with the fedora objects etc. Some of it we could do with hooks something like this:

<?php
/**
 * drupal hook_user
 * @param string $op
 * @param object $edit
 * @param object $account
 * @param <type> $category
 */
function sidora_islandora_user($op, &$edit, &$account, $category = NULL) {
 //@TODO add form elements for further info so we can populate more of the eac-cpf record (op == 'register' or op == 'edit')
 //@TODO will aslo have to update the eac-cpf on user update (op== 'update').
 module_load_include('inc', 'sidora_islandora', 'si_util');
 if ($op == 'insert') {
   $pid = sidora_islandora_create_user_object($edit);
 }
 if ($op == 'view') {
   $arr = unserialize($account->data);
   $pid = $arr['islandora_user_pid'];
   $account->content['islandora_user_pid'] = array(
     '#title' => t(' '),
     '#value' => l(t('My Projects'), 'fedora/repository/' . $pid),
     '#class' => 'islandora_user_pid',
     '#type' => 'user_profile_item');
 }
}

The function sidora_islandora_create_user_object($edit) would become a function in our user api etc. This user api could be called by other frontends if required.

I do see some potential pitfalls as well but it might be the right way to move our security forward. Can you spend sometime on this to see if you think it is feasible and document or code what we would have to store in Fedora etc.?

Attendees

Jonathan, Paul, Ben