I'm developing a tool, similar to Visual Studio's Cloud Explorer, that performs a limited set of management and deployment tasks inside a user's Azure subscription.
I'm thrown-off by a few things relating to authenticating against Azure and how the application represents itself to Azure.
Most of the documentation about authentication with Azure is concerned with web-applications that let users authenticate themselves against an Azure Active Directory. This is not my scenario. While me application necessarily authenticates users against Azure AD (as all Azure users are), my users are administrators, not "users".
I understand previously software that performed administration tasks would be assigned a Management Certificate which is separately-registered in the web-based Azure Management Portal. I understand this fine.
...however I also understand that Management Certificates are almost deprecated and are replaced with Service Principals, which itself makes more sense from a security perspective (as it enables more granular role-based security) - however the downside is that there are a lot of manual steps and hoops to jump through in order to enable the use of Service Principals with administration software - in particular you need to pre-register your application in Azure Portal.
I don't like this because it greatly increases user-friction with the software I'm writing. I want my software to behave like the Visual Studio Cloud Explorer or Azure PowerShell in that you don't need to pre-register anything: 1. just run the program on your desktop; 2. you'll get a prompt to sign-in with your Azure administrator account credentials. 3. my softwware lists the contents of your subscriptions and lets you perform your management tasks.
So far I have actually got something that does this - I perform the following steps:
Use Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext to authenticate against https://login.microsoftonline.com/common (using AcquireTokenAsync which presents the webview to login). I use clientId: "1950a258-227b-4e31-a9cf-717495945fc2" which is the Azure PowerShell clientId.
Use the token from step 1 to enumerate Tenants and Subscriptions in the user's account.
The user is prompted to select a tenant and then a subscription from the list downloaded in step 2.
Send a new authentication request to https://login.microsoft.com/{tenantId} (where {tenantId} is retrieved from step 3), again using the same clientId.
However I don't like impersonating Azure PowerShell - Microsoft could revoke that clientId.
...but how do I register a clientId that can be used to login in step 1 (when there's no tenantId or subscription context, thus no Azure AD which contains Service Principals)?
I don't like this because it greatly increases user-friction with the software I'm writing. I want my software to behave like the Visual Studio Cloud Explorer or Azure PowerShell in that you don't need to pre-register anything: 1. just run the program on your desktop; 2. you'll get a prompt to sign-in with your Azure administrator account credentials. 3. my softwware lists the contents of your subscriptions and lets you perform your management tasks.
Actually, the Visual Studio Cloud Explorer also register the app on the Azure AD and use the Service Management REST to manage the Azure subscription. And you can caputer the request using the Fiddler when you add account to the Cloud Explorer.
...but how do I register a clientId that can be used to login in step 1 (when there's no tenantId or subscription context, thus no Azure AD which contains Service Principals)?
We need to develope a multi-tenant application which enables the users from different tenant to use the application. After that we can use the Common endpoint instead of the specific tenant id you register the app. Then users login-in with their account which associate with Azure subscription and get the access token for the Service Management REST. At last the applicaiton can manage the Azure resource with the access token. For example, we can use the REST below to list the Azure Sbuscriptions:
Get:https://management.core.windows.net/subscriptions
Authorization: Bearer {token}
x-ms-version: 2013-08-01
And more detail about the authenticating Service Management requests, you can refer here.
Related
I have a rather (hopefully) theoretical question regarding the secure usage of Service Pricipals in Azure (Enterprise Applications)
Introduction
we currently deploy our DevOps Code via Azure Service Principals.
AppRegistration/Enterprise App is created
Secret is generated
Permission (i.e. Contributor) to the Ressource Group is granted in Azure
Service Connection is made in Devops
everything works fine.
Assumption
By default the Service Principal (Enterprise Application) is not restricted to a specific user/group (Assignment Required => "no").
My assumption is now, that every user in the AAD-Tenant is able to login to the Enterprise Application as well.
I i.e. do this by using the "Graph Powershell API"-EnterpriseApp.
I can either use a Secret or use my User Credentials to access the Service Principal and its permissions
Security issue?
coming back to our DevOps configuration:
The Service Principal has Contributor Permission on the dedicated Resource Group
Assignment Required is set to no (default configuration)
if I (as a malicious user) have the Application ID, i could simply logon to the Service Principal and receive the Token.
Question:
With this token and my login to the App, do i also have the Contributor Permissions of the App and could now manipulate the whole Resource Group?
Since i'm not an Azure Developer - but only an Azure AD Admin - my knowledge regarding this is limited,
so i'm not able to test it.
Can someone maybe either provide code or prove that my assumptions are wrong or correct?!
Thanks
Yes, the SPN can manage the resources within the resource group if it has Contributor - it is no different than a normal (human) identity.
Consider if the SPN actually needs Contributor or if you can limit it with another role or even make a custom role.
Furthermore, monitor the sign-ins using the Azure AD sign-in logs:
https://learn.microsoft.com/en-us/azure/active-directory/reports-monitoring/concept-all-sign-ins
You can also use CanNotDelete resource lock, which means that the service principal cannot delete resource as it is only Contributor:
https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources?tabs=json
You might want to look into the Conditional Access to strengthen your environment:
https://learn.microsoft.com/en-us/azure/active-directory/develop/workload-identities-overview
https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/workload-identity
https://learn.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-create-azure-ad-roles-and-resource-roles-review
Take a look here:
https://infosecwriteups.com/a-lab-for-practicing-azure-service-principal-abuse-bd000e6c48eb
https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/disable-user-sign-in-portal
https://learn.microsoft.com/en-us/powershell/module/az.accounts/connect-azaccount?view=azps-9.3.0#example-3-connect-to-azure-using-a-service-principal-account
My assumption is now, that every user in the AAD-Tenant is able to login to the Enterprise Application as well.
No. They would need the client secret or the rights to generate a new one. Which requires that they are owners of the App Registration. In the App Registration on the Owners tab it says:
The users listed here can view and edit this application registration. Additionally, any user (may not be listed here) with administrative privileges to manage any application (e.g., Global Administrator, Cloud App Administrator etc.) can view and edit the application registrations.
We have written some code (I hesitate to use the term "application") in .NET Core using Visual Studio 2019. This concept is relatively simple; when a user opens a "proprietary" Excel workbook (an Excel file that calls our code) the code goes out to a hosted (by us) Azure SQL Managed database and returns data based on the parameters passed in by the user.
In Azure, we have a single production App Service plan with an App Service dedicated to each client (company). My question is about security: I'd like to tie each App Service to the related company's Azure AD. I do NOT want to create an account on my Azure AD for each user, although I can certainly do this through the "invitation" process using B2B. Can each App Service be "pointed" to a specific external instance of Azure AD so that only users from that company can access the related data?
Thanks.
You may use two different flows:
Each WebApp will authenticate users from only one specific Azure AD tenant
One WebApp will authenticate users from multiple Azure AD tenants
Both solution can be achieved with Azure AD multi-tenant authentication application pattern.
Here are steps you need to implement:
Update App registration to be multi-tenant
Update your code to send requests to /common
Update your code to handle multiple/single issuer values
Here is a picture that describes the flow
https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-convert-app-to-be-multi-tenant
I have developed a domain-based modeling tool and code-generator that provides the ability to capture domain models per DDD and automatically generates ASP.Net Web API microservices.
I also created an Azure B2C CLI tool that uses MS Graph API to programmatically generate an Azure B2C AD Application for each Web ASP.NET Web API of which includes all possible scopes that are applied to protect some of the generated Web API operations.
As some of these generated API services often interact with other generated services via REST and/or gRPC, the Azure B2C CLI tool also adds the list of dependent API permissions that would be required by each Web API in order to integrate with the other Web API.
My Azure B2C CLI tool works great and is creating/updating the underlying Azure B2C Web/API application per each domain service within the Home Tenant along with the necessary Service Principal.
Currently I still need to log into the Azure Portal in order to grant the API permissions per each B2C Application.
My Question is : Is it possible to automate the granting of the API Permissions using the B2C Application that I am using to create these same B2C Web/API applications ?
It seems like this should be possible as the Azure B2C CLI tool's B2C Application is the owner of these created Apps.
To help illustrate and support my question I have included some screen shots below.
To begin, the following image shows the permission set that my Azure B2C CLI tool runs under in order to create the other B2C applications for each Web API via MS Graph API.
On each pass, the Azure B2C CLI tool processes a particular domain model to understand the definition for each domain service within that model and will automatically create a series of B2C applications within Azure B2C per each service in a particular domain model.
The following domain model has 4 domain services which results with 4 B2C Apps being generated by my Azure B2C CLI tool as illustrated below ..
The Azure B2C CLI tool creates as many permission scope items per API operation and adds that to the underlying API OAuthPermissionScopes. Here is a few examples of generated permission scopes services for "WorkSpace" and "SharedServices" Web API's...
The Azure B2C CLI also adds any API permissions to each generated B2C API Application. The following example shows that "CoreServices" API requires permissions from both the "SharedServices" App API and the "WorkSpace" App API
Once that is completed I can log into the Azure Portal and Grant these permissions, manually, per each API.
Instead of granting these manually I would like to programmatically grant these permissions via MS Graph within the Azure B2C CLI tool I've created.
The code-generator domain modeling tool will be producing 100's upon 100's of services so I want to automate securing the generated domain services as much as possible, including granting of API permissions.
What is the MS Graph API to allow me to fully automate this process within my Azure B2C CLI tool?
Microsoft Graph doesn't support the "grant admin consent" feature currently.
AAD Graph has an endpoint https://graph.windows.net/myorganization/consentToApp?api-version=2.0 which is used to grant admin consent but it is only available within Microsoft. Calling this endpoint from outside will get this error.
You could consider using Azure CLI cmd az ad app permission grant or az ad app permission admin-consent --id $appid. See reference here.
There is a difference between the 2 cmds. You can find more details from my previous answer.
This isn't a specific problem question but a "cry for help".
My problem is this. Our organization is in the process of implementing Office365.
Until now there were tens of applications with their own authentication and authorization but in the process most of them will be rewritten to use within O365 environment.
We are facing the problem of creating one endpoint (ASP.NET WebAPI app) which will be used to authenticate a user with his credentials from Active Directory (or B2B AD on Azure because some apps are used outside) and tell if this user is allowed to use app that asked to log him.
I'm just wondering through documentations and sample code but can't decide what will be a good practice in this scenario. Should we just build each app and use Azure Active Directory provider to authenticate. Or is it possible to setup ONE api that will hold all apps Ids and its userIds - then it will check user credentials against AD and give app token/cookie...
My best bet is to try this: http://www.tugberkugurlu.com/archive/simple-oauth-server-implementing-a-simple-oauth-server-with-katana-oauth-authorization-server-components-part-1
But create Provider for AzureAD. But then its still question about this B2B AD part.
Please help by pointing to some up to date resources..
You should register each of your B2B application within your Azure Active Directory and configure them to use AAD as the Identity Provider.
Then you can administrate everything you want (e. g. which user has access to which application) within the Azure Active Directory blade from the Azure Portal.
You are getting this backwards. If you have apps integrated with Azure AD you don't have to create endpoint which will validate users right to use apps but you are assigning right to use an app in Azure AD. This is whole point.
Is it possible to enable multi-factor authentication for getting access to the Azure portal, https://portal.azure.com?
I know there is an MFA server resource in Azure itself, but my understanding is that this is for Azure hosted applications/resources. I initially want to enable MFA for getting access to the portal itself, before setting it up for the different resources themselves in Azure.
Yes, you can.
For example here they say
Add protection for Azure administrator accounts
Multi-Factor Authentication adds a layer of security to your Azure administrator account at no additional cost. When turned on, you need to confirm your identity to spin up a virtual machine, manage storage, or use other Azure services.
Here is one of step-by-step guides.
UPD Feb 2019
Azure is constantly evolving, so many answers and related articles quickly become outdated.
As it is now, MFA is not a free option. I would start reading this Microsoft page for details, in particular:
Multi-Factor Authentication comes as part of the following offerings:
Azure Active Directory Premium licenses
Azure MFA Service (Cloud)
Azure MFA Server
Multi-Factor Authentication for Office 365
Azure Active Directory Global Administrators
EDIT:
The feature I originally mentioned has been replaced by Security Defaults, which includes requiring that all users register for MFA (but non-admin users don't necessarily have to use it), and requires admin users to use MFA.
https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-security-defaults
Old response:
There is currently a feature in preview offering a baseline policy to apply MFA to the Azure Portal (and PowerShell and CLI).
https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/concept-baseline-protection#require-mfa-for-service-management-preview
This is applicable even at the free level of AAD.