Register local applications
In the previous units, we have talked about users as identities, and we have touched on how a global application like CDF creates a service principal identity in Azure Active Directory (AAD). Also, we have mentioned that extractors or Python apps that run over a long time should have their own identity and not use a user’s identity. What then about applications that have been developed for a specific organization?
Any application or client you want to connect to only one specific organization's AAD follows the same pattern: create a new, AAD-specific (not global or federated) app registration in the AAD of the organization.
This is what you need to create a local (AAD-specific) app registration:
- The AAD instance needs to trust the CDF cluster.
- The CDF project needs to trust the AAD instance.
- The AAD users needs to belong to a group that matches a group in the CDF project.
The final thing you need is the identity of the client or application that will connect to CDF. This is a service principal identity, often referred to as an app registration. For CDF and other globally shared applications, you can reuse a global app registration.
However, for organization-specific apps, scripts, extractors, and even dashboarding tools like Grafana and PlotlyDash, you need a local app registration in the organization’s AAD.
Think about the hotel room analogy. For the janitor to access your room:
- The lock needs to trust the hotel security system.
- The hotel security system needs to trust the locks.
- There needs to be an "app registration" (or identity) in the hotel security system for the janitor.
- Your identity needs to be in the hotel security system with a registered "group access" to the hotel room.
And all these things need to be in place before you can grant the janitor access to the room for a time-limited period.