Hi,
An example from the field may be helpful here.
The TeraGrid (www.teragrid.org) uses MDS4 to publish quite a lot of
information about the HPC resources offered throughout the system.
Each resource runs an index service that provides access to info about
the local system, and a central index (implemented as a high-
availability service) indexes data from each of the local index
services. The data in the central indices is in turn used for many
purposes: to populate user documentation web pages, to autoconfigure
automated system tests, to support metascheduling/brokering services,
and to populate system status web pages (e.g., current resource queue
sizes, etc.).
This is similar to what you describe because TeraGrid's current policy
is to restrict access to queue data to authenticated users; i.e.,
people who have logged in to the TeraGrid user portal using a personal
ID/password. The rest of the data needs to be openly accessible. Not
only do we not want the rest of the data to be restricted, but we
don't even want clients to have to authenticate (present a
certificate) *at all*.
To make this possible, TeraGrid runs two index services at each
resource. These services run in the same Web services container (GT4
container), but they are configured differently: one has
authentication enabled, the other has it disabled. The authenticated
index service publishes the queue status information. The non-
authenticated index service publishes everything else (including the
list of queues that are available in the other index service). The
central indices index the non-authenticated data (containing queue
pointer info), and this allows users and automated tools to discover
queues, but not get the queue status. To get the queue status, they
follow the pointers to the authenticated index service and
authenticate to get the status data.
We took this dual-service approach (rather than trying to restrict
subtrees of the information space in a single service) for two reasons:
1) We didn't want to require authentication for the non-restricted
data, and there isn't a way to configure a single index service to
allow BOTH non-authenticated and authenticated access.
2) When you have a central index that indexes data from multiple local
index services, it seems very complicated to not only index the data
but also the access control information (which includes knowledge of
the individuals and/or attributes used to make decisions). I don't
think the MDS4 implementation supports this, though I suppose it may
be possible using specialized authorization plugins.
In any case, we found it a lot easier and more straightforward to just
use two index services. Keeping them in the same WS container
minimizes the overhead of having more than one index service.
-- Lee
On Apr 4, 2008, at 8:40 AM, Benjamin Henne wrote:
Hi.
To query a MDS, for example with
wsrf-query -x -s https://myhost.mydomain.tld:8443/wsrf/services/DefaultIndexService
,
I have to do this with an user who has a valid proxy certificate.
So far I have worked with MDS.
I have some (theoretical) questions about MDS and authorization.
Can I exactly specify which users may or may not access resource
information at a MDS?
Ok, but furthermore, is there a way to restrict access to resource
information, so that one user can only see some parts while another
can see all?
I am thinking about something like LDAP's possibility to restrict
access to attributes depending on user authorization.
I came to this question when thinking about usage of resource
information with maybe different "security levels". Of course there
could be a scenario where it would be very beneficial to have some
resource information for e.g. a scheduler, but one doesn't want to
announce (all) those information to all users having access to the
MDS this theoretical scheduler uses to get resource information.
Maybe, someone of you may tell me his or her ideas about this.
It is nothing like a feature request, only some theoretical
questions/thoughts.
Regards,
Benjamin
