Apps Java verifiëren voor Azure services met behulp van de Azure Identity-bibliotheek

Apps kunnen de Azure Identity-bibliotheek gebruiken om te verifiëren bij Microsoft Entra ID, zodat de apps toegang hebben tot Azure services en resources. Deze verificatievereiste is van toepassing of de app wordt geïmplementeerd op Azure, on-premises wordt gehost of lokaal wordt uitgevoerd op een ontwikkelwerkstation. In dit artikel worden de aanbevolen methoden beschreven voor het verifiëren van een app voor Microsoft Entra ID in verschillende omgevingen bij het gebruik van de Azure SDK-clientbibliotheken.

Aanbevolen benadering voor app-verificatie

Verificatie op basis van tokens via Microsoft Entra ID is de aanbevolen methode voor het verifiëren van apps voor Azure, in plaats van verbindingsreeksen of opties op basis van sleutels te gebruiken. De Azure Identiteitsbibliotheek biedt klassen die verificatie op basis van tokens ondersteunen en apps in staat stellen om te verifiëren bij Azure resources, ongeacht of de app lokaal, op Azure of op een on-premises server wordt uitgevoerd.

Voordelen van verificatie op basis van tokens

Verificatie op basis van tokens biedt de volgende voordelen ten opzichte van verbindingsreeksen:

• Verificatie op basis van tokens zorgt ervoor dat alleen de specifieke apps die zijn bedoeld voor toegang tot de Azure-resource, toegang hebben, terwijl iedereen of elke app met een connection string verbinding kan maken met een Azure resource.
• Met verificatie op basis van tokens kunt u Azure resourcetoegang beperken tot alleen de specifieke machtigingen die nodig zijn voor de app. Deze benadering volgt het principe van minimale bevoegdheden. Een connection string verleent daarentegen volledige rechten aan de Azure resource.
• Wanneer u een beheerde identiteit gebruikt voor verificatie op basis van tokens, Azure beheerfuncties voor u afhandelt, zodat u zich geen zorgen hoeft te maken over taken zoals het beveiligen of roteren van geheimen. Deze aanpak maakt de app veiliger omdat er geen connection string of toepassingsgeheim is dat kan worden aangetast.
• De Azure Identity-bibliotheek verkrijgt en beheert Microsoft Entra tokens voor u.

Beperk het gebruik van verbindingsreeksen tot scenario's waarbij verificatie op basis van tokens geen optie is, eerste proof-of-concept-apps, of prototypes voor ontwikkeling die geen toegang hebben tot productiegegevens of gevoelige data. Gebruik indien mogelijk de verificatieklassen op basis van tokens die beschikbaar zijn in de Azure Identiteitsbibliotheek om te verifiëren bij Azure resources.

Verificatie in verschillende omgevingen

Het specifieke type verificatie op basis van tokens dat een app moet gebruiken om te verifiëren bij Azure resources, is afhankelijk van waar de app wordt uitgevoerd. Het volgende diagram bevat richtlijnen voor verschillende scenario's en omgevingen:

Wanneer een app:

• Hosted op Azure: De app moet zich authentiseren bij Azure-bronnen met behulp van een beheerde identiteit. Zie de sectie Authentication voor Azure gehoste apps voor meer informatie.
• Lokaal uitvoeren tijdens de ontwikkeling: De app kan worden geverifieerd bij Azure met behulp van een ontwikkelingsaccount, een broker of een service-principal. Zie de sectie Verificatie tijdens lokale ontwikkeling voor meer informatie.
• Hosted on-premises: de app moet worden geverifieerd bij Azure resources met behulp van een service-principal voor toepassingen of een beheerde identiteit in het geval van Azure Arc. On-premises werkstromen worden in meer detail besproken op Verificatie voor apps die on-premises worden gehost.

Verificatie voor Azure gehoste apps

Wanneer u uw app host op Azure, kan deze beheerde identiteiten gebruiken om te verifiëren bij Azure resources zonder referenties te hoeven beheren. Er zijn twee typen beheerde identiteiten beschikbaar: door de gebruiker toegewezen en door het systeem toegewezen.

Een door de gebruiker toegewezen beheerde identiteit gebruiken

U kunt een door de gebruiker toegewezen beheerde identiteit maken als een zelfstandige Azure resource. U kunt deze vervolgens toewijzen aan een of meer Azure resources, zodat deze resources dezelfde identiteit en machtigingen kunnen delen. Als u wilt verifiëren met behulp van een door de gebruiker toegewezen beheerde identiteit, maakt u de identiteit, wijst u deze toe aan uw Azure resource en configureert u vervolgens uw app om deze identiteit te gebruiken voor verificatie door de client-id, resource-id of object-id op te geven.

Een door het systeem toegewezen beheerde identiteit gebruiken

U kunt een door het systeem toegewezen beheerde identiteit rechtstreeks inschakelen op een Azure resource. De identiteit is gekoppeld aan de levenscyclus van die resource en wordt automatisch verwijderd wanneer de resource wordt verwijderd. Als u wilt verifiëren met behulp van een door het systeem toegewezen beheerde identiteit, schakelt u de identiteit in uw Azure resource in en configureert u vervolgens uw app voor het gebruik van deze identiteit voor verificatie.

Verificatie tijdens lokale ontwikkeling

Tijdens lokale ontwikkeling kunt u zich verifiëren bij Azure resources met behulp van uw referenties voor ontwikkelaars, een broker of een service-principal. Met behulp van een van deze methoden kunt u de verificatielogica van uw app testen zonder deze te implementeren op Azure.

Referenties voor ontwikkelaars gebruiken

U kunt uw eigen Azure-gegevens gebruiken om te authenticeren met Azure resources tijdens lokale ontwikkeling. Normaal gesproken gebruikt u een ontwikkelhulpprogramma, zoals Azure CLI, Azure Developer CLI, Azure PowerShell, Visual Studio Code of IntelliJ IDEA. Deze hulpprogramma's kunnen uw app voorzien van de benodigde tokens voor toegang tot Azure services. Deze methode is handig, maar u moet deze alleen gebruiken voor ontwikkelingsdoeleinden.

Een broker gebruiken

Brokered-authenticatie verzamelt gebruikersreferenties met behulp van de systeemauthenticatiebroker om een app te authenticeren. Een systeemverificatiebroker wordt uitgevoerd op de computer van een gebruiker en beheert de verificatie handshakes en tokenonderhoud voor alle verbonden accounts.

Een service-principal gebruiken

U kunt een service-principal maken in een Microsoft Entra-tenant om een app te vertegenwoordigen en te verifiëren bij Azure resources. U kunt uw app tijdens lokale ontwikkeling configureren om service-principalgegevens te gebruiken. Deze methode is veiliger dan het gebruik van referenties voor ontwikkelaars en is dichter bij de manier waarop uw app in productie wordt geverifieerd. Het is echter nog steeds minder ideaal dan het gebruik van een beheerde identiteit vanwege de noodzaak van geheimen.

Verificatie voor apps die on-premises worden gehost

Voor apps die on-premises worden gehost, kunt u een service-principal gebruiken om te verifiëren bij Azure resources. Dit omvat het maken van een service-principal in Microsoft Entra ID, het toewijzen van de benodigde machtigingen en het configureren van uw app voor het gebruik van diens referenties. Met deze methode kan uw on-premises app veilig toegang krijgen tot Azure services.