Lesson 4: Identity and Access Management

Captions as YouTube publishes them, usually machine-generated, so names such as Daml and Canton can be misheard.

1. 0:04

   the Canton Network manages the identities of its users parties and system entities with its identity management systems in this lesson we will learn what these systems are and how they work we will start with learning about user and party identities and then discuss how system entities in a Canon Network use public key cryptography to identify and validate each other let us start with users and parties daml applications are

2. 0:34

   multi-party applications that operate across organizational boundaries and store their data in a shared Ledger however each party controls the access to their view of the shared Ledger using its own independent identity and access management system that is IM am as shown in this diagram there are two organizations bank which is the app provider for an app called Bank app and Company a which is the app user they each have their own independent IMS

3. 1:07

   controlling access to their participant nodes and private contract stores to understand how the parties users and system entities such as participant nodes are uniquely identified and authenticated in such a setup let us first zoom into the user level to understand how external users can access the Ledger let us take a scenario in which the participant node has two parties P1 and P2 defined in its private contract store the user Management

4. 1:40

   Service running on the same node defines two users U1 and U2 the user Management Service helps create and manage users on a participant note and Associate them with a set of act as and read as permissions it also serves as the integration point for the organization's I am system as shown here U1 is mapped to both P1 and P2 and is authorized with can act as permissions U2 can read as P2

5. 2:12

   now employee one in this organization uses an application front end to access The Ledger this frontend is an external entity from the participant node and therefore needs to be mapped to a user defined on the participant node let's now look at how employee 1's browser gets authentication credentials for U1 based on which employee 1 will be able to act as party P1 and P2 first the employee needs to be authenticated by the organization's I am system which is

6. 2:45

   integrated with the participant node used by the application the employee enters their credentials in a website served by the IM am where they log in the IM am gets the credentials along with a request for user access to token for user uan user access tokens are Json web tokens or jots that follow oaf standards the Imam validates the credentials and Returns the U1 token this token is then taken by the

7. 3:16

   application and sent along with the API request to access the ledger to the participant node at this point the participant node needs to once again check if this is a valid token so it asks the am for the token issuer key and uses the key sent by I am to validate the U1 token once validated it then checks if the user uan has the permission for the API request it submitted once authorized the API request is then executed as needed and

8. 3:50

   API request response is sent back to the user U1 which is the web UI let us now trace this flow once more for another end user say employee 2 employee 2 uses a different web UI which is mapped to user U2 on the participant node through this application the employee submits their credentials along with the U2 user access token request to the am the I am authenticates the credentials and Returns the U2 token the application

9. 4:24

   then submits the API request to access The Ledger with the You2 access token to the participant node which now has the im's key from the previous request in its cache so the participant node validates the token checks you's authorization and then sends the API request response as needed this entire flow demonstrates how participant nodes integrate with an organization's I am system and allow end users to access The Ledger through front-end applications

10. 4:58

    that are mapped to participant user users on the Node which in turn are mapped to parties with read as and act as authorizations this example shows the authentication of end users backends are authenticated analogously by having them use a service user registered in the IM am which is mapped to a corresponding participant user what we have seen so far is how external users can access the Ledger through daml applications daml applications space participant nodes

11. 5:31

    that is the provider node plus all nodes where the app is installed and they use participant nodes to synchronize the state of the app's multi-party workflows the participant nodes are part a larger Canton Network that has multiple components called as system entities let us now look at how these system entities are identified the system entities in the Canton Network's sync domain are participant nodes one or or more sequencers and mediators a sync domain

12. 6:03

    is used by participant nodes to communicate with other participant nodes this communication is done by sending messages through the sync domain and these messages need to be encrypted and transmitted safely for this purpose these entities use public key cryptography with a pair of public and private keys they use the recipient public keys to encrypt messages and their own private keys to sign message contents and decrypt the content these

13. 6:34

    entities must also validate each other's identity to make sure that they are communicating with the right entity this means that they need to verify that a certain Association of an entity with a key is valid this mapping of system entities to their keys is distributed knowledge that is kept consistent at all times by the sync domain to which the entities belong each of these system entities has a globally unique ID that has two components separated by a double

14. 7:06

    colon first a human readable string X this can be a random string assigned by the system or by the user this string may not be unique in a sync domain and is referred to as a nickname and second a fingerprint of a public key n that is guaranteed to be unique globally these fingerprints come from a namespace and namespace is a mechanism to bootstrap identity and can be thought of as a bucket of unique identities which itself has a secret key as the root of trust

15. 7:40

    this namespace is used to assign unique IDs to system entities as well as to parties let us now see a demo of how these IDs work in an actual Canton Network this demo has Canton downloaded from the link shown here and then extracted in a folder you can run the command from the rout to start the Canton executable that is located in the bin folder notice that this command is passing on a config file called simpl topology docon that comes bundled in the

16. 8:12

    01 simple topology folder inside the examples folder this file specifies that we need two participant nodes with the names participant one and participant 2 and one domain named my domain the term domain here refers to the sync domain that has sequencers and mediators as it components once this config file has been executed we will have three elements on this Canton Network each has a unique ID derived from its own

17. 8:44

    namespace and therefore each will have its own unique fingerprint for example the fingerprint F1 of participant 1 comes from its namespace one the fingerprint F2 of participant 2 comes from its own namespace 2 2 and F3 from mespace 3 we can see these fingerprints by entering at health. status at the prompt as you can see the three unique IDs each have their own name Spaces by default each Canton node generates a fresh asymmetric key pair for its Nam space when it first

18. 9:19

    starts finally let us add two parties one for each node when you execute the commands as shown the party IDs are displayed but as the identifier strings are too long they are truncated when displayed for convenience you can get the full string by using the two Proto primitive function on the party names now if you compare the party IDs with the participant node IDs that are shown here for reference you will see that the Nam

19. 9:51

    space of the unique IDs assigned to each of the parties is the same as the participant nodes where the party is hosted and and hence they have the same fingerprint in their unique IDs this example shows how each node has its own name space which is then used by all the parties on that node let us now summarize Canton offers identity management systems for its system entities as well as parties and users the parties are on lger identities recognized by The Ledger across

20. 10:24

    participant nodes whereas users also called as participant user ERS that are external applications or entities are local to the participant nodes where they are defined these participant users can access the Ledger using a token issued by the organization's I am system and recognized by The Ledger API exposed by the participant node for Canton system entities unique IDs are created from within a nam space for safe communication and validation of entities

21. 10:57

    on the network the these IDs are created at sync domain level for participant nodes sequencers and mediators and at the participant node level for parties hosted on it