{"id":"p7UNTkZsS7g","title":"Lesson 3: Authentication and IAM","description":"The learner will recall that maximizing the business value of a Daml Application intrinsically results in a multi-organization application. This means an application crossing multiple trust boundaries, and with users managed within multiple governance domains. The learner will be introduced to several implications for authorization and identity management that result from this when designing the application architecture.\n\nFor a better learning experience, sign up and enroll in this free course at: https://daml.talentlms.com/plus/catalog/courses/162","channel_name":"Digital Asset Training","published_at":"2025-02-18T00:00:00.000Z","thumbnail_url":"https://i.ytimg.com/vi/p7UNTkZsS7g/hqdefault.jpg","transcript_text":"welcome to authentication and IM am daml applications cross organizational trust boundaries so authentication is a crosscutting concern that requires attention in your solution architecture in this lesson you will learn how to select a suitable party topology to manage authentication both of end users and backend services including the specific considerations required when providing backend services to external entities across trust boundaries we have seen in previous courses how daml applications are built around shared consensus and that daml allows consensus to be achieved over trust boundaries it is The daml Ledger managed across participant nodes sharing a synchronizer that provides this consensus D parties provide first class Global identities that act on and share in The Ledger consensus in Dam applications they are used to represent the organizations interacting with each other in a synchronized manner Over The Ledger obtaining the ability to act as a party is to obtain the ability to act as the organization obtaining the ability to read as a party is to obtain the ability to observe every contract or Ledger event visible to the organization or organizational entity that party represents as a result your damel party to ology deciding the granularity of what organizational entity a party represents within your application is a critical design concern it is critical that each organization appropriately controls the access to the parties that represent the organization this is typically achieved using authentication credentials issued by an IM am system under their control without that control an organization would lose control over the workflows run on on Ledger with their counterparties and whoever had access to act on The Ledger using an organization's parties could advance that organization's workflows for their own benefit which is why the daml application architecture is the way it is the benefits provided by daml and Canton that we discussed in the earlier courses rely on this Providence chain of trust The Ledger authorization and its association with organization damel parties the credentialing of participant users access damel parties hosted on participant nodes and in operation the management of access to participant users through an authentication process with an am under the organization's control delegating authentication across a trust boundary should be avoided as it weakens the authorization delegation privacy and non-repudiation guarantees provided by Canton and the DL Ledger the rest of this lesson will go into more detail about how to design your DL party topology and how to manage the authentication of users and services within a DL application those details matter but the most important architectural takeaway is in order for daml to provide non-repudiation each organization should control their own participant node and the IM am that controls access to it in previous lessons we have seen how dl's privacy and authorization model is defined in terms of parties parties are the sole representation of Identity On The Ledger and therefore signatories controllers observers Witnesses and informes are all defined as sets of DML parties consequently daml parties are used to govern Access Control to ler data and therefore encode identity across interorganizational boundaries for this reason which entities will be represented as danal parties in your application is a very important architectural decision there is no single answer to this question your decision is going to depend both on your business case and the way you implement the business workflows using daml a good starting point is to use one party for the app provider and exactly one for for each of the app users it is not uncommon for this to correspond to one party per legal entity and consequently one party per trust boundary as a good default each of these parties is allocated on the respective organizations participant node and represents that organization in on Ledger workflows note that more advanced party topologies like hosting parties on multiple participant nodes or controlling parties independently of the participant node are possible the Canton user manual has details and digital asset can advise if or how these more advanced apologies apply to your specific circumstances however one party per organization hosted on their own participant node is a good default for most applications this will align party topology with the desired granularity of on Ledger visibility and authorization where the relationship of app user to organization to Legal entity are not one to one you may need to consider if counterparties care about which legal entity acted in a particular workflow or which of other options best represents the level of access control desired keep in mind that within a single trust boundary you will usually have other options to manage access and authorization so while more fine grained party topologies are possible they often leak entities internal detail details onto The Ledger and to counterparties note that data for all parties on the same participant node is physically Consolidated interpart privacy is restricted to what is returned by The Ledger API and in The Ledger consensus between participant nodes we instead recommend implementing internal Access Control policies via backend Services as explained in previous lessons a single party per trust boundary is generally preferred where you do decide to use multiple parties for a single organization try to align parties with stable business roles as parties form the foundation of a ledger consensus restructuring your party topology can be delicate and disruptive judicious addition of parties can help resolve business requirements however the point where party topology reflects internal hierarchies is an anti- pattern as the party is the level at which lure consensus and disclosure is defined so make careful note of the witnesses of subtransaction to ensure you do not inadvertently divulge internal details finally keep in mind that adding unnecessary parties can lead to hitting scalability limits which we will discuss further in a future Course once you have decided on your party topology it becomes necessary to consider how you will manage manage authenticating access to the parties by end users and backend services on the relevant participant node in the case of backend Services access to their respective participant node the recommended approach is for the backends administrator to allocate a service account for the backend in their organizations's IM am then for them to create a participant user with the same name in the participant node identify the part being mediated by the backend in the participant node note that while the example here shows two parties being used to represent the bank this will often be only a single party and allocate to the participant user read as and act as rights for each of the mediated parties finally configure the backend to use the service accounts user ID ooth client ID and ooth secret and use those credentials when acquiring the job token required to access The Ledger API a few points to keep in mind the daml platform is designed to allow the use of standard tooling and ooth Technologies all the usual best practices that apply to allocating and managing service accounts apply the relationship between participant users and Ledger parties is not one to one you can have multiple Ledger parties associated with a single participant user multiple users can be granted access to the same Ledger party each Grant of a ledger party to a participant user can provide independent read as and access capabilities for that user to that party we recommend that front-ends submit all their commands via a backend service and have the backend authenticate them as explained later however if a front end does submit commands directly to the Ledger API on a participant node you will also need to allow front-end users to authenticate to the participant node generally this will require creating participant users for every end user in your IM am with access to the front end as with the backend service participant user these front-end participant users will need to be granted read as and act as rights for The Ledger parties accessed via the front end where the front end is talking directly to The Ledger API front-end users are directly associated with participant users consequently this form of DL application architecture is only suitable where it is appropriate for end users to be granted full authority to view and act as a specific Party On The Ledger and where the party must provide the desired granularity of authorization and privacy common examples of this include applications where every end user is an entity within your party topology and therefore acts using a party of their own applications where end users are trusted by and acting in the name of the organization represented by the party such as administrative operational and support front ends accessible only by trusted administrators and operations Personnel given the larger number of participant users involved in direct front-end access you will need to consider how you will create and configure them while they can be set up manually using the Canton console you may need to consider scripting the process use the primary party field to associate an end user's party to its participant user if a user has act as rights for multiple parties store the mapping between the parties and their respective purposes in the user metadata use the user endpoint on The Ledger API to retrieve the primary party and user metadata of the authenticated user from the front end often it is technically simpler for Ledger access to be mediated by a back-end API when providing mediating backend services within the same authentication domain use best practices and your organization's existing advice and facilities for authenticating the requests to your backend most applications should ensure all read and write access is mediated via backend as this allows the backend to implement fine grained Access Control at the service level it then becomes the backend Services responsibility to authenticate the mediated end users and apply the required Access Control policies for the end user things are slightly more complicated when a backend needs to provide services to requests from outside the authentication domain otherwise one option is to create service accounts within the app providers IM am for external backends a common use case for this approach is to provide readon access to query reference data when this option is available keep in mind that the concept of interorganizational Identity On The Ledger Remains The Ledger party so while the identity of the app user can be authenticated using the service account you will also need to maintain an authorized mapping between that account and the app user's leg party this mapping can be stored anywhere durable but a reasonable default is on the app install contract as part of onboarding if there is no compelling reason to store it elsewhere when the backend is accessed directly from end user front ends in external organizations this may require a more complex solution if the number of end users is small then it may be okay to create IM am users for them and the app providers I am in the same manner as with external service users and use these to authenticate them using an IAM outside the application users control has the trust implications we have already discussed so be careful and explicit about what parties and permissions you map these users onto where trust issues are intractable or for large numbers of end users using a Federated identity integration like samle is advisable with authentication and identity being foundational to daml Applications it is critical that workflow tests include authentication to that end it is important to run your tests with authentication turned on mock authentication servers or self-issued jot tokens created On Demand by the test harness can make it easy to set up the required access tokens for test runs what is important is that your tests include concepts of identity and authentication to avoid surprises in production parties represent Identity On The Ledger they are at the core of how the DL platform provides authorization privacy and control over trust boundaries the decision of how to allocate parties in a damel application is therefore of critical importance as a TSA you need to decide for your business domain which type of business entity parties will represent it is common for this to result in a single party per independent business entity occasionally other stable business roles may be appropriate but basing party topology on an internal organizational structure is almost always an anti- pattern parties are hosted on participant noes and to strength in the chain of trust every organization should have at least one party under its control access capabilities to parties are allocated to participant users which makes the issuing of authentication credentials by each participant's IM am the Providence root of all trust in the system the recommended DL application architecture reflects this each organization hosts their own participant node participant user credentials are managed by each organization's local I am system and user off lger system access is mediated by backend Services applying internal access and control policies finally because authentication is so Central to the guarantees of the DL application authentication should be included in your endtoend integration tests from the outset","transcript_synced_at":"2026-10-26T04:04:58.840Z","segments":[{"start_seconds":0,"text":"welcome to authentication and IM am daml applications cross organizational trust boundaries so","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=0s"},{"start_seconds":8,"text":"authentication is a crosscutting concern that requires attention in your solution architecture in this lesson you will","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=8s"},{"start_seconds":15,"text":"learn how to select a suitable party topology to manage authentication both of end users and backend services","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=15s"},{"start_seconds":24,"text":"including the specific considerations required when providing backend services to external entities across trust","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=24s"},{"start_seconds":32,"text":"boundaries we have seen in previous courses how daml applications are built around shared consensus and that daml","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=32s"},{"start_seconds":40,"text":"allows consensus to be achieved over trust boundaries it is The daml Ledger managed across participant nodes sharing","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=40s"},{"start_seconds":48,"text":"a synchronizer that provides this consensus D parties provide first class Global identities that act on and share","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=48s"},{"start_seconds":57,"text":"in The Ledger consensus in Dam applications they are used to represent the organizations interacting with each","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=57s"},{"start_seconds":64,"text":"other in a synchronized manner Over The Ledger obtaining the ability to act as a party is to obtain the ability to act as","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=64s"},{"start_seconds":73,"text":"the organization obtaining the ability to read as a party is to obtain the ability to observe every contract or","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=73s"},{"start_seconds":81,"text":"Ledger event visible to the organization or organizational entity that party represents as a result your damel party","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=81s"},{"start_seconds":89,"text":"to ology deciding the granularity of what organizational entity a party represents within your application is a","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=89s"},{"start_seconds":97,"text":"critical design concern it is critical that each organization appropriately controls the","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=97s"},{"start_seconds":103,"text":"access to the parties that represent the organization this is typically achieved using authentication credentials issued","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=103s"},{"start_seconds":111,"text":"by an IM am system under their control without that control an organization would lose control over the workflows","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=111s"},{"start_seconds":119,"text":"run on on Ledger with their counterparties and whoever had access to act on The Ledger using an","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=119s"},{"start_seconds":126,"text":"organization's parties could advance that organization's workflows for their own benefit which is why the daml","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=126s"},{"start_seconds":133,"text":"application architecture is the way it is the benefits provided by daml and Canton that we discussed in the earlier","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=133s"},{"start_seconds":142,"text":"courses rely on this Providence chain of trust The Ledger authorization and its association with organization","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=142s"},{"start_seconds":150,"text":"damel parties the credentialing of participant users access damel parties hosted on participant nodes and in","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=150s"},{"start_seconds":158,"text":"operation the management of access to participant users through an authentication process with an am under","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=158s"},{"start_seconds":166,"text":"the organization's control delegating authentication across a trust boundary should be avoided as it weakens the","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=166s"},{"start_seconds":173,"text":"authorization delegation privacy and non-repudiation guarantees provided by Canton and the DL","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=173s"},{"start_seconds":181,"text":"Ledger the rest of this lesson will go into more detail about how to design your DL party topology and how to manage","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=181s"},{"start_seconds":189,"text":"the authentication of users and services within a DL application those details matter but the most important","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=189s"},{"start_seconds":196,"text":"architectural takeaway is in order for daml to provide non-repudiation each organization should","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=196s"},{"start_seconds":204,"text":"control their own participant node and the IM am that controls access to it","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=204s"},{"start_seconds":214,"text":"in previous lessons we have seen how dl's privacy and authorization model is defined in terms of parties parties are","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=214s"},{"start_seconds":222,"text":"the sole representation of Identity On The Ledger and therefore signatories controllers observers Witnesses and","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=222s"},{"start_seconds":230,"text":"informes are all defined as sets of DML parties consequently daml parties are used to govern Access Control to ler","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=230s"},{"start_seconds":239,"text":"data and therefore encode identity across interorganizational boundaries for this reason which entities will be","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=239s"},{"start_seconds":247,"text":"represented as danal parties in your application is a very important architectural decision there is no","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=247s"},{"start_seconds":254,"text":"single answer to this question your decision is going to depend both on your business case and the way you implement","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=254s"},{"start_seconds":261,"text":"the business workflows using daml a good starting point is to use one party for the app provider and exactly","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=261s"},{"start_seconds":269,"text":"one for for each of the app users it is not uncommon for this to correspond to one party per legal entity and","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=269s"},{"start_seconds":276,"text":"consequently one party per trust boundary as a good default each of these parties is allocated on the respective","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=276s"},{"start_seconds":284,"text":"organizations participant node and represents that organization in on Ledger workflows note that more advanced","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=284s"},{"start_seconds":292,"text":"party topologies like hosting parties on multiple participant nodes or controlling parties independently of the","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=292s"},{"start_seconds":299,"text":"participant node are possible the Canton user manual has details and digital asset can advise if or how these more","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=299s"},{"start_seconds":307,"text":"advanced apologies apply to your specific circumstances however one party per organization hosted on their own","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=307s"},{"start_seconds":315,"text":"participant node is a good default for most applications this will align party topology with the desired granularity of","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=315s"},{"start_seconds":323,"text":"on Ledger visibility and authorization where the relationship of app user to organization to Legal entity are not one","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=323s"},{"start_seconds":331,"text":"to one you may need to consider if counterparties care about which legal entity acted in a particular workflow or","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=331s"},{"start_seconds":339,"text":"which of other options best represents the level of access control desired keep in mind that within a","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=339s"},{"start_seconds":347,"text":"single trust boundary you will usually have other options to manage access and authorization so while more fine grained","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=347s"},{"start_seconds":354,"text":"party topologies are possible they often leak entities internal detail details onto The Ledger and to","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=354s"},{"start_seconds":362,"text":"counterparties note that data for all parties on the same participant node is physically Consolidated interpart","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=362s"},{"start_seconds":369,"text":"privacy is restricted to what is returned by The Ledger API and in The Ledger consensus between participant","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=369s"},{"start_seconds":376,"text":"nodes we instead recommend implementing internal Access Control policies via backend Services as explained in","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=376s"},{"start_seconds":384,"text":"previous lessons a single party per trust boundary is generally preferred where you do decide to use multiple parties","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=384s"},{"start_seconds":393,"text":"for a single organization try to align parties with stable business roles as parties form the foundation of a ledger","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=393s"},{"start_seconds":400,"text":"consensus restructuring your party topology can be delicate and disruptive judicious addition of parties can help","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=400s"},{"start_seconds":408,"text":"resolve business requirements however the point where party topology reflects internal hierarchies is an anti- pattern","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=408s"},{"start_seconds":417,"text":"as the party is the level at which lure consensus and disclosure is defined so make careful note of the witnesses of","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=417s"},{"start_seconds":424,"text":"subtransaction to ensure you do not inadvertently divulge internal details finally keep in mind that adding","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=424s"},{"start_seconds":432,"text":"unnecessary parties can lead to hitting scalability limits which we will discuss further in a future","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=432s"},{"start_seconds":443,"text":"Course once you have decided on your party topology it becomes necessary to consider how you will manage manage","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=443s"},{"start_seconds":449,"text":"authenticating access to the parties by end users and backend services on the","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=449s"},{"start_seconds":456,"text":"relevant participant node in the case of backend Services access to their respective participant node the","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=456s"},{"start_seconds":464,"text":"recommended approach is for the backends administrator to allocate a service account for the backend in their organizations's IM am then for them to","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=464s"},{"start_seconds":473,"text":"create a participant user with the same name in the participant node identify the part being mediated by the backend","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=473s"},{"start_seconds":481,"text":"in the participant node note that while the example here shows two parties being used to represent the bank this will","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=481s"},{"start_seconds":489,"text":"often be only a single party and allocate to the participant user read as and act as rights for each of the","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=489s"},{"start_seconds":497,"text":"mediated parties finally configure the backend to use the service accounts user ID ooth","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=497s"},{"start_seconds":504,"text":"client ID and ooth secret and use those credentials when acquiring the job token","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=504s"},{"start_seconds":511,"text":"required to access The Ledger API a few points to keep in mind the daml platform is designed to allow the","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=511s"},{"start_seconds":519,"text":"use of standard tooling and ooth Technologies all the usual best practices that apply to allocating and","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=519s"},{"start_seconds":527,"text":"managing service accounts apply the relationship between participant users and Ledger parties is not one to one you","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=527s"},{"start_seconds":535,"text":"can have multiple Ledger parties associated with a single participant user multiple users can be granted","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=535s"},{"start_seconds":542,"text":"access to the same Ledger party each Grant of a ledger party to a participant user can provide independent read as and","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=542s"},{"start_seconds":550,"text":"access capabilities for that user to that party we recommend that front-ends submit all their commands via a backend","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=550s"},{"start_seconds":559,"text":"service and have the backend authenticate them as explained later however if a front end does submit","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=559s"},{"start_seconds":566,"text":"commands directly to the Ledger API on a participant node you will also need to allow front-end users to authenticate to","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=566s"},{"start_seconds":574,"text":"the participant node generally this will require creating participant users for every end user in your IM am with access to the","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=574s"},{"start_seconds":584,"text":"front end as with the backend service participant user these front-end participant users will need to be","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=584s"},{"start_seconds":590,"text":"granted read as and act as rights for The Ledger parties accessed via the front end where the front end is talking","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=590s"},{"start_seconds":598,"text":"directly to The Ledger API front-end users are directly associated with participant users consequently this form","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=598s"},{"start_seconds":607,"text":"of DL application architecture is only suitable where it is appropriate for end users to be granted full authority to","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=607s"},{"start_seconds":614,"text":"view and act as a specific Party On The Ledger and where the party must provide the desired granularity of authorization","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=614s"},{"start_seconds":622,"text":"and privacy common examples of this include applications where every end user is an entity within your party","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=622s"},{"start_seconds":630,"text":"topology and therefore acts using a party of their own applications where end users are trusted by and acting in","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=630s"},{"start_seconds":638,"text":"the name of the organization represented by the party such as administrative operational and support front ends","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=638s"},{"start_seconds":646,"text":"accessible only by trusted administrators and operations Personnel given the larger number of participant users involved in direct","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=646s"},{"start_seconds":655,"text":"front-end access you will need to consider how you will create and configure them while they can be set up manually using the Canton console you","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=655s"},{"start_seconds":664,"text":"may need to consider scripting the process use the primary party field to associate an end user's party to its","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=664s"},{"start_seconds":671,"text":"participant user if a user has act as rights for multiple parties store the mapping between the parties and their","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=671s"},{"start_seconds":679,"text":"respective purposes in the user metadata use the user endpoint on The Ledger API to retrieve the primary party and user","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=679s"},{"start_seconds":688,"text":"metadata of the authenticated user from the front end often it is technically simpler for Ledger access to be mediated","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=688s"},{"start_seconds":696,"text":"by a back-end API when providing mediating backend services within the same authentication","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=696s"},{"start_seconds":703,"text":"domain use best practices and your organization's existing advice and facilities for authenticating the","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=703s"},{"start_seconds":710,"text":"requests to your backend most applications should ensure all read and write access is mediated via backend as","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=710s"},{"start_seconds":718,"text":"this allows the backend to implement fine grained Access Control at the service level it then becomes the","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=718s"},{"start_seconds":726,"text":"backend Services responsibility to authenticate the mediated end users and apply the required Access Control","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=726s"},{"start_seconds":733,"text":"policies for the end user things are slightly more complicated when a backend needs to provide services to requests from","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=733s"},{"start_seconds":741,"text":"outside the authentication domain otherwise one option is to create service accounts within the app","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=741s"},{"start_seconds":748,"text":"providers IM am for external backends a common use case for this approach is to provide readon access to query reference","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=748s"},{"start_seconds":758,"text":"data when this option is available keep in mind that the concept of interorganizational Identity On The","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=758s"},{"start_seconds":764,"text":"Ledger Remains The Ledger party so while the identity of the app user can be authenticated using the service account","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=764s"},{"start_seconds":773,"text":"you will also need to maintain an authorized mapping between that account and the app user's leg party this","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=773s"},{"start_seconds":780,"text":"mapping can be stored anywhere durable but a reasonable default is on the app install contract as part of onboarding","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=780s"},{"start_seconds":788,"text":"if there is no compelling reason to store it elsewhere when the backend is accessed directly from end user front ends in","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=788s"},{"start_seconds":796,"text":"external organizations this may require a more complex solution if the number of end users is","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=796s"},{"start_seconds":803,"text":"small then it may be okay to create IM am users for them and the app providers I am in the same manner as with external","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=803s"},{"start_seconds":812,"text":"service users and use these to authenticate them using an IAM outside the application users control has the","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=812s"},{"start_seconds":820,"text":"trust implications we have already discussed so be careful and explicit about what parties and permissions you","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=820s"},{"start_seconds":827,"text":"map these users onto where trust issues are intractable or for large numbers of end users using a Federated identity","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=827s"},{"start_seconds":835,"text":"integration like samle is advisable with authentication and identity being foundational to daml Applications it is","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=835s"},{"start_seconds":844,"text":"critical that workflow tests include authentication to that end it is important to run your tests with","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=844s"},{"start_seconds":851,"text":"authentication turned on mock authentication servers or self-issued jot tokens created On Demand by the test","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=851s"},{"start_seconds":860,"text":"harness can make it easy to set up the required access tokens for test runs what is important is that your tests","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=860s"},{"start_seconds":867,"text":"include concepts of identity and authentication to avoid surprises in","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=867s"},{"start_seconds":876,"text":"production parties represent Identity On The Ledger they are at the core of how the DL platform provides authorization","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=876s"},{"start_seconds":885,"text":"privacy and control over trust boundaries the decision of how to allocate parties in a damel application","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=885s"},{"start_seconds":892,"text":"is therefore of critical importance as a TSA you need to decide for your business domain which type of business entity","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=892s"},{"start_seconds":901,"text":"parties will represent it is common for this to result in a single party per independent business entity occasionally","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=901s"},{"start_seconds":909,"text":"other stable business roles may be appropriate but basing party topology on an internal organizational structure is","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=909s"},{"start_seconds":916,"text":"almost always an anti- pattern parties are hosted on participant noes and to strength in the chain of trust every","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=916s"},{"start_seconds":925,"text":"organization should have at least one party under its control access capabilities to parties are","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=925s"},{"start_seconds":931,"text":"allocated to participant users which makes the issuing of authentication credentials by each participant's IM am","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=931s"},{"start_seconds":940,"text":"the Providence root of all trust in the system the recommended DL application architecture reflects this each","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=940s"},{"start_seconds":948,"text":"organization hosts their own participant node participant user credentials are managed by each organization's local I","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=948s"},{"start_seconds":956,"text":"am system and user off lger system access is mediated by backend Services applying internal access and control","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=956s"},{"start_seconds":965,"text":"policies finally because authentication is so Central to the guarantees of the DL application authentication should be","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=965s"},{"start_seconds":974,"text":"included in your endtoend integration tests from the outset","url":"https://www.youtube.com/watch?v=p7UNTkZsS7g&t=974s"}],"youtube_url":"https://youtube.com/watch?v=p7UNTkZsS7g","url":"https://ccpedia.xyz/videos/p7UNTkZsS7g"}