It was Igor.Novakovic@xxxxxxxxxxx who said at the right time 16.01.2009
20:33 the following words:
Hi Leo,
first, thank you for your valuable input!
Generally, I see that the security considerations should be taken more
deeply,
for example by looking into the dark cave of SASL/LDAP/Kerberos for
wisdom about authentification,
but for storing user identification and group identification of
indexed
content, I see a complex thing coming up.
As Daniel stated right at the beginning of the description section, this
specification considers only the authorization aspect of the security.
The authentication aspect will be covered in another specification. Our
colleagues from brox have already been working on this and the single
sign-on (SSO) topic and will soon publish their work so that we have the
complete coverage of security in SMILA.
I see that we will probably have to make an internal identification
system,
giving away some internal SMILA ids (SIDs) and this carries with it a
lot of thinking to do...
anyone having a good idea here?
Also, storing these sensible information into normal attributes makes
it
open for easier hacking,
I wonder if some fields should be in protected areas of records.
I understand your concerns, but this problem is not limited only to
document's security information but also to its content and metadata.
What you are talking about is something that I would call the "general
data encryption" issue. In other words: The encryption of all
information (access rights, metadata and the content) that flows
throughout SMILA and is being persisted in storages. This case is
relevant if you do not trust the network that connects SMILA nodes
and/or you do not want the SMILA administrator to be able to read/modify
any data.
Currently we haven't posed such requirement on SMILA, but if you think
that this might be a relevant in your SMILA based projects, please feel
free to open a new Wiki page and address this issue and let us discuss
it.
no, I just meant that we may want to set (in the API, in the data flows
maybe also)
some fields as "read only".
If signatures are needed to enforce the "read only" in xml messages,
then this is also interesting,
but primarily: who can edit the access rights....
but I am not an expert on these things - you guys have more practical
experience,
I don't want to invent a monster if there is none..
best
Leo
Best Regards
Igor
_______________________________________________
smila-dev mailing list
smila-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/smila-dev
--
____________________________________________________
DI Leo Sauermann http://www.dfki.de/~sauermann
Deutsches Forschungszentrum fuer
Kuenstliche Intelligenz DFKI GmbH
Trippstadter Strasse 122
P.O. Box 2080 Fon: +49 631 20575-116
D-67663 Kaiserslautern Fax: +49 631 20575-102
Germany Mail: leo.sauermann@xxxxxxx
Geschaeftsfuehrung:
Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
____________________________________________________
|
