Desenvolver estratégia de permissões delegadas
Este artigo ajuda você, como desenvolvedor, a implementar a melhor abordagem para gerenciar permissões em seu aplicativo e desenvolver usando os princípios Zero Trust. Conforme descrito em Adquirir autorização para acessar recursos, as permissões delegadas são usadas com acesso delegado para permitir que um aplicativo aja em nome de um usuário, acessando apenas o que o usuário pode acessar. As permissões de aplicativo são usadas com acesso direto para permitir que um aplicativo acesse quaisquer dados aos quais a permissão está associada. Somente administradores e proprietários de entidades de serviço podem consentir com permissões de aplicativos.
Os modelos de permissão e consentimento referem-se principalmente a um aplicativo. O processo de permissão e consentimento não tem controle sobre o que um usuário pode fazer. Ele controla quais ações o aplicativo tem permissão para executar.
Faça referência ao diagrama de Venn a seguir. Com permissões delegadas, há uma interseção entre o que o usuário tem permissão para fazer e o que o aplicativo tem permissão para fazer. Essa interseção é a permissão efetiva à qual o aplicativo está vinculado. Sempre que você usa uma permissão delegada, as permissões efetivas a vinculam.
Por exemplo, seu aplicativo que tem usuários na frente do aplicativo recebe permissão para atualizar o perfil de cada usuário no locatário. Isso não significa que qualquer pessoa que execute seu aplicativo possa atualizar o perfil de outra pessoa. Se o administrador decidir conceder seu aplicativo User.ReadWrite.All, ele acredita que seu aplicativo está fazendo as coisas certas ao atualizar qualquer perfil de usuário. Seu aplicativo pode registrar as alterações e proteger adequadamente as informações. O administrador faz um juízo de valor sobre o aplicativo, não sobre o usuário.
Abordagem de privilégios mínimos
As APIs podem ser complexas. APIs simples podem não ter muitas operações. APIs complexas como o Microsoft Graph encapsulam muitas solicitações que um aplicativo pode querer usar. Só porque o aplicativo tem o direito de ler não significa que ele deve ter o direito de atualizar. Por exemplo, o Microsoft Graph tem milhares de APIs. Só porque você tem permissão para ler o perfil do usuário, não há razão para que você também tenha permissão para excluir todos os arquivos do OneDrive.
Como desenvolvedor, você deve:
- saiba quais APIs o aplicativo chama.
- entender a documentação da API e quais permissões a API exige.
- Use a menor permissão possível para realizar suas tarefas.
As APIs geralmente fornecem acesso aos armazenamentos de dados da organização e atraem a atenção de invasores que desejam acessar esses dados.
Avalie as permissões solicitadas para garantir que você busque o conjunto de privilégios mínimos absolutos para realizar o trabalho. Evite solicitar permissões de privilégios mais altos; em vez disso, trabalhe cuidadosamente com o grande número de permissões que APIs como o Microsoft Graph fornecem. Localize e use as permissões mínimas para atender às suas necessidades. Se você não escrever código para atualizar o perfil do usuário, não o solicitará para seu aplicativo. Se você acessar apenas usuários e grupos, não solicitará acesso a outras informações no diretório. Você não solicita permissão para gerenciar o e-mail do usuário se não escrever o código que acessa o e-mail do usuário.
No desenvolvimento de aplicações Zero Trust:
- Defina a intenção do seu aplicativo e o que ele precisa.
- Certifique-se de que os agentes mal-intencionados não podem comprometer e usar seu aplicativo de uma maneira que você não pretendia.
- Faça solicitações de aprovação nas quais você define seus requisitos (por exemplo, leia o e-mail do usuário).
Funções de administrador de usuário e locatário em permissão e consentimento
As pessoas que podem aprovar os seus pedidos dividem-se em duas categorias: administradores que podem sempre consentir com pedidos de permissão e utilizadores regulares que não são administradores. No entanto, os administradores de locatários têm a palavra final em seu locatário sobre quais permissões exigem consentimento do administrador e para quais permissões um usuário pode consentir.
Quando um designer de API requer o consentimento do administrador para uma permissão, essa permissão sempre requer o consentimento do administrador. Um administrador de locatário não pode ignorar isso e exigir apenas o consentimento do usuário.
Quando um designer de API define permissões que exigem o consentimento do usuário, o administrador do locatário pode anular as sugestões de consentimento do usuário do designer de API. Os administradores de locatários podem fazer isso com uma "grande mudança" no locatário: tudo requer o consentimento do administrador. Eles podem anular o consentimento do usuário de uma forma mais granular com o gerenciamento de permissão e consentimento. Por exemplo, eles podem permitir que os usuários consintam com solicitações de consentimento de editores verificados, mas não de outros editores. Em outro exemplo, eles podem permitir que User.Read o usuário entre e leia seu perfil, mas exigem o consentimento do administrador para aplicativos que pedem permissão para enviar e-mails ou arquivos.
Os designers de API fazem suas sugestões, mas os administradores de locatários têm a palavra final. Portanto, como desenvolvedor, você nem sempre sabe quando seu aplicativo requer o consentimento do administrador. É bom planejar e projetar em torno disso, mas lembre-se, quando você faz uma solicitação de token, ela pode ser negada por qualquer motivo. Em seu código, você precisa lidar normalmente com a não obtenção de um token porque os administradores de locatários nos quais seus clientes ou usuários estão executando seu aplicativo decidem quando as permissões exigem consentimento do administrador.
Exemplo usando JavaScript MSAL
Para a autenticação neste exemplo, você usa nossa Biblioteca de Autenticação da Microsoft JavaScript (MSAL) para entrar o usuário em um aplicativo de página única (SPA) onde toda a lógica do aplicativo é executada a partir do navegador.
No artigo de início rápido relacionado, você pode baixar e executar um exemplo de código. Ele demonstra como um aplicativo JavaScript de página única (SPA) pode entrar em usuários e chamar o Microsoft Graph usando o fluxo de código de autorização com PKCE (Proof Key for Code Exchange). O exemplo de código mostra como obter um token de acesso para chamar a API do Microsoft Graph ou qualquer API da Web.
Como mostrado no código de exemplo a seguir, você instancia um cliente público porque um aplicativo executado inteiramente no navegador deve ser um cliente público. O usuário pode colocar as mãos nos internos do seu aplicativo quando o código está no navegador.
// Create the main myMSALObj instance
// configuration parameters are located at authConfig.js
const myMSALObj = new msal.PublicClientApplication(msalConfig);
Então você usa nossa biblioteca MSAL. No MSAL JavaScript, há uma API específica para entrar. Há duas APIs que utilizam recursos específicos dentro do navegador. Uma delas é entrar com uma experiência pop-up; O outro é entrar com uma experiência de redirecionamento do navegador.
Como mostrado no exemplo de código a seguir, o pop-up de entrada manipula a autenticação que o usuário precisa executar chamando a signIn função.
function signIn() {
/**
* You can pass a custom request object. This overrides the initial configuration. For more information, visit:
* https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/request-response-object.md#request
*/
myMSALObj.loginPopup(loginRequest)
.then(handleResponse)
.catch(error => {
console.error(error);
});
}
Seu aplicativo pode obter informações sobre o usuário, como seu nome para exibição ou ID de usuário. Em seguida, seu aplicativo precisa de autorização para ler o perfil completo do usuário do Microsoft Graph seguindo um padrão que você usa em todas as nossas bibliotecas MSAL.
Como mostrado no código de exemplo abaixo, seu aplicativo tenta obter a autorização chamando AcquireTokenSilent. Se o Microsoft Entra ID puder emitir o token sem interagir com o usuário, retornará AcquireTokenSilent o token de que seu aplicativo precisa para acessar o Microsoft Graph em nome do usuário.
function getTokenPopup(request) {
/**
* See here for more info on account retrieval:
* https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-common/docs/Accounts.md
*/
request.account = myMSALObj.getAccountByUsername(username);
return myMSALObj.`AcquireTokenSilent`(request)
.catch(error => {
console.warn("silent token acquisition fails. acquiring token using popup");
if (error instanceof msal.InteractionRequiredAuthError) {
// fallback to interaction when silent call fails
return myMSALObj.`AcquireTokenPopup`(request)
.then(tokenResponse => {
console.log(tokenResponse);
return tokenResponse;
}).catch(error => {
console.error(error);
});
} else {
console.warn(error);
}
});
}
No entanto, muitas vezes o Microsoft Entra ID não pode emitir o token sem interagir com o usuário (por exemplo, o usuário alterou sua senha ou não concede consentimento). Portanto, AcquireTokenSilent envia um erro de volta para o aplicativo que requer interação do usuário. Quando a sua aplicação recebe o erro, volta a ligar AcquireTokenPopuppara .
Nesse ponto, o Microsoft Entra ID tem uma conversa com o usuário para que ele possa autenticar o usuário e autorizar seu aplicativo a agir em nome do usuário (por exemplo, fazer um MFA, fornecer sua senha, conceder consentimento). Em seguida, seu aplicativo recebe o token necessário para avançar.
Um passo principal na jornada de uma empresa para o Zero Trust é adotar métodos de autenticação mais fortes em vez de apenas um ID de usuário e senha. O código de exemplo anterior permite totalmente que uma empresa mude para o método de autenticação mais forte que a empresa escolher. Por exemplo, autenticação multifator, totalmente sem senha com uma chave FIDO2, Microsoft Authenticator.
Próximos passos
- Adquirir autorização para acessar recursos ajuda você a entender a melhor forma de garantir o Zero Trust ao adquirir permissões de acesso a recursos para seu aplicativo.
- Desenvolver a estratégia de permissões de aplicativo ajuda você a decidir sobre a abordagem de permissões de aplicativo para o gerenciamento de credenciais.
- Personalizar tokens descreve as informações que você pode receber nos tokens do Microsoft Entra. Ele explica como personalizar tokens para melhorar a flexibilidade e o controle e, ao mesmo tempo, aumentar a segurança de confiança zero do aplicativo com o menor privilégio.
- Configurar declarações de grupo e funções de aplicativo em tokens mostra como configurar seus aplicativos com definições de função de aplicativo e atribuir grupos de segurança a funções de aplicativo. Esses métodos ajudam a melhorar a flexibilidade e o controle e, ao mesmo tempo, aumentam a segurança de confiança zero do aplicativo com o menor privilégio.
- A Proteção de API descreve as práticas recomendadas para proteger sua API por meio de registro, definição de permissões e consentimento e imposição de acesso para atingir suas metas de Zero Trust.
- Chamar uma API de outra API ajuda você a garantir o Zero Trust quando você tem uma API que precisa chamar outra API e desenvolver seu aplicativo com segurança quando ele está trabalhando em nome de um usuário.
- As práticas recomendadas de autorização ajudam você a implementar os melhores modelos de autorização, permissão e consentimento para seus aplicativos.
- Use as práticas recomendadas de desenvolvimento de gerenciamento de acesso e identidade Zero Trust em seu ciclo de vida de desenvolvimento de aplicativos para criar aplicativos seguros.