Overview

Most applications need a way to control which users can write or read certain data. For example, you might build an application where senior staff members can READ and WRITE documents in the "menuItems" collection while junior staff members can only READ. Ditto's security is controlled by identities. Each Ditto instance must identify itself to other peers in order to syncronize with them.

Get started

These sections will describe how you can:

1. Identify users
2. Give users read or write control
3. Integrate with your existing authentication systems

There are several types of identities. Every installation of an app that uses Ditto has its own identity. This identity is used to identify each unique peer in the mesh network. Each Ditto Identity is associated to a single Ditto client via a globally unique AppId and may not be used across multiple Ditto apps. Each identity has an appID, an authentication certificate, and a set of access control permissions which you specify. This information is used to accept or reject syncronization with peers.

Playground

When you start prototyping with Ditto you can use a "playground" identity. The playground identitiy offers no real security. Playground certificates should absolutely not be deployed to any production environments.

• Online Playground - for prototyping with Ditto for hybrid offline/online synchornization. Start here!

Production identities

Once you are ready to deploy, this can be swapped for a production identity where security is enforced.

• Online With Authentication - for hybrid offline/online synchronization with customized permissioning.
• Shared Key - an intermediate level of security for offline-only applications where all devices are trusted.

Parts of a Ditto Identity

For more detailed information on what is contained within Ditto Identity certificates, see Certificate Security.

Ditto Identity Lifecycle

While highly configurable, each Ditto Identity has a typical life cycle. First, the Ditto Identity is constructed. Typically the only prerequisites are a Ditto persistence root (working directory for local data storage, where configured) and a globally unique Ditto AppId. In order to sync, all app instances, regardless of SDK language, must have the same globally unique Ditto AppId. Therefore this value will typically be incorporated in the App's bundle or provided to the App when it starts. The Ditto Big Peer can create AppIds for you, but it is not the authentication provider. Ditto Cloud is a proxy to your own "source of truth" for identities, credential validation, and permissions.

Next the Ditto Identity is consumed by the Ditto constructor, yielding a configured Ditto instance. The Ditto instance will contain a Ditto Authenticator and your own implementation of the DittoAuthEventHandler interface, which can provide login credentials. Ditto will then contact the configured Auth Url and supply the login credentials to an Authentication Provider. If the credentials are valid, then the Authentication Provider will return to Ditto an Authentication Token, validating its credentials and granting the Ditto instance individualized permissions. The Ditto instance can now sync with other peers.