Minutes: Friday 16th January AM
These notes are in addition to the slides, and dont repeat their content. See the slides on the
agenda page for more information.
---
R-GMA Security: Current Status, Authorization Design and Implementation Strategy
Linda Cornwall
---
Authentication
The authentication mechanism will change with Web Services.
Authentication on every call is inefficient perhaps save details at each end of communication to
allow one-time authentication.
Web Services: authentication in Tomcat and/or Axis.
Not many Web Service security implementations available.
Potential difficulty because of non-standard proxy certificate.
Authentication is part of the ServletConnection.
Current restrictions
References to Web Browsers are related to the R-GMA BrowserServlet.
Problem is with authenticating a service to a user using a proxy certificate.
Internet Explorer: does not work.
Netscape: works (use Accept for this session to avoid additional fiddling)
IETF are working on the problem what is the timescale for this?
Suggested solutions:
· Use a local server that the browser contacts and which in turn contacts the remote server.
· Use proxies on all components except the browser.
· Make browser insecure, but this could be dangerous perhaps the feature set of the browser would
need to be restricted.
The host-deny/-allow feature in R-GMA can be used to further restrict access.
This is an EDG/EGEE-wide problem; could security group JRA3 write an IE plug-in?
Compare WP3 approach to EDG in general and Globus.
EDG supports delegation in Java, but it involves copying the proxy and private key, which is a bit
of a fudge.
Authorisation EDG Principal
Auth. of resource vs. information.
A resource doesnt move around.
Information provider deals with authorisation.
Differentiate between where the decision is made and who makes the decision.
Security information must be published with the data if the decision can be made by any user of the
data.
Coarse- vs. fine-grained
Fine-grained = within R-GMA (application specific)
Coarse-grained = Tomcat / Axis.
Distributed and onward connection authorisation
1. Only pass on information to authorised principals: agreed!
2. Producers only pass information into R-GMA if requested by an authorised principal: this
behaviour is only available through the Canonical Producer (credentials from consumer would be
passed to the producer). In standard R-GMA, data is always pushed, regardless of whether its
requested.
3. Encrpyt information: this would be user-implemented.
Authorisation on views
Steve Fs Interesting Thought:
· Could the provenance of tuples (i.e. MeasurementHost) play a part in this?
Where to specify authorisation rules
Schema
Shouldnt have per-row authorisation, should have global security.
Schema stores one set of rules per table.
Registry
Archivers become horribly complicated if security data is held in the registry (i.e.
per-producer).
Authorisation then has to go with data.
If producer views dont overlap, work out where row comes from (provenance) and therefore which
rules apply.
Make sure rules are sufficiently general for a table, so all potential producer of it can make use
of it.
Per-item
Each item (row) of data has its own rule: too complex!
1st Step for authorisation
Set-up of /decision on Schema vs. Registry.
This should be 2nd step: first should be to define the security rules.
Look at GACL (possibly extend?) & working groups Andrew McNab
There shouldnt be a flag indicating info available but the user isnt authorised.
Confidentiality
Security of security data (and metadata in general).
Potentially hide the registry completely.
Other steps
Security needs to be part of the redesign: designed by month 5, implemented by month 9.
---
Mediating Better Answers
Andy Cooke
---
Current Situation
Naming revisit all names in design (org.eu-egee
)
An adventurous answer can be:
· Incomplete
· Wrong
· Meaningless
A publisher is a producer or a republisher (archiver).
Some definitions (from later on in the discussion, but they probably should have come here):
· A publisher is complete if it has all published tuples that match its predicate.
· A publisher provides a full view if it publishes for the whole table (i.e. no predicate).
RGMAWarnings
Not thrown.
Uses chaining, as in exceptions, but unclear whether this has any meaning/use.
Need to add error code to make determining errors more easy (this applies to RGMAExceptions too).
Assumption of completeness:
· LRP always complete.
· LP complete if only one LP.
Queries with COUNT, NOT, AVERAGE etc. are more prone to problems.
Improving One-Time Queries
If the producer used the same (incomplete) data set to answer queries:
SELECT * FROM X would be correct, but incomplete.
SELECT COUNT(*) FROM X would be wrong.
User control of Quality of Service: if user doesnt care about completeness, they should be able to
get a quick-and-nasty answer.
Contact PolarStar, re distributed queries.
Continuous Queries
Code in Registry stops a continuous query going to republishers.
Problems surrounding network outage while streaming.
Min retention period should be set only once, in constructor add forceClose() or cleanAndClose()
method to close down a producer and force it to clear out its tuples (equivalent to setting MRP =
0). This removes the problem of setting MRP while streaming.
Use latest snapshot to recommence streaming snapshot needs to be latest per primary producer,
not per primary key as defined by the user. (But, MeasurementDate/Time arent unique, so which of
two identical tuples was the last sent? Perhaps unique tuple numbering is required).
Could this produce too big a load on the republisher?
Tuple tagging (adding originating host name to tuples) could be of use.
---
Logging Accounting Information
Antony Wilson
---
Resilient streaming = DataBaseProducer + streaming.
Need to add streaming direct from database.
Could then very easily provide extra consumer flag, e.g. FROM, where you define the tuple time to
start streaming from.
Asides
Keeping streaming sockets open can be inefficient if they are rarely used. Add timeout to close a
socket after a fixed period of inactivity.
Use of JMS instead of current 8088 streaming implementation. Use JMS API for current streaming, so
that any third-party software could be easily plugged in.
JMS could provide guaranteed delivery.
Is there an open source/free JMS implementation?
