iotaledger / integration-services Goto Github PK

Folder:
clients/frama-c-client

There shall be two clients each in a sub folder of frama-c-client
1. Client: Log Creator

Subfolder:
log-creator

1. Client adds the attached file as local file into log-creator folder. Give the file some unique identitifier. Like date + time and short name.

There shall be one script which executes the following behavior

2. The client creates an identity for himself with a claim representing information about him

{
  "username": "frama-c-log-creator",
  "claim": {
        "type":"Service",
        "name":"Frama C Log Creator",
        "category": "embedded-tool",
        "description":"Creates embedded logs"
   }
}

3. The client creates a stream channel with the body:

{
    "topics": [{"type":"hashed-audit-log-file","source":"frama-c-client"}],
    "encrypted":false
}

_This request and some others require authentication. There is a sample how to integrate an axios interceptor into the request, so the authentication is automatically done if a 401 status is received. Also integrate this interceptor into the requests. Like: _
axios.interceptors.response.use((response) => response, errFunc(issuer));
See: /clients/summer-school-client/create-credentials for more details

Then the second client needs to subscribe to this channel. After the client has subscribed it can do the following.

4. Authorize client using its identity or subscriber link

5. Hash file write the hash and unique id of the file into the channel.

2. Client: Log Auditor

Subfolder:
log-auditor

1. Client adds the attached file as local file into log-creator folder. Give the file some unique identitifier. Like date + time and short name. (Same as defined above)

2. The log-auditor also creates an identity with a claim representing information about him

{
  "username": "frama-c-log-auditor",
  "claim": {
        "type":"Service",
        "name":"Frama C Log Auditor",
        "category": "embedded-tool",
        "description":"Audits embedded logs"
   }
}

3. Subscribe to channel of tool 1

Now the first client needs to authorize the 2nd client and write data to the log afterwards. After this is done the audit client can fetch the data from the channel.

4. Fetch data from channel

5. Locally hash file and compare fetched hash from the channel with the local hash.

6. If they are the same log some message

Channel service which is used to create a channel in streams and write/read to/from it.

Several clients which interact with the e-commerce tools

Having a user service, clients can search for users and also crud its user information.

A user has a role which identifies privileges he is able to do.

For simplification this role can be: 'admin' or 'user'!

Admins can for instance users of other companies or update/delete other users which are not themself.

Role can be extracted from jwt of the bearer token!

Create admin user on startup like the api server via admin.ts tool!

adjust authorization mechamism to consider admin privileges!
tests for the admin authorization mechanism

• Write data to a public channel

data:

• eventType
• dataType: public | restricted
• payload
• metadata

• send signed package or send tagged package
  => signed as flag?
• differentiate public or private
• automatically add date

evtl.

• possibility to hash data using param

Prerequesite:

• Author needs to have defined a preshared key otherwise no auditors are able to get access to it

There are two scenarios a auditor shall subscribe to a channel

1. auditor already knows preshared key
2. auditor uses subscribe and author gives him access to this preshared key
   ==> 2nd option needs to be done in a separate ticket and is an optional requirement

Both times subscribe shall be used but in the first case they auditor is directly allowed to read from the channel since he knows about the key to access the data

FR-085 Data Integrity Verification (Must Have) DLT-003

• Use chunk of data array with links + data inside to validate
• fetch the links from the tangle/channel and compare them at api side

Create/Use standardized credentials.

Look into standards for verifiable credential attributes for the following categories:

• Devices

• Organisations

• Users/Employees

• set credential type according to classification

• revoke and remove the subscription to a channel

Won't be done:
possibility to remove all subscriptions of the user when it gets deleted

Otherwise the identity service would be dependent of the audit trail but we don't want this dependency. Should be done by client backend...

Deployment, Pipelines, CI/CD

Service to authorize/unauthorize and request subscriptions of a IOTA streams channel.

• install streams dependency
• Create a public channel in streams using an endpoint.
• type for channel public|restricted

Service to manage channels.

• Read stored channel data from db
• Fetch further data from stream

A api can connect to a parent api where it can also store and request channel information from. So an api is able to exchange channel information with other apis.