Islandora Drupal Filter additional attributes

108 views
Skip to first unread message

Tomasz Cielecki

unread,
May 19, 2011, 10:06:08 AM5/19/11
to islandora
Hello!

I have been researching the Islandora Drupal Filter and have found out
that it explicitly only takes roles from Drupal and passes on to
Fedora, along with the username trying to log in. This is in some
cases not enough information to authorize users to specific data
through FeSL or the old XACML.

I have modified the Islandora Drupal Filter to take more information
and pass on to Fedora, which is determined from the columns fetched
through filter-drupal.xml. It takes all columns apart from, userid,
password and name, since they are already set, and creates attributes
with values determined by the column label.

I have added my modified source here: https://github.com/Cheesebaron/Islandora_Drupal_Filter

Reproduction steps (Fedora installation is a prerequisite, I used it
with FeSL):

*1. Add following lines to fedora-auth {...} in the file $FEDORA_HOME/
server/config/jaas.conf:*
ca.upei.roblib.fedora.servletfilter.DrupalAuthModule required
debug=true;

the section should now look like this:
fedora-auth
{
org.fcrepo.server.security.jaas.auth.module.XmlUsersFileModule
required
debug=true;

ca.upei.roblib.fedora.servletfilter.DrupalAuthModule required
debug=true;
};

*2: Enable the servlet filter by creating a file filter-drupal.xml in
$FEDORA_HOME/server/config*
Use the filter-drupal.xml file provided, or use mine as an example,
make sure you have the same profile_fields as I have or SQL query wont
work.

*3: Make sure you have a mysql connector for tomcat, if not get it
here: http://dev.mysql.com/downloads/connector/j/*
Place it in $CATALINA_HOME/webapps/fedora/WEB-INF/lib

*4: Pull my code from git and compile it*
mvn install
Then place the generated jar file in target to $CATALINA_HOME/webapps/
fedora/WEB-INF/lib

If maven complains about pom files which it is not able to locate, you
might have to compile the entire fcrepo and generate generic pom
files. Which is done like this:
Instructions on compiling fcrepo are found here:
https://github.com/fcrepo/fcrepo/blob/master/README

Generating generic pom files are done like this:
mvn install:install-file -Dfile=<path/to/jar> -DgroupId=your.groupId -
DartifactId=your-artifactId -Dversion=version -Dpackaging=jar -
DgeneratePom=true

Now you should be able to compile my code. Put the generated .jar file
in target in: $CATALINA_HOME/webapps/fedora/WEB-INF/lib

To see which attributes a user has authenticate against Fedora with
your drupal username and the password hash value from the database, I
did it by going to /fedora/object and pressing search. Then going to /
fedora/user lets you show the authenticated users attributes.

With the filter-drupal.xml file supplied with my modified source code
this is the result:

<user id="KED">
<attribute name="Host"/>
<attribute name="role">
<value>administrator</value>
<value>authenticated user</value>
<value>local editor</value>
</attribute>
<attribute name="fedoraRole">
<value>administrator</value>
<value>authenticated user</value>
<value>local editor</value>
</attribute>
<attribute name="Orgid">
<value>200</value>
</attribute>
</user>

The attribute names will use the label provided in the filter-
drupal.xml, the implementation is limited by that ALL names must have
a label.

I hope this will be useful to someone, or maybe you might consider
merging it upstream as it might be useful to other people using Drupal
along with Fedora and want to authorize against additional attributes.

--
Best regards
Tomasz Cielecki

Paul Pound

unread,
May 20, 2011, 11:34:22 AM5/20/11
to isla...@googlegroups.com
Thanks for taking the time to pass this on.  I'm sure it will get discussed at our next meeting and hopefully we can incorporate it into the current filter

thanks again,
Paul


--
You received this message because you are subscribed to the Google Groups "islandora" group.
To post to this group, send email to isla...@googlegroups.com.
To unsubscribe from this group, send email to islandora+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/islandora?hl=en.


Jonathan Green

unread,
May 25, 2011, 10:20:20 PM5/25/11
to isla...@googlegroups.com
Thanks Tomasz for contributing this back to us. We very much appreciate the effort.

I've added discussing your changes to next weeks committers meeting agenda, and we will see if we can bring your changes in upstream so everyone can benefit. If your not already you might want to consider joining the islandora-dev mailing list.

Cheers,
Jonathan
--
Jonathan Green
DiscoveryGarden Inc. 
Sims Office Suites Building, 3rd Floor, 118 Sydney Street 
Charlottetown, PE C1A 1G4 
902.367.3851 discoverygarden.ca 
joan...@discoverygarden.ca
skype: jonathan.edwards.green

Tomasz Cielecki

unread,
May 26, 2011, 12:26:22 PM5/26/11
to islandora
I appreciate the appreciation.

Before bringing the changes upstream, you should consider putting some
of the helper methods I made into a class on its own as the methods
are the same in both classes I changed. I will look at joining the
islandora-dev list and see if there is anything I can help with.

On May 26, 4:20 am, Jonathan Green <jonat...@discoverygarden.ca>
wrote:
> joant...@discoverygarden.ca
> skype: jonathan.edwards.green

--
Great Winds and Best regards
Tomasz Cielecki

Tomasz Cielecki

unread,
May 27, 2011, 7:14:36 AM5/27/11
to islandora
About creating that class on its own. Is there any reason why you use
Logger in DrupalAuthModule and Log in DrupalUserInfo?

Tomasz Cielecki

unread,
May 27, 2011, 8:22:14 AM5/27/11
to islandora
Ok I have now updated my repo with some changes. I have moved out some
methods in its own class as they are used in the two classes
DrupalAuthModule and DrupalUserInfo.

Jonathan Esterhazy

unread,
May 26, 2011, 8:01:03 AM5/26/11
to islandora
The IIVFeslAdapterFilter.java I built for the islandora_dm project
should be fully compatible with this new filter. We probably should
deprecate the old IIV filter, rather than backport these mods.

On May 25, 9:20 pm, Jonathan Green <jonat...@discoverygarden.ca>
wrote:
> joant...@discoverygarden.ca
> skype: jonathan.edwards.green

Tomasz Cielecki

unread,
Jun 22, 2011, 5:07:13 AM6/22/11
to islandora
Hello,

Just to let you know. As it is now FeSL apparently does not support
using these attributes in XACML policies yet. So a workaround could
actually be to put those attributes inside the fedoraRole. So with my
sollution, you could just label the column Role, as more than one
column can have the same name, and it should then be picked up and put
into fedoraRole.

I have raised a JIRA ticket to enhance the functionality of FeSL to in
the future somehow support these extra attributes.
https://jira.duraspace.org/browse/FCREPO-957

--
Best regards
Tomasz Cielecki

On May 26, 2:01 pm, Jonathan Esterhazy <jonathan.esterh...@gmail.com>
wrote:

Tomasz Cielecki

unread,
Jun 22, 2011, 8:15:43 AM6/22/11
to islandora
Hello again,

I discovered that renaming the column did not work. So to get your
values under the Role column you should do it by using a little bit
more advanced SQL query. I.e. I am getting both roles and organization
ids stored in profile fields here:

SELECT userid, Name, Pass, Role, Host
FROM (
SELECT u.uid AS userid, u.name AS Name, u.pass AS
Pass, r.name AS Role, s.hostname AS Host
FROM
(((users u LEFT JOIN users_roles ON
u.uid=users_roles.uid)
LEFT JOIN role r ON r.rid=users_roles.rid)
LEFT JOIN sessions s ON u.uid = s.uid)

UNION

SELECT us.uid AS userid, us.name AS Name, us.pass AS
Pass, prv.value AS Role, ss.hostname AS Host
FROM
((users us LEFT JOIN profile_values prv ON
us.uid=prv.uid)
LEFT JOIN profile_fields prf ON
prv.fid=prf.fid)
LEFT JOIN sessions ss ON us.uid = ss.uid WHERE
prf.name="profile_orgid"
) q
WHERE q.Name=? AND q.Pass=?;

This is done by doing a UNION on the two SELECTs. It might be that
there are other methods of doing this, but this is one solution. As a
result
I get this user:

<user id="toci">
<attribute name="Host">
<value>127.0.0.1</value>
</attribute>
<attribute name="role">
<value>administrator</value>
<value>236</value>
</attribute>
<attribute name="fedoraRole">
<value>administrator</value>
<value>236</value>
</attribute>
</user>

Ofcourse if I wanted the Host to be under the roles I should probably
do another UNION to get the data there.

On Jun 22, 11:07 am, Tomasz Cielecki <tom...@ostebaronen.dk> wrote:
> Hello,
>
> Just to let you know. As it is now FeSL apparently does not support
> using these attributes in XACML policies yet. So a workaround could
> actually be to put those attributes inside the fedoraRole. So with my
> sollution, you could just label the column Role, as more than one
> column can have the same name, and it should then be picked up and put
> into fedoraRole.
>
> I have raised a JIRA ticket to enhance the functionality of FeSL to in
> the future somehow support these extra attributes.https://jira.duraspace.org/browse/FCREPO-957
Reply all
Reply to author
Forward
0 new messages