[kepler-dev] kepler actors repository and LDAP authentication

Matt Jones jones at nceas.ucsb.edu
Fri Aug 29 11:10:33 PDT 2008


Hi,

The Kepler Repository uses the Metacat metadata and data server to store KAR
files and associated metadata.  The server is also used as the basis for the
KNB data sharing system (http://knb.ecoinformatics.org/) that spans hundreds
of environmental field stations distributed around the US and globally, and
thus was built with access control across distributed institutions as one of
its main features.  It provides a set of services for inserting, updating,
deleting, and searching metadata files that are represented in XML, and for
storing the associated data files.  In the Kepler Repository, we use the
MoML file as the metadata and KAR files represent the data payload.  Because
Kepler MoML files include full documentation about actors as well as
semantic annotations, this metadata is accessible in Metacat and provides
for an effective search and discovery mechanism.

On Fri, Aug 29, 2008 at 3:49 AM, dejw <dejw at man.poznan.pl> wrote:

> 1. MS Active Directory:
> I saw that the kepler actor's repository authenticates user against LDAP
> server (for example if I want to put there some actor definition).
> I wonder if it is possible to configure kepler to use Microsoft Active
> Directory which is as I know in fact some LDAP kind of server.
> Did someone tried to use it with Kepler?

Metacat does indeed use LDAP as its backend authentication system, and can
be configured to use any backend system that is LDAP compliant. I suspect
Active Directory would work, but we have focused on open source solutions,
and so we have used OpenLDAP in our deployments and have not tried AD.

>
> 2. Authentication and authorization as regard repository:
> How works generally the repository access ? There is some authentication
> module which takes LDAP login and later stores objects on behalf of some
> user?

The LDAP server stores user credentials and is used only for authentication
of users.  Metacat itself maintains access control lists for  the individual
data and metadata objects, which can be set with the setAccess() interface
in Metacat.  When a user attempts to create an authenticated session with
Metacat (e.g., in order to be able to upload a new actor), they pass their
credentials to Metacat, which then checks this against the LDAP server.  So
LDAP has a relatively limited role in the whole system (and could actually
be replaced by a different system if needed).

>
> If I have LDAP user: UserA then if object is put inside the LDAP the
> name of the user is also stored in the repository? I understand yes?
> Because there is a Private role so then a user name is  persisted?
> So if I would like to access the repository from some external module -
> there is some web service which takes LDAP credentials and return
> objects only for the given user?
> If there is object inside the repository with the Public role then user
> name is not checked or something?

When a user creates an authenticated session in Metacat, their session has a
reference to their LDAP Distinguished Name (DN), which is used as the
'owner' for all objects that they upload.  Initially objects uploaded are
only viewable by their owner -- nobody else can see them.  The owner can
then use Metacat's 'setAccess()' interface to additionally allow other users
to access the objects (e.g., to grant read access to the 'public' user).
The public user is a special virtual user that allows anonymous access.  In
Kepler, the user interface only allows one to set the uploaded actors to
private or public, even though Metacat itself supports more fine-grained
access control lists.  This was done mainly to simplify the user interface,
and is something we planned to revisit in future work (some of our other
data sharing software provides a UI for setting fine-grained access
constraints, so we can probably build on that).

>
>
> 3. Is there any API available to use the repository: search for objects,
> manage objects etc.

Yes, Metacat supports the EarthGrid web service API, which provides methods
for searching the metadata, getting back a synopsis of the metadata
documents that match, and downloading, inserting, updating, and deleting
objects in the repository, among other things.


>
>
> 4. Is there any simple tutorial how to setup and configure own kepler
> repository?

There are instructions for how to set up a Metacat server in general, but we
have not developed a specific document that describes how to use a Metacat
server as a Kepler Repository.  The configuration is somewhat involved,
although it mainly involves 1) setting up Metacat, 2) registering the new
repository with Kepler so that it knows where to contact the appropriate web
service interface.  There have been previos emails to kepler-dev descibing
how to do this.


There's a  renewed interest in the repository and in web-based user
interfaces.  Several of our projects are planning to continue the work that
was started with the repository, and so a new collaboration group for the
workflow repository will be formed sometime soonish.  The Web user interface
group also has done some related work, so you may want to participate in
their discussions in the kepler dev site as they get going.

Matt

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matthew B. Jones
Director of Informatics Research and Development
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara
jones at nceas.ucsb.edu Ph: 1-907-523-1960
http://www.nceas.ucsb.edu/ecoinfo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20080829/fe0d62c6/attachment-0002.html>


More information about the Kepler-dev mailing list