Scribd Logo
Upload

Welcome to Scribd!

  • 8 views

    Azure Book 173

    Uploaded by

    jayantascribe

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    Azure Book 173

    Uploaded by

    jayantascribe
    8 views1 page

    Original Title

    Azure book 173

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    8 views1 page

    Azure Book 173

    Uploaded by

    jayantascribe

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    of 1

    160

    Vault authentication with managed identities for Azure


    resources
    Your application requires service passwords, connection strings, and other secret configuration values to
    do its job. Storing and handling secret values is risky, and every usage introduces the possibility of
    leakage. Azure Key Vault, in combination with managed identities for Azure resources, enables your Azure
    web app to access secret configuration values easily and securely without needing to store any secrets in
    your source control or configuration.
    Azure Key Vault uses Azure Active Directory (Azure AD) to authenticate users and apps that try to access
    a vault. To grant your web app access to the vault, you first need to register your app with Azure Active
    Directory. Registering creates an identity for the app. After the app has an identity, you can assign vault
    permissions to it.
    Apps and users authenticate to Key Vault using an Azure AD authentication token. Getting a token from
    Azure AD requires a secret or certificate because anyone with a token could use the app identity to
    access all the secrets in the vault.
    To access resources that are secured by an Azure AD tenant, the entity that requires access must be
    represented by a security principal. This requirement is true for both users (user principal) and applica-
    tions (service principal). The security principal defines the access policy and permissions for the user/
    application in the Azure AD tenant. This enables core features such as authentication of the user/applica-
    tion during sign-in, and authorization during resource access.

    Select application service principals


    There are three types of service principal:
    ●● Application - The type of service principal is the local representation, or application instance, of a
    global application object in a single tenant or directory. In this case, a service principal is a concrete
    instance created from the application object and inherits certain properties from that application
    object. A service principal is created in each tenant where the application is used and references the
    globally unique app object. The service principal object defines what the app can do in the specific
    tenant, who can access the app, and what resources the app can access.
    When an application is given permission to access resources in a tenant (upon registration or consent), a
    service principal object is created. When you register an application using the Azure portal, a service
    principal is created automatically. You can also create service principal objects in a tenant using Azure
    PowerShell, Azure CLI, Microsoft Graph, and other tools.
    ●● Managed identity - This type of service principal is used to represent a managed identity. Managed
    identities eliminate the need for developers to manage credentials. Managed identities provide an
    identity for applications to use when connecting to resources that support Azure AD authentication.
    When a managed identity is enabled, a service principal representing that managed identity is created
    in your tenant. Service principals representing managed identities can be granted access and permis-
    sions, but cannot be updated or modified directly.
    ●● Legacy - This type of service principal represents a legacy app, which is an app created before app
    registrations were introduced or an app created through legacy experiences. A legacy service principal
    can have credentials, service principal names, reply URLs, and other properties that an authorized user
    can edit, but does not have an associated app registration. The service principal can only be used in
    the tenant where it was created.

    You might also like

    pFad - Phonifier reborn

    Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

    Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


    Alternative Proxies:

    Alternative Proxy

    pFad Proxy

    pFad v3 Proxy

    pFad v4 Proxy