End-User Access

many apps require access controls to manage end user authorization for reading and writing specific data for instance, junior staff members are limited to read only access, while senior staff members have permission to both read and write documents you can issue each certificate manually or with the onlinewithauthentication digital identity rejecting a user to reject a user from reading or writing at all, specify the json payload { "authenticate" false } accepting a user to grant full read and write permissions to all collections and all documents { "authenticate" true, "expirationseconds" 28800, "userid" "123abc", "permissions" { "read" { "everything" true, "queriesbycollection" {} }, "write" { "everything" true, "queriesbycollection" {} } } } authenticate to true to tell the webhook that the user has successfully validated expirationseconds is number property on how long the authentication session is valid for before a refresh is required userid is a string which identifies the the userid this should be unique across users within your app permissions which describes all the types of access control for collections and documents that this user can read or write using the id field currently, you can only specify a permission query on the field of a document permissions on mutable properties are currently not supported to grant selective permissions on specific documents, add to the queriesbycollection property inside either the read or write property each key inside queriesbycollection is a reference to the collection each value is an array of ditto queries describing which documents the user can read or write permissions must be written using the legacy query syntax and not dql for more see docid\ jldhfbwkbbekpzlpkq7os example the following write permissions describe that userid "123abc" can write to documents in the "books" collection where the id locationid == 'abcedef123456' write to any document in the "newspapers" collection we use a single value of true read to documents in the "books" collection where the id locationid == 'abcedef123456' { "authenticate" true, "expirationseconds" 28800, "userid" "123abc", "permissions" { "write" { "everything" false, // ensure that this is false "queriesbycollection" { // highlight start // 1 "books" \[ id locationid == 'abcedef123456' ], // highlight end // highlight start // 2 "newspapers" \[ "true" ] // highlight end } }, "read" { "everything" false, // ensure that this is false "queriesbycollection" { // highlight start // 3 "books" \[ id locationid == 'abcedef123456' ], // highlight end } } } } threat modeling in p2p networks threat modeling is a process used by software engineers to identify, analyze, and prioritize threats that could potentially impact an application it helps engineers identify potential weak points in an application and take steps to mitigate those risks threat modeling involves identifying the assets that an application needs to protect, assessing the potential threats to those assets, and determining the best ways to protect them by identifying potential risks, engineers can ensure that the application is secure from malicious actors and that users' data is protected threat modeling can also help ensure that the application meets the company's security standards and regulations threat modeling in peer to peer (p2p) networks is different than that in client server networks due to the distributed nature of the p2p network in a client server network, there is a single server that all clients connect to, and thus all of the data and resources are centralized this makes it easier to identify potential threats and vulnerabilities, but creates a entry that can be targeted by an attacker, making it easier to exploit the entire network at once peer to peer (p2p) networks are networks that do not have a central server, but rather all nodes are equal, allowing clients to share resources with each other directly as such, p2p networks have more restrictive permissions on synchronization than client server authentication systems, as nodes are required to agree to any changes made by other peers this is done to ensure that no node has an advantage over another and that all nodes remain secure therefore, even though peers in ditto may have overlapping subscriptions, ditto peers are only able to synchronize data directly from a peer that has the authority to write that document in other words, small peers are only able to trust writes from other peers that have the authority to make those writes they cannot trust each other as a source of data that they aren't authorized to write to, since they can't tell the difference between an edit they made on their own and one which came from a further hop read only security model because ditto peers are only able to synchronize data directly from a peer that has the authority to write that document, a read only security model comes with some caveats this section covers how to best implement this security model and the trade offs that exist in peer to peer networks ditto provides a mechanism to specify which small peers can read documents in a collection without permission to write this can be useful in situations where you have restrictive user roles, such as customer and employee to implement read only documents, you should create restrictive write permissions that include the userid inside of the document id ditto ensures that only those authorized to create documents with a particular document id are able to synchronize those documents in a trustworthy manner throughout the system { "authenticate" true, "expirationseconds" 28800, "userid" "a", "permissions" { "read" { "everything" true, "queriesbycollection" {} }, "write" { "everything" false, "queriesbycollection" { "messages" \[" id userid == 'a'"] } } } } read only example in this example, peers can read chat messages from other people, but cannot write to them they can only write their own chat messages imagine three peers, peer a, b, and c peers a and b are connected, but peer c only connected to peer b graph lr; a\[a] > c\[fa\ fa mobile b]; c > d\[fa\ fa mobile c]; every peer has similar permissions, where they can read everything but can only write to a collection with an id that represents their userid so, for example, peer a has the following permissions { "authenticate" true, "expirationseconds" 28800, "userid" "a", "permissions" { "read" { "everything" true, "queriesbycollection" {} }, "write" { "everything" false, "queriesbycollection" { "messages" \[" id userid == 'a'"] } } } } peer a writes a message and syncs that message to b { " id" { "messageid" "00372532806762369024", "userid" "a" }, "text" "hello world!" } graph lr; a\[a] > |sync| c\[fa\ fa mobile b]; however, peer b cannot forward that message from a to c this is because peer b does not have write permissions to create documents with userid=a graph lr; a\[a] >|sync| b((fa\ fa cloud big peer)); b("b") does not sync b does not have write permissions for userid=a > c\[fa\ fa mobile c]; today ditto enforces that data which has to propagate peer to peer must have mutual write permissions if integrity is at risk, you have to sign the payloads yourself at the application level this is a credible attack vector, especially if peer a represents an authority in the system, such as an administrative user this design prevents a hacker from impersonating peer a, because other peers will only synchronize documents from peer a when they have a direct connection to peer a, and can verify their certificate is valid threat a hacker attempts to write messages pretending to be peer a even though they are only allowed to read steal mobile phone that is authorized as peer b create documents pretending to be peer a this is a credible attack vector, especially if peer a represents an authority in the system, such as an administrative user this design prevents a hacker from impersonating peer a, because other peers will only synchronize documents from peer a when they have a direct connection to peer a, and can verify their certificate is valid app level security the access rules contained in the identity are rigid, signed by the central certificate authority, and enforced by all participating devices this offers the highest level of security if a device is not allowed to access particular data, it will never be synced to their device for apps with weaker security requirements, a developer may choose to relax the access rules inside the ditto certificate, and instead restrict access in their application code one advantage is that the developer has more flexibility to change the access rules dynamically since they are not encoded in signed certificates another advantage is that all devices in the mesh can participate in syncing the data, which may help it propagate faster if certain data is only accessible to a few privileged devices which are not often in range of each other, it will take longer for them to sync the disadvantage is that an unprivileged user does have a device containing privileged data a technically savvy user or phone thief may be able to gain access to not only their regular data, but also the more privileged data that they were never intended to be able to view therefore relaxed access rules app level security are only suitable for environments where there is a degree of trust that the devices won't end up unlocked in the wrong hands