-
Notifications
You must be signed in to change notification settings - Fork 1
/
README
1828 lines (1493 loc) · 59.8 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Caume Data Security Engine (CaumeDSE) version 1.0.3
CONTENTS
========
I. Purpose and philosophy
II. Status
III. License
IV. Architecture and functionality
V. REST (Resource) API reference
VI. Contributing
VII. Security considerations
I. Purpose and philosophy
-------------------------
1. Purpose
The idea behind CaumeDSE is to provide a free software solution that
allowed the creation of reasonably secure and isolated workspaces to process
and store sensitive data, within uncontrolled environments.
With concepts such as the cloud and bring your own device as well as an
increasing demand for mobile devices, it has become clear that the way in
which companies operate is changing dramatically, and with it, the way in
which we secure information and the infrastructure that supports business
processes.
CaumeDSE has been designed as a service platform that provides security to
data by using free, well known and robust cryptographic software, as well as
open an simple data structures and interfaces to make portability and
extensibility easy.
CaumeDSE is not an end-user solution. It is a service platform for
sopporting front end applications.
2. Philosophy
CaumeDSE is designed with solid security principles, that take into account
new models of doing business and emerging information technologies. It also
takes into consideration the increasing number of data privacy regulations.
Trust is essential for security. In fact, it is one of the main reasons why
we put security in place on computer systems: to be able to trust them. We
aim to provide trust by following these principles:
* Transparency. With free, open source software, you can check for yourself
what this software does, and know that others can and will do it as well
to help improving it.
* Portability. With open standards and data structures, you avoid vendor
lock-ins with closed programs/technologies. Moreover, by being free and
open source, this platform can be ported to many environments and modified
to suit your own needs. You don't depend on a company being there to
continue its development.
* Simplicity. We favor simplicity for doing all tasks as much as possible.
With the adoption of REST, we expect that interaction and development with
this platform will be easy and straightforward.
* Secure by design. We developed this tool with security as a primary goal.
That is not to say it is perfect, but its development process has been
structured to ensure continued improvement in this area, independently of
other important requirements such as performance and interoperability
* Need to know and use. We restrict as much as possible the access to
information. One way that we do it is by not storing encryption keys
within the software. This means that each organization (in the scope of
this software) is responsible of managing keys securely, but it also
allows them to have full control of who access what.
* Traceability. Logging securely all relevant actions provides good control
on who did what, when, as well as evidence in case of an incident.
* Thoroughness. We aim to do extensive debugging and security assessments
before any major release. This won't eliminate all problems, but should
limit their number and provide a more stable platform. We favor stability
and simplicity over new functionality, since the later can be developed
easily on top of this platform by other software.
There are some important aspects regarding trust. Achieving trust is
difficult, particularly since we human beings posses a natural bias towards
risk assessment (e.g. we tend to think that the closer to us things are,
the more secure they are).
No matter how sensitive a particular piece of data is or how much money you
are willing to invest to protect it, in the end, for it to be useful, you
will need to trust someone and/or something.
There are many arguments in favor of hardware based protections, and it is
true that such devices are usually more resistant to certain types of
attacks than software, but you still end trusting the manufacturer of such
products as much as you need to trust the developer of security software.
Also, specialized hardware may offer better performance than software for
some tasks, such as higher resistance against reverse engineering and
internal processing monitoring.
Like there are disadvantages to a software based approach, there are also
some advantages to it. Transparency is one of them.
Even if your won't be checking the source code yourself, you know that it is
available for many others to take a look at it (so the chances of finding
problems and fixing them may be higher than that of closed hardware
solutions).
Another advantage is portability. Think about some possible scenarios you
may face with new operation models such as the cloud. An infrastructure
provider in the cloud may not be offering hardware based security solutions,
or you may not be able to install in their premises your preferred hardware
based solution. But still, if you have some control at some layer of the
environment where data will be stored, transferred or processed, you can
setup your "rules of engagement" there and create a virtual perimeter that
may offer a reasonable level of protection for your data.
In terms of compliance, remember that when you contract external services
and personnel you may share with them some responsibility for protecting
sensitive data and operations, but you cannot share accountability; that
will remain on your side.
II. Status
----------
Right now, the software is in a stable release:
* Basic functionality is complete and tested but some features are
still pending.
* Basic documentation is available.
If you would like to collaborate Please take a look at section VI
(Collaborating).
III. License
------------
Caume Data Security Engine (also called CaumeDSE) is released under the GNU
General Public License version 3 by the Copyright holder, with the
additional exemption that compiling, linking, and/or using OpenSSL is
allowed.
The software is Copyright 2010-2021 by Omar Alejandro Herrera Reyna.
Check licensing and copyright details for CaumeDSE and other included
software in the file called COPYING and in the headers of the source code
available for distribution.
IV. Architecture and functionality
----------------------------------
1. Layers
The architecture of CaumeDSE is composed of several layers:
1. API - Web based, RESTful API that handles requests to resources
using standard HTTP methods (GET, POST, PUT, DELETE, HEAD and
OPTIONS). The requests can be received by HTTP (TCP port 80;
only in DEBUG mode) or by HTTPS (TCP port 443). Libmicrohttpd is
used as an internal, standalone web server to handle the
requests, while TLS security is handled by GnuTLS. Standard
query parameters and multipart/form-data encoded parameters (for
POST method) are supported in resource requests.
2. Authentication - Authentication of users and applications is
handled at the web server level. Right now, client
authentication with digital certificates with TLS is supported.
3. Authorization - Authorization is handled internally by CaumeDSE
with role tables for each user. Each role table maps each
available resource type with available HTTP methods (GET, POST,
PUT,...). All roles are encrypted with the organization's key
(see resource hierarchy below).
4. Resource access - CaumeDSE maintains internal index databases
that map data resources to their location. All resources and
index database registers are encrypted with the organization's
key. Currently 3 types of data resources are supported: raw
files, CSV files and Perl scripts. File resources in addition
are split in several parts (CSV files are split in columns and
each column in different parts of a specific size).
5. Resource protection - The resulting encrypted files are named
with pseudo random generated hexadecimal strings, and stored in
their corresponding storage directory (the relation between the
original files and each encrypted part is maintained in the
internal index database). No encryption key is ever stored in an
internal database, and values in internal databases are salted
before being encrypted with one salt per register, and a second
salt per value (salts per register are not encrypted). Since
encryption keys are rather handled as passwords, internally these
keys are processed using PBKDF2 (PKCS5v2.0 with HMAC-SHA1 + a
counter greater than 1) to generate a temporary key and its
corresponding initialization vector (iv) that are the ones
actually being used by the encryption/decryption algorithms.
This KEY/IV generation mechanism is not compatible anymore with
the OpenSSL's command line tool (You will need to generate
manually the keys and iv with this method before you can decrypt
manually each file and database register with this tool).
Resource indexes are shuffled when new elements are added (for
CSV files, columns are reconstructed maintaining the order of
their registers, but the order in which columns appear changes.
Scripts should therefore access columns by name and not by their
position).
6. Resource processing - All data processing including encryption
and decryption takes place in memory (with a few exceptions, such
as file uploads that are stored in a specific directory before
being encrypted, overwritten and deleted). Internal secure
databases (data tables organized in rows and columns like CSV
files) can be processed by Perl scripts in memory, using and
embedded Perl interpreter.
7. Sessions and multi-threading - CaumeDSE uses stateless REST
connections and does not support multiple execution threads.
Also, it currently supports only one user at a time. While this
imposes some limits to operations, it also makes it easier to
detect and fix issues. Multiple instances to support several
users at any single time may be managed by a controlling
application in the future. This layered model will allow us to
improve usability without compromising security.
2. Resource hierarchy
Resources are organized hierarchically using a REST approach. Reading the
uniform resource identifier (URI) within an HTTP request from left to right
will show resources and resource types that USE or CONTAIN the resource or
resource type to the right of it within the hierarchy, until you find the
requested resource at the end (before any parameters).
The resource hierarchy is listed below:
https://{engine}
| /organizations
| | /{organization}
| | | /users
| | | | /{user}
~| | | | | /roleTables
| | | | | | /{roleTable}
~| | | | | /filterWhitelist
~| | | | | /filterBlacklist
| | | /storage
| | | | /{storage}
~| | | | | /documentTypes
| | | | | | /{documentType}
| | | | | | | /documents
| | | | | | | | /{document}
~| | | | | | | | | /parserScripts
| | | | | | | | | | /{parserScript}
| | | | | | | | | /content
~| | | | | | | | | /contentRows
| | | | | | | | | | /{contentRow}
~| | | | | | | | | /contentColumns
| | | | | | | | | | /{contentColumn}
| /favicon.ico| | | | | | |
~| /dbNames | | | | | | | |
~| | /{dbName}| | | | | | |
~| | | /dbTables| | | | | |
~| | | | /{dbTable} | | | |
~| | | | | /tableRows | | |
~| | | | | | /{tableRow} | |
~| | | | | /tableColumns | |
~| | | | | | /{tableColumn} |
| /engineCommands| | | | | |
| /transactions | | | | | |
| | | | | | | | | | | |
0 1 2 3 4 5 6 7 8 9 10 (resource/resourceType level)
~ = Not implemented (might be implemented in the future).
Resources (listed within keys, { and }), must be called by their unique
name. Resource types are not listed within keys and they must be named
exactly as they are listed.
For example, to get the resource representation of user EngineAdmin that is
registered in organization EngineOrg at the CaumeDSE instance in ip address
192.168.1.1, you would do an HTTPS GET request with an URI similar to this:
https://192.168.1.1/organizations/EngineOrg/users/EngineAdmin?userId=EngineAdmin&
orgId=EngineOrg&orgKey=0CDBB9AF76AF43BDB72E095989E612CC
Check section V for access methods, parameters and examples for each
resource/ resourceType requests and their expected results.
3. Request parameters
Common parameters to a resource request are passed either via a query string
or as a multipart/form-data encoded body (in the case of POST requests).
There are 3 types of parameters
* Authorizations & Encryption parameters
* Resource attribute parameters (to match or update)
* Optional parameters
3.1 Authorizations & Encryption parameters
These parameters are required in every request to decrypt resource indexes
roles and resources, and allows the system to verify if the request is
authorized (note that authentication takes place before any authorization
and decryption).
userId
Specifies the {user} to verify authorization (note that this same
user is authenticated previously). The user referred to by userId
must be a resource of the organization defined within orgId.
orgId
Specifies the {organization} to verify authorization and perform
resource operations. This parameter does no need to match the
organization defined in the URI. For example, a user with the right
privileges can create a new organization (defined in the URI) with a
POST request, but still authenticate and be authorized using the
userId and orgId parameters.
orgKey
Specifies the organization key that is used to decrypt resources and
internal database values. Every resource registered within the same
organization are encrypted with the same key (although with
different salt and initialization vector). This includes users, and
is the reason why authentication is a separate process.
3.2 Resource attribute parameters (to match or update)
These parameters, allow you to specify matching registers (exact matches
only), if prepended with an underscore (_) and combined with methods such as
GET, HEAD, PUT or DELETE, or to update resource values in POST and PUT
methods if prepended with an asterisk (*).
For example, a request using a PUT method to update all user resources
(resource type users) whose resourceInfo value is 'new', by setting their
certificate value to 'undefined' you would use a PUT request that would look
similar to this one:
https://192.168.1.1/organizations/EngineOrg/users?userId=EngineAdmin&
orgId=EngineOrg&orgKey=0CDBB9AF76AF43BDB72E095989E612CC&_resourceInfo=new&
*certificate=undefined
Attribute parameters could be considered resources contained by the
corresponding resource or resource type where they are being used. As such,
they may be included in the resource hierarchy in the future to provide a
consistent and alternative form to be accessed. Unfortunately, managing
every attribute as a resource also means more requests to perform a simple
function (e.g. Suppose you have a resource with 5 attributes, you can
create the resource and update all 5 attributes in a single request if you
use attribute parameters, but if you manage attributes as resources
contained by the main resource, it would take 6 requests to create the
resource and each of its attributes)
To check which attribute parameters are supported by each resource and
resource type refer to section V (REST (Resource) API reference).
userId
Resources/ResourceTypes: ANY
Prefixes: match (_) only.For POST/PUT updates the value is always
taken from the URI
When used with _ matches against the userId attribute of a resource.
This attribute contains the last user to modify (e.g. with PUT) the
resource, or the user who created the resource (with POST) if it has
not been modified.
For other uses check: 3.1 Authorizations & Encryption parameters
orgId
Resources/ResourceTypes: ANY
Prefixes: match (_) only.For POST/PUT updates the value is always
taken from the URI
When used with _ matches against the orgId attribute of a resource.
This attribute contains the orgId corresponding to the last user to
modify (e.g. with PUT) the resource or to the user who created the
resource (with POST) if it has not been modified.
For other uses check: 3.1 Authorizations & Encryption parameters
resourceInfo
Resources/ResourceTypes: organizations, {organization}, users,
{user}, storage {storage}, documents, {document}
Prefixes: match (_) and update (*).
Contains general information regarding the resource.
certificate
Resources/ResourceTypes: organizations, {organization}, users,
{user}
Prefixes: match (_) and update (*).
Stores digital certificate information related to the resource. Note
that CaumeDSE does not use this information in any way for
authentication. Organizations can store any string here (PEM
certificates, certificate issuer, certificate hash,...).
publicKey
Resources/ResourceTypes: organizations, {organization}, users, {user}
Prefixes: match (_) and update (*).
Stores public key information related to the resource. Note that
CaumeDSE does not use this information in any way for
authentication. Organizations can store any string here (PEM public
keys, public key file names, public key hash,...).
userResourceId
Resources/ResourceTypes: users
Prefixes: match (_) only. For POST ({user}), this attribute is taken
from the URI.
Stores the identifier of a {user} resource.
orgResourceId
Resources/ResourceTypes: organizations, transactions
Prefixes: match (_) only. For POST ({organization}) this attribute
is taken from the URI.
Stores the identifier of an {organization} resource. For
transactions, if the user was correctly authenticated, then this
value will be protected (indicated by the 'authenticated'
parameter).
basicAuthPwdHash
Resources/ResourceTypes: users, {user}
Prefixes: match (_) and update (*).
*FUNCTIONALITY NOT YET IMPLEMENTED*: This attribute may contain
password hashes for user authentication via the HTTP basic
authentication method in the future.
oauthConsumerKey
Resources/ResourceTypes: users, {user}
Prefixes: match (_) and update (*).
*FUNCTIONALITY NOT YET IMPLEMENTED*: This attribute may contain the
Consumer Secret for user authentication via OAUTH authentication
protocol in the future.
oauthConsumerSecret
Resources/ResourceTypes: users, {user}
Prefixes: match (_) and update (*).
*FUNCTIONALITY NOT YET IMPLEMENTED*: This attribute may contain the
Consumer Secret for user authentication via OAUTH authentication
protocol in the future.
columnFile
Resources/ResourceTypes: documents, {document}
Prefixes: match (_) only. For POST/PUT this attribute is calculated
by CaumeDSE.
Stores the name (hexadecimal string generated randomly) that
contains the encrypted content for the corresponding partId and
columnId.
documentId
Resources/ResourceTypes: documents
Prefixes: match (_) only. For POST ({document}) this attribute is
taken from the URI.
Stores the identifier of a {document} resource.
storageId
Resources/ResourceTypes: storage
Prefixes: match (_) only. For POST ({storage}) this attribute is
taken from the URI.
Stores the identifier of a {storage} resource.
partHash
Resources/ResourceTypes: documents, {document}
Prefixes: match (_) only. For POST/PUT this attribute is calculated
by CaumeDSE.
Stores the hash of the encrypted content in the corresponding
columnFile.
totalParts
Resources/ResourceTypes: documents, {document}
Prefixes: match (_) only. For POST/PUT this attribute is calculated
by CaumeDSE.
Stores the number of encrypted parts in which the original file was
divided. For CSV files, this refers to the number of parts in which
every column was divided if you want to know the number of files
that contain pieces of a CSV files, just do (number of
columns)*totalParts. The highest number in columnId is the number
of columns that a CSV resource has.
partId
Resources/ResourceTypes: documents, {document}
Prefixes: match (_) only. For POST/PUT this attribute is calculated
by CaumeDSE.
Stores the sequential id for the part for the corresponding columnId.
lastModified
Resources/ResourceTypes: documents, {document}
Prefixes: match (_) only. For POST/PUT this attribute is calculated
by CaumeDSE.
Stores the Unix time (epoch) corresponding to the last time that the
resource was updated (PUT), or to the time it was created (POST) if
it has not been updated yet.
columnId
Resources/ResourceTypes: documents, {document}
Prefixes: match (_) only. For POST/PUT this attribute is calculated
by CaumeDSE.
Stores the column id corresponding to the column File. for document
types different from CSV files (e.g. raw files), this value is
always 1 (i.e. they consist of a single column).
location
Resources/ResourceTypes: storage, {storage}
Prefixes: match (_) and update (*).
Stores information related to the location of the {storage}
resource. You can store any text string here, it is not used by
CaumeDSE.
type
Resources/ResourceTypes: storage, {storage}
Prefixes: match (_) and update (*).
*FUNCTIONALITY NOT YET IMPLEMENTED*: This attribute may specify the
type of storage to allow CaumeDSE to connect and use remote storage
in the future. Right now, only regular file storage available
through standard input and output functions is supported.
accessPath
Resources/ResourceTypes: storage, {storage}
Prefixes: match (_) and update (*).
*FUNCTIONALITY NOT YET IMPLEMENTED*: This attribute may specify an
access identifier to allow CaumeDSE to connect and use remote
storage in the future. Right now, only regular file storage
available through standard input and output functions is supported.
accessUser
Resources/ResourceTypes: storage, {storage}
Prefixes: match (_) and update (*).
*FUNCTIONALITY NOT YET IMPLEMENTED*: This attribute may specify the
user identifier to allow CaumeDSE to connect and use remote storage
in the future. Right now, only regular file storage available
through standard input and output functions is supported.
accessPassword
Resources/ResourceTypes: storage, {storage}
Prefixes: match (_) and update (*).
*FUNCTIONALITY NOT YET IMPLEMENTED*: This attribute may specify
access credentials to allow CaumeDSE to connect and use remote
storage in the future. Right now, only regular file storage
available through standard input and output functions is supported.
_get
Resources/ResourceTypes: {roleTable}
Prefixes: match (_) and update (*).
NOTE: with the match prefix you would have a 2 underscores at in the
parameter name.
This attribute specifies whether the corresponding {user} at the
specified {organization} is allowed to perform GET requests on
resources related to {roleTable}.
String "1" is for allow. string "0" is for deny.
_post
Resources/ResourceTypes: {roleTable}
Prefixes: match (_) and update (*).
NOTE: with the match prefix you would have a 2 underscores at in the
parameter name.
This attribute specifies whether the corresponding {user} at the
specified {organization} is allowed to perform POST requests on
resources related to {roleTable}.
String "1" is for allow. string "0" is for deny.
_put
Resources/ResourceTypes: {roleTable}
Prefixes: match (_) and update (*).
NOTE: with the match prefix you would have a 2 underscores at in the
parameter name.
This attribute specifies whether the corresponding {user} at the
specified {organization} is allowed to perform PUT requests on
resources related to {roleTable}.
String "1" is for allow. string "0" is for deny.
_delete
Resources/ResourceTypes: {roleTable}
Prefixes: match (_) and update (*).
NOTE: with the match prefix you would have a 2 underscores at in the
parameter name.
This attribute specifies whether the corresponding {user} at the
specified {organization} is allowed to perform DELETE requests on
resources related to {roleTable}.
String "1" is for allow. string "0" is for deny.
_head
Resources/ResourceTypes: {roleTable}
Prefixes: match (_) and update (*).
NOTE: with the match prefix you would have a 2 underscores at in the
parameter name.
This attribute specifies whether the corresponding {user} at the
specified {organization} is allowed to perform HEAD requests on
resources related to {roleTable}.
String "1" is for allow. string "0" is for deny.
_options
Resources/ResourceTypes: {roleTable}
Prefixes: match (_) and update (*).
NOTE: with the match prefix you would have a 2 underscores at in the
parameter name.
This attribute specifies whether the corresponding {user} at the
specified {organization} is allowed to perform OPTIONS requests on
resources related to {roleTable}.
String "1" is for allow. string "0" is for deny.
requestMethod
Resources/ResourceTypes: transactions
Prefixes: match (_) only. For POST this attribute will be defined
automatically by CaumeDSE
This attribute specifies the HTTP method used by the user request.
If the user was correctly authenticated, then this value will be
protected (indicated by the 'authenticated' parameter).
requestUrl
Resources/ResourceTypes: transactions
Prefixes: match (_) only. For POST this attribute will be defined
automatically by CaumeDSE
This attribute specifies the URL used as part of the user request.
If the user was correctly authenticated, then this value will be
protected (indicated by the 'authenticated' parameter).
requestHeaders
Resources/ResourceTypes: transactions
Prefixes: match (_) only. For POST this attribute will be defined
automatically by CaumeDSE
This attribute specifies the HTTP Headers used as part of the user
request. If the user was correctly authenticated, then this value
will be protected (indicated by the 'authenticated' parameter).
startTimestamp
Resources/ResourceTypes: transactions
Prefixes: match (_) only. For POST this attribute will be defined
automatically by CaumeDSE
This attribute specifies the timestamp of the moment at which the
user request was received. If the user was correctly authenticated,
then this value will be protected (indicated by the 'authenticated'
parameter).
endTimestamp
Resources/ResourceTypes: transactions
Prefixes: match (_) only. For POST this attribute will be defined
automatically by CaumeDSE
This attribute specifies the timestamp of the moment at which the
user request was answered. If the user was correctly authenticated,
then this value will be protected (indicated by the 'authenticated'
parameter).
requestDataSize
Resources/ResourceTypes: transactions
Prefixes: match (_) only. For POST this attribute will be defined
automatically by CaumeDSE
This attribute specifies the size of the body of the HTTP user's
request. If the user was correctly authenticated, then this value
will be protected (indicated by the 'authenticated' parameter).
responseDataSize
Resources/ResourceTypes: transactions
Prefixes: match (_) only. For POST this attribute will be defined
automatically by CaumeDSE
This attribute specifies the size of the body of the HTTP engine's
answer. If the user was correctly authenticated, then this value
will be protected (indicated by the 'authenticated' parameter).
requestIPAddress
Resources/ResourceTypes: transactions
Prefixes: match (_) only. For POST this attribute will be defined
automatically by CaumeDSE
This attribute specifies the IP address (v4 or v6) of the user
sending the request. If the user was correctly authenticated, then
this value will be protected (indicated by the 'authenticated'
parameter).
responseCode
Resources/ResourceTypes: transactions
Prefixes: match (_) only. For POST this attribute will be defined
automatically by CaumeDSE
This attribute specifies the response code of the HTTP engine's
answer. If the user was correctly authenticated, then this value
will be protected (indicated by the 'authenticated' parameter).
responseHeaders
Resources/ResourceTypes: transactions
Prefixes: match (_) only. For POST this attribute will be defined
automatically by CaumeDSE
This attribute specifies the response headers of the HTTP engine's
answer. If the user was correctly authenticated, then this value
will be protected (indicated by the 'authenticated' parameter).
authenticated
Resources/ResourceTypes: transactions
Prefixes: match (_) only. For POST this attribute will be defined
automatically by CaumeDSE
This attribute specifies whether the user was authenticated ('1') or
not ('0'). If the user was correctly authenticated, then values
depending on the authenticated attribute will be encrypted;
otherwise they will be copied in cleartext. This attribute is never
encrypted.
Note that there is a situation when an authenticated user uses an
incorrect orgKey. In this case, transaction logs won't be readable
since they will be protected using the erroneous key. Transactions
will be protected as whenever the user is authenticated, even if
he/she does not have the right priviledges to execute the request.
setEnginePower
Resources/ResourceTypes: engineCommands
Prefixes: match (_) only. This parameter activates (value = on,
default) or deactivates (value = off) engine requests with the PUT
method.
3.3 Optional parameters
salt
Specifies the salt to be used with all values of an internal
database register or a data resource for encryption/decryption. if
not included, it will be generated by a pseudo random algorithm by
CaumeDSE. If included it must be an hexadecimal string 16
characters long (i.e. representing 8 bytes).
(Note that for values within the same register another salt is
generated and prepended to values before being encrypted (internally
this is called valueSalt), and removed after decryption, this second
salt is necessary to avoid same ciphertext for identical database
values within the same internal database register.)
newOrgKey
In POST requests only (i.e 'create'), this parameter specifies the
organization key (orgKey) to be used for creating the new resource,
which is different from the orgKey used to protect the the userId's
roles of the requesting user (of course, the user must have POST
permission within its organization that can be decrypted with
orgKey).
This allows for example, an administrator to create a different
organization or resources within a different organization. After
being created though, this administrator would need a user with the
right credentials to be authenticated and the corresponding
permissions within the role table for this new organization in order
to access the newly created resources.
If omitted, orgKey will be used to protect any new resource.
outputType
Specifies the type of output for the result. Available values are
csv and HTML (the later is the default). this is particularly
useful for results that return data tables, such as resource
specification queries or requests for the contents of csv type
files.
3.4 Document POST parameters
These parameters are required in every POST request of {document} resources.
file
Specifies the file name and contents (which does not necessarily
will be the same as the documentId of the resource in the URI) of
the file to be uploaded, to create a {document} resource. POST
requests will contain the attribute parameters and the file contents
encoded in multipart/form-data format within the body.
3.5 Optional Column index parameters for content rows (file.csv)
[column_name]
Specifies the value for the specified 'column_name'. The column name
must match an existing column name within a document resource of
type file.csv.
V. REST (Resource) API reference
--------------------------------
Note that with the POST method you must define values for every updateable
parameter, to ensure that every attribute is initialized by the user. With
the PUT method you can update just the values that need changes.
While most examples of POST requests include data in the URI, be aware that
the standard way is to encode both parameters (and any file) using
multipart/form-data format. Any POST request can be encoded in this way
(CaumeDSE supports both encoding formats: URI appended parameters and
multipart/form-data parameters). However, you must use multipart/form-data
encoding if you are uploading a file (See {document} resource examples
below).
engineCommands
Supported HTTP methods: GET PUT OPTIONS
Supported ATTRIBUTE PARAMETERS:
MATCH:
<NONE>
UPDATE:
*setEnginePower
RESPONSE HEADERS:
Engine-results: <engine active status>
RESPONSE BODY:
<Attribute table for matching resources>
Example 1) Deactivate engine
METHOD:
PUT
URI:
https://localhost/engineCommands?userId=EngineAdmin&
orgId=EngineOrg&orgKey=
0CDBB9AF76AF43BDB72E095989E612CC&setEnginePower=off
REQUEST HEADERS:
<NONE>
REQUEST BODY:
<EMPTY>
organizations
Supported HTTP methods: GET PUT HEAD DELETE OPTIONS
Supported ATTRIBUTE PARAMETERS:
MATCH:
_userId _orgId _resourceInfo _certificate _publicKey
_orgResourceId
UPDATE:
*resourceInfo *certificate *publicKey
RESPONSE HEADERS:
Engine-results: <number of matching registers>
RESPONSE BODY:
<Attribute table for matching resources>
Example 1) List all organizations with publicKey = 'undefined'
in a CSV style list
METHOD:
GET
URI:
https://localhost/organizations?userId=EngineAdmin&
orgId=EngineOrg&orgKey=0CDBB9AF76AF43BDB72E095989E612CC
&_publicKey=undefined&outputType=csv
REQUEST HEADERS:
<NONE>
REQUEST BODY:
<EMPTY>
{organization}
Supported HTTP methods: GET POST PUT HEAD DELETE OPTIONS
Supported ATTRIBUTE PARAMETERS:
MATCH:
_userId _orgId _resourceInfo _certificate _publicKey
UPDATE:
*resourceInfo *certificate *publicKey
RESPONSE HEADERS:
Engine-results: <number of matching registers>
RESPONSE BODY:
<Attribute table for matching resource>
Example 1) Create a new organization called BusinessOrg, using
a new organization key: 3132333440414243, with
account EngineAdmin from EngineOrg (EngineAdmin is
assumed to have POST privileges for organizations)
METHOD:
POST
URI:
https://192.168.0.1/organizations/BusinessOrg?userId=
EngineAdmin&orgId=EngineOrg&orgKey=
0CDBB9AF76AF43BDB72E095989E612CC&*resourceInfo=
new%20organization&*certificate=undefined&*publicKey=
undefined&newOrgKey=3132333440414243
REQUEST HEADERS:
<NONE>
REQUEST BODY:
<EMPTY>
Example 2) List attributes for organization EngineOrg
METHOD:
GET
URI:
https://localhost/organizations/EngineOrg?userId=
EngineAdmin&orgId=EngineOrg&orgKey=
0CDBB9AF76AF43BDB72E095989E612CC
REQUEST HEADERS:
<NONE>
REQUEST BODY:
<EMPTY>
Example 3) Set attribute publicKey to 'serial:10F46D308B39' for
organization EngineOrg
METHOD:
PUT
URI:
https://localhost/organizations/EngineOrg?userId=
EngineAdmin&orgId=EngineOrg&orgKey=
0CDBB9AF76AF43BDB72E095989E612CC&*publicKey=
serial%3A10F46D308B39
REQUEST HEADERS:
<NONE>
REQUEST BODY:
<EMPTY>
users
Supported HTTP methods: GET PUT HEAD DELETE OPTIONS
Supported ATTRIBUTE PARAMETERS:
MATCH:
_userId _orgId _resourceInfo _certificate _publicKey
_userResourceId _basicAuthPwdHash _oauthConsumerKey
_oauthConsumerSecret
UPDATE:
*resourceInfo *certificate *publicKey
*basicAuthPwdHash *oauthConsumerKey
*oauthConsumerSecret
RESPONSE HEADERS:
Engine-results: <number of matching registers>
RESPONSE BODY:
<Attribute table for matching resources>
Example 1) List attributes of all users of organization
EngineOrg
METHOD:
GET
URI:
https://localhost/organizations/EngineOrg/users?userId=
EngineAdmin&orgId=EngineOrg&orgKey=