Hoe en waarom toepassingen worden toegevoegd aan Azure ADHow and why applications are added to Azure AD

Er zijn twee representaties van toepassingen in azure AD:There are two representations of applications in Azure AD:

  • Toepassings objecten -hoewel er uitzonde ringenzijn, kunnen toepassings objecten worden beschouwd als de definitie van een toepassing.Application objects - Although there are exceptions, application objects can be considered the definition of an application.
  • Service-principals : kan worden beschouwd als een exemplaar van een toepassing.Service principals - Can be considered an instance of an application. Service-principals verwijzen doorgaans naar een toepassings object en er kan naar één toepassings object worden verwezen door meerdere service-principals in directory's.Service principals generally reference an application object, and one application object can be referenced by multiple service principals across directories.

Wat zijn toepassings objecten en waar komen ze vandaan?What are application objects and where do they come from?

U kunt toepassings objecten in de Azure portal beheren via de app registraties .You can manage application objects in the Azure portal through the App Registrations experience. Toepassings objecten beschrijven de toepassing naar Azure AD en kunnen worden beschouwd als de definitie van de toepassing, zodat de service kan weten hoe tokens moeten worden uitgegeven aan de toepassing op basis van de instellingen ervan.Application objects describe the application to Azure AD and can be considered the definition of the application, allowing the service to know how to issue tokens to the application based on its settings. Het toepassings object bevinden zich alleen in de basismap, zelfs als dit een multi tenant-toepassing is die service-principals in andere mappen ondersteunt.The application object will only exist in its home directory, even if it's a multi-tenant application supporting service principals in other directories. Het toepassings object kan bestaan uit een van de volgende (evenals aanvullende informatie die hier niet wordt vermeld):The application object may include any of the following (as well as additional information not mentioned here):

  • Naam, logo en uitgeverName, logo, and publisher
  • Omleidings-Uri'sRedirect URIs
  • Geheimen (symmetrische en/of asymmetrische sleutels die worden gebruikt voor het verifiëren van de toepassing)Secrets (symmetric and/or asymmetric keys used to authenticate the application)
  • API-afhankelijkheden (OAuth)API dependencies (OAuth)
  • Gepubliceerde Api's/bronnen/bereiken (OAuth)Published APIs/resources/scopes (OAuth)
  • App-rollen (RBAC)App roles (RBAC)
  • SSO-meta gegevens en-configuratieSSO metadata and configuration
  • Meta gegevens en configuratie van gebruikers inrichtenUser provisioning metadata and configuration
  • Meta gegevens en configuratie van proxyProxy metadata and configuration

Toepassings objecten kunnen worden gemaakt via meerdere paden, waaronder:Application objects can be created through multiple pathways, including:

  • Toepassings registraties in de Azure PortalApplication registrations in the Azure portal
  • Een nieuwe toepassing maken met Visual Studio en deze configureren voor gebruik van Azure AD-verificatieCreating a new application using Visual Studio and configuring it to use Azure AD authentication
  • Wanneer een beheerder een toepassing toevoegt uit de app-galerie (waardoor ook een service-principal wordt gemaakt)When an admin adds an application from the app gallery (which will also create a service principal)
  • De Microsoft Graph-API of Power shell gebruiken om een nieuwe toepassing te makenUsing the Microsoft Graph API or PowerShell to create a new application
  • Veel andere onderdelen, inclusief verschillende ontwikkel ervaringen in Azure en in API Explorer-ervaringen op ontwikkel centrumsMany others including various developer experiences in Azure and in API explorer experiences across developer centers

Wat zijn service-principals en waar komen ze vandaan?What are service principals and where do they come from?

U kunt de service-principals in de Azure portal beheren via de ervaring van bedrijfs toepassingen .You can manage service principals in the Azure portal through the Enterprise Applications experience. Service-principals zijn datgene wat een toepassing is die verbinding maakt met Azure AD en kan worden beschouwd als het exemplaar van de toepassing in uw Directory.Service principals are what govern an application connecting to Azure AD and can be considered the instance of the application in your directory. Voor een bepaalde toepassing kan het Maxi maal één toepassings object hebben (dat is geregistreerd in een ' Home ' Directory) en een of meer Service Principal-objecten die exemplaren van de toepassing vertegenwoordigen in elke map waarin deze wordt uitgevoerd.For any given application, it can have at most one application object (which is registered in a "home" directory) and one or more service principal objects representing instances of the application in every directory in which it acts.

De service-principal kan het volgende omvatten:The service principal can include:

  • Een verwijzing naar een toepassings object via de eigenschap toepassings-IDA reference back to an application object through the application ID property
  • Records van lokale gebruikers-en groeps toepassingen-roltoewijzingenRecords of local user and group application-role assignments
  • Records van lokale gebruikers-en beheerders machtigingen die aan de toepassing zijn verleendRecords of local user and admin permissions granted to the application
    • Bijvoorbeeld: machtiging voor de toepassing om toegang te krijgen tot de e-mail van een bepaalde gebruikerFor example: permission for the application to access a particular user's email
  • Records van lokale beleids regels met beleid voor voorwaardelijke toegangRecords of local policies including Conditional Access policy
  • Records met alternatieve lokale instellingen voor een toepassingRecords of alternate local settings for an application
    • Claim transformatie regelsClaims transformation rules
    • Kenmerk toewijzingen (gebruikers inrichten)Attribute mappings (User provisioning)
    • Directory-specifieke app-rollen (als de toepassing aangepaste rollen ondersteunt)Directory-specific app roles (if the application supports custom roles)
    • Directory-specifieke naam of logoDirectory-specific name or logo

Net als toepassings objecten kunnen service-principals ook worden gemaakt via meerdere paden, waaronder:Like application objects, service principals can also be created through multiple pathways including:

  • Wanneer gebruikers zich aanmelden bij een toepassing van derden die is geïntegreerd met Azure ADWhen users sign in to a third-party application integrated with Azure AD
    • Tijdens het aanmelden wordt gebruikers gevraagd om machtigingen aan te geven voor de toepassing om toegang te krijgen tot hun profiel en andere machtigingen.During sign-in, users are asked to give permission to the application to access their profile and other permissions. De eerste persoon die toestemming verleent, veroorzaakt een service-principal die de toepassing vertegenwoordigt die moet worden toegevoegd aan de Directory.The first person to give consent causes a service principal that represents the application to be added to the directory.
  • Wanneer gebruikers zich aanmelden bij micro soft onlineservices zoals Microsoft 365When users sign in to Microsoft online services like Microsoft 365
    • Wanneer u zich abonneert op Microsoft 365 of een proef versie begint, worden een of meer service-principals gemaakt in de map die de verschillende services vertegenwoordigt die worden gebruikt voor het leveren van alle functies die zijn gekoppeld aan Microsoft 365.When you subscribe to Microsoft 365 or begin a trial, one or more service principals are created in the directory representing the various services that are used to deliver all of the functionality associated with Microsoft 365.
    • Sommige Microsoft 365 Services, zoals share point, maken voortdurend service-principals voor veilige communicatie tussen onderdelen, waaronder werk stromen.Some Microsoft 365 services like SharePoint create service principals on an ongoing basis to allow secure communication between components including workflows.
  • Wanneer een beheerder een toepassing toevoegt uit de app-galerie (Hiermee wordt ook een onderliggend app-object gemaakt)When an admin adds an application from the app gallery (this will also create an underlying app object)
  • Een toepassing voor het gebruik van Azure AD-toepassingsproxy toevoegenAdd an application to use the Azure AD Application Proxy
  • Een toepassing verbinden voor eenmalige aanmelding met SAML of een eenmalige aanmelding met een wacht woord (SSO)Connect an application for single sign on using SAML or password single sign-on (SSO)
  • Programmatisch via de Microsoft Graph-API of Power shellProgrammatically via the Microsoft Graph API or PowerShell

Een toepassing heeft één toepassings object in de basismap waarnaar wordt verwezen door een of meer service-principals in elk van de directory's waar het actief is (inclusief de basismap van de toepassing).An application has one application object in its home directory that is referenced by one or more service principals in each of the directories where it operates (including the application's home directory).

Hiermee wordt de relatie tussen app-objecten en service-principals weer gegeven

In het voor gaande diagram onderhoudt micro soft twee directory's intern (weer gegeven aan de linkerkant) die worden gebruikt voor het publiceren van toepassingen:In the preceding diagram, Microsoft maintains two directories internally (shown on the left) that it uses to publish applications:

  • Eén voor micro soft-apps (adreslijst van micro soft-Services)One for Microsoft Apps (Microsoft services directory)
  • Een voor vooraf geïntegreerde toepassingen van derden (app Gallery Directory)One for pre-integrated third-party applications (App gallery directory)

Toepassings uitgevers/leveranciers die met Azure AD zijn geïntegreerd, moeten een publicatiemap hebben (weer gegeven aan de rechter kant als ' een enkele SaaS-Directory ').Application publishers/vendors who integrate with Azure AD are required to have a publishing directory (shown on the right as "Some SaaS Directory").

Toepassingen die u zelf toevoegt (wordt weer gegeven als app (uw) in het diagram) zijn:Applications that you add yourself (represented as App (yours) in the diagram) include:

  • Apps die u hebt ontwikkeld (geïntegreerd met Azure AD)Apps you developed (integrated with Azure AD)
  • Apps waarmee u verbinding hebt gemaakt voor eenmalige aanmeldingApps you connected for single-sign-on
  • Apps die u hebt gepubliceerd met behulp van de Azure AD-toepassings proxyApps you published using the Azure AD application proxy

Opmerkingen en uitzonde ringenNotes and exceptions

  • Niet alle service-principals verwijzen terug naar een toepassings object.Not all service principals point back to an application object. Toen Azure AD de services die aan toepassingen zijn geleverd, beperkt waren en de Service-Principal voldoende was om een toepassings identiteit in te richten.When Azure AD was originally built the services provided to applications were more limited and the service principal was sufficient for establishing an application identity. De oorspronkelijke Service-Principal bevond zich dichter bij de vorm van het Windows Server Active Directory-Service account.The original service principal was closer in shape to the Windows Server Active Directory service account. Daarom is het nog steeds mogelijk om service-principals te maken via verschillende routes, zoals het gebruik van Azure AD Power shell, zonder eerst een toepassings object te maken.For this reason, it's still possible to create service principals through different pathways, such as using Azure AD PowerShell, without first creating an application object. De Microsoft Graph-API vereist een toepassings object voordat u een Service-Principal maakt.The Microsoft Graph API requires an application object before creating a service principal.
  • Niet alle hierboven beschreven informatie wordt momenteel programmatisch weer gegeven.Not all of the information described above is currently exposed programmatically. De volgende opties zijn alleen beschikbaar in de gebruikers interface:The following are only available in the UI:
    • Claim transformatie regelsClaims transformation rules
    • Kenmerk toewijzingen (gebruikers inrichten)Attribute mappings (User provisioning)
  • Zie de referentie documentatie voor de Microsoft Graph-API voor meer informatie over de Service-Principal en toepassings objecten:For more detailed information on the service principal and application objects, see the Microsoft Graph API reference documentation:

Waarom kunnen toepassingen worden geïntegreerd met Azure AD?Why do applications integrate with Azure AD?

Toepassingen worden toegevoegd aan Azure AD om gebruik te maken van een of meer van de services die het biedt, waaronder:Applications are added to Azure AD to leverage one or more of the services it provides including:

  • Verificatie en autorisatie van toepassingenApplication authentication and authorization
  • Gebruikers verificatie en-autorisatieUser authentication and authorization
  • Eenmalige aanmelding met Federatie of wacht woordSSO using federation or password
  • Gebruikers inrichten en synchronisatieUser provisioning and synchronization
  • Op rollen gebaseerd toegangs beheer: gebruik de Directory om toepassings rollen te definiëren voor het uitvoeren van op rollen gebaseerde autorisatie controles in een toepassingRole-based access control - Use the directory to define application roles to perform role-based authorization checks in an application
  • OAuth-autorisatie Services: wordt gebruikt door Microsoft 365 en andere micro soft-toepassingen om toegang te verlenen tot Api's/bronnenOAuth authorization services - Used by Microsoft 365 and other Microsoft applications to authorize access to APIs/resources
  • Toepassingen publiceren en proxy-een toepassing publiceren vanuit een particulier netwerk naar InternetApplication publishing and proxy - Publish an application from a private network to the internet
  • Kenmerken van de extensie van het Directory-schema: Breid het schema van de Service-Principal en gebruikers objecten uit voor het opslaan van aanvullende gegevens in azure ADDirectory schema extension attributes - Extend the schema of service principal and user objects to store additional data in Azure AD

Wie is gemachtigd om toepassingen toe te voegen aan mijn Azure AD-exemplaar?Who has permission to add applications to my Azure AD instance?

Hoewel er sommige taken zijn die alleen voor globale beheerders kunnen worden uitgevoerd (zoals het toevoegen van toepassingen uit de app-galerie en het configureren van een toepassing voor het gebruik van de toepassings proxy), hebben alle gebruikers in uw Directory standaard rechten om toepassings objecten te registreren die ze ontwikkelen en wijzen op welke toepassingen ze delen/toegang tot hun organisatie gegevens geven via toestemming.While there are some tasks that only global administrators can do (such as adding applications from the app gallery and configuring an application to use the Application Proxy) by default all users in your directory have rights to register application objects that they are developing and discretion over which applications they share/give access to their organizational data through consent. Als een persoon de eerste gebruiker in uw directory is om zich aan te melden bij een toepassing en toestemming te verlenen, wordt een Service-Principal in uw Tenant gemaakt. anders wordt de informatie over het verlenen van toestemming opgeslagen op de bestaande service-principal.If a person is the first user in your directory to sign in to an application and grant consent, that will create a service principal in your tenant; otherwise, the consent grant information will be stored on the existing service principal.

Het toestaan van gebruikers om toepassingen te registreren en goed te keuren, kunnen aanvankelijk een geluid hebben over, maar het volgende bedenken:Allowing users to register and consent to applications might initially sound concerning, but keep the following in mind:

  • Toepassingen kunnen veel jaren gebruikmaken van Windows Server Active Directory voor gebruikers verificatie, zonder dat de toepassing moet worden geregistreerd of geregistreerd in de map.Applications have been able to leverage Windows Server Active Directory for user authentication for many years without requiring the application to be registered or recorded in the directory. Nu heeft de organisatie de zicht baarheid verbeterd tot precies het aantal toepassingen dat de Directory gebruikt en voor wat doel einde.Now the organization will have improved visibility to exactly how many applications are using the directory and for what purpose.
  • Door deze verantwoordelijkheden aan gebruikers te delegeren, wordt de nood zaak voor het registreren en publiceren van een door de beheerder gestuurde toepassing genegeerd.Delegating these responsibilities to users negates the need for an admin-driven application registration and publishing process. Met Active Directory Federation Services (ADFS) was het waarschijnlijk dat een beheerder een toepassing heeft toegevoegd als een Relying Party namens hun ontwikkel aars.With Active Directory Federation Services (ADFS) it was likely that an admin had to add an application as a relying party on behalf of their developers. Ontwikkel aars kunnen nu selfservice Services installeren.Now developers can self-service.
  • Gebruikers die zich aanmelden bij toepassingen die hun organisatie accounts gebruiken voor zakelijke doel einden, zijn goed.Users signing in to applications using their organization accounts for business purposes is a good thing. Als ze de organisatie daarna verlaten, verliezen ze automatisch de toegang tot hun account in de toepassing die ze gebruiken.If they subsequently leave the organization they will automatically lose access to their account in the application they were using.
  • Met een record welke gegevens zijn gedeeld met welke toepassing het goed is.Having a record of what data was shared with which application is a good thing. Gegevens zijn verwisselbaar dan ooit en het is handig om een duidelijke record te hebben van wie de gegevens deelt met welke toepassingen.Data is more transportable than ever and it's useful to have a clear record of who shared what data with which applications.
  • API-eigen aars die Azure AD voor OAuth gebruiken, beslissen precies welke machtigingen gebruikers kunnen verlenen aan toepassingen en aan welke machtigingen een beheerder moet instemmen.API owners who use Azure AD for OAuth decide exactly what permissions users are able to grant to applications and which permissions require an admin to agree to. Alleen beheerders kunnen toestemming geven voor grotere bereiken en meer significante machtigingen, terwijl de toestemming van de gebruiker is afgestemd op de eigen gegevens en mogelijkheden van de gebruikers.Only admins can consent to larger scopes and more significant permissions, while user consent is scoped to the users' own data and capabilities.
  • Wanneer een gebruiker een toepassing toevoegt of toestaat om toegang te krijgen tot hun gegevens, kan de gebeurtenis worden gecontroleerd zodat u de controle rapporten kunt weer geven in de Azure Portal om te bepalen hoe een toepassing aan de Directory is toegevoegd.When a user adds or allows an application to access their data, the event can be audited so you can view the Audit Reports within the Azure portal to determine how an application was added to the directory.

Als u nog steeds wilt voor komen dat gebruikers in uw Directory toepassingen registreren en zich niet kunnen aanmelden bij toepassingen zonder goed keuring van de beheerder, zijn er twee instellingen die u kunt wijzigen om deze mogelijkheden uit te scha kelen:If you still want to prevent users in your directory from registering applications and from signing in to applications without administrator approval, there are two settings that you can change to turn off those capabilities:

  • Om te voor komen dat gebruikers namens hun eigen naam worden gezonden:To prevent users from consenting to applications on their own behalf:

    1. Ga in het Azure Portal naar de sectie gebruikers instellingen onder bedrijfs toepassingen.In the Azure portal, go to the User settings section under Enterprise applications.

    2. Wijzigings gebruikers kunnen toestemming geven voor apps die toegang hebben tot Bedrijfs gegevens namens hun naam .Change Users can consent to apps accessing company data on their behalf to No.

      Notitie

      Als u besluit de toestemming van de gebruiker uit te scha kelen, moet een beheerder toestemming geven voor een nieuwe toepassing die een gebruiker nodig heeft om te worden gebruikt.If you decide to turn off user consent, an admin will be required to consent to any new application a user needs to use.

  • Om te voor komen dat gebruikers hun eigen toepassingen registreren:To prevent users from registering their own applications:

    1. Ga in het Azure Portal naar de sectie gebruikers instellingen onder Azure Active DirectoryIn the Azure portal, go to the User settings section under Azure Active Directory
    2. Wijzigings gebruikers kunnen toepassingen registreren op Nee.Change Users can register applications to No.

Notitie

Micro soft zelf maakt gebruik van de standaard configuratie, waarbij gebruikers toepassingen kunnen registreren en op hun eigen naam mogen instemmen.Microsoft itself uses the default configuration with users able to register applications and consent to applications on their own behalf.