I'm looking to create a custom role that allows someone to ONLY trigger an Azure Function (I guess they need sufficient permissions to be able to see it too), nothing else.
I've been looking at the list of actions here but I don't see anything that instantly jumps out at me as being the correct action.
Use case for this is to allow other people (and also programmatic users) in other subscriptions, permission to use an Azure Function as an action when creating an Action Group for alerts (eg Monitor or Application Insights).
RBAC roles cannot do this thing (allows someone to ONLY trigger an Azure Function) for you.
It is used to restrict a user (or service principal) to access the Azure resource. For example: microsoft.web/sites/functions/read role allows you to get Web Apps Functions. microsoft.web/sites/functions/write role allows you to update Web Apps Functions.
There is no a good option to meet your requirement. But for restricting users to use your function app (trigger Azure Function), you should consider configure the Authorization level and App Service Authentication.
Authorization level controls whether the function requires an API key and which key to use; Function uses a function key; Admin uses your master key. The function and master keys are found in the 'keys' management panel on the portal, when your function is selected. For user-based authentication, go to Function App Settings.
After you configure App Service Authentication, you will need an access token to trigger the function app. An Azure AD Authentication example for your reference.
In this way, you don't need to assign any RBAC role to the user.
Related
I'm adding an external identity provider, Azure multi-tenant, as a login option. I have local accounts right now and they know nothing about Azure AD users.
I want to create an Azure Enterprise App that other tenants can use to set up SSO using OpenID Connect. Also I want the app to support User Provisioning by setting up a SCIM API.
I can't really find any documents on how to handle linking Azure AD users with the existing accounts in my IDP. I've seen examples where users can login using their local account, authenticate with Azure, and then their local account is updated to have the Azure AD User ID. This approach still seems pretty manual. Another thought was to have a step in the login journey, where if no local account has the Azure AD User ID then find a local account with the same email. I don't like this approach either since the emails might not always match. Is there an approach where an admin can automatically link all accounts with a sync or upload?
SYSTEMS
First it's worth clarifying roles:
Role
Details
Authorization Server (AS)
Your UIs and APIs receive tokens from this. It is where accounts and linked accounts are stored. It is where you use SCIM to update account records. It is where you apply account linking logic.
Identity Provider (IDP)
There can be multiple of these. When your apps call the AS it manages connections to them, and exchanges IDP tokens for AS tokens that are returned to apps. It is not usual to use SCIM against an IDP.
You are using IdentityServer as the AS so your UIs and APIs will continue to use IdentityServer tokens and remain simple. Meanwhile Azure AD will become an alternative IDP. So on the data side of things your architecture is in a good place.
AUTHENTICATION ACTIONS
I would aim to solve your problems via custom authentication actions, and to design this in a vendor agnostic way. Not all providers support these concepts, but IdentityServer has some pretty good extensibility features, so hopefully it has what you need.
A bit of code, configuration and technical investigations in IdentityServer feel like the correct direction, with no complexity added to your applications. I will describe techniques in terms of Curity (where I work), but the same principles can apply to any system.
USERNAME AUTHENTICATOR
A great way to deal with user specific differences is to make the initial screen prompt only for an email. See this example for how that looks. Later, when authentication has completed, you could set a cookie so that this screen is not shown on subsequent logins.
Then, before asking for credentials, apply some scripted logic, eg to look up existing account attributes, and decide how the user should authenticate. You might decide to route unknown users to Azure AD or do something based on business partner email suffixes.
DATA UPDATES
Something simple that might work in advance of adding Azure AD support is to assign all users a Tenant ID, and perhaps existing users get a Tenant ID of 1. Only those users are allowed to sign in with Identity Server - all others have to use Azure AD.
SCRIPTED LOGIC AND ACCOUNT LINKING
For a worked example of how this looks, see this Account Linking with Facebook tutorial. In this example the objective is to update the main account with a new linked account. This account linking doc may give you some additional ideas for your scenario. It should be possible to run custom logic before triggering authentication or once your have the Azure IDP attributes.
INVOLVE THE USER IF NEEDED
It may also be useful to present a custom screen to ask the user if they have an existing account when they first login via Azure AD. If not then an Azure AD login can create the primary account in IdentityServer data in addition to a linked account.
USERS AND PARTNERS
How users onboard is interesting, and discussed in this detailed article. I always start by getting a feel for the type of assets involved:
Type
Description
Personal Assets
You allow any user to sign up and they only have access to their own assets
Corporate Assets
Users are provisioned by an administrator, eg a banker is granted access to financial data according to business rules
In your case it feels like users are from the second category, so to enable a user to fully sign up you need data from the partner, either fed in manually or by getting them to call your API, before you can assign the user the correct tenant ID. This might eventually result in TenantID=23, but there is nothing to stop you initially allowing users to onboard and placing them in a default TenantID=0 bucket.
Ultimately this all comes down to data, claims and API authorization. Eg APIs could return certain data to TenantID=0 users but only return privileged data to users whose tenant ID has been asserted by an administrator. Not sure if these thoughts of mine match your scenario but hopefully they provide a useful hint or two.
SUMMARY
Reliable account linking is tricky, but it should be solvable via the building blocks of the Authorization Server, using the above techniques. The end result should be deterministic user data, with no duplicate users.
TL;DR
How can I delegate my user permissions to a service principal in Azure Ad when the usual interactive way (e.g. web app with consent screen popup) is not feasible? This is because I cannot configure the MSI in the Azure Portal properly to work that way.
More detail
I want to grant an application permission to access the Graph API on behalf of a user. Usually, this is a well-documented scenario in which you create an app registration, acquire delegated user permissions by asking permission for the needed scopes, and then use these permissions in the app.
The app that needs Graph access is a background service that is to work on its own without user intervention/activity. For this use case, the common approach is to use application permissions. In my case this is not feasible, because application permissions require admin-consent and are all-or-nothing kind of permissions. There is no way this will be granted for me. Rightfully so, because its overkill.
But on the other hand that's really a pity. A pity, because I've found an example on how to assign Graph API application permissions directly to a Managed Service Identity rather than to a self-registered app. And my service (as an Azure Functions app) already has a MSI assigned to it. So this would be the perfect fit, b then again, there is no way I'll get those application permissions.
So what is the workaround? We have this one user principal which has all the required permissions we need for our background service. What I want to do is to delegate this user's permissions to the Function App/MSI. In order to do this, I used this SPA-template by the MSAL team to have something that will prompt me the permissions popup.
This however failed because the implicit oauth flow was not enabled. To remedy this, you usually need to update the app manifest in the portal. However, since this is a MANAGED service identity, and not a self-registered one, the MSI is not listed in the portal under app registrations. So I cannot set this property to true.
Doing the same via Azure CLI also failed because apparently the MSI is not identified as an app.
az ad app update --oauth2-allow-implicit-flow true --id <appId_of_MSI>
This yields the following error:
ResourceNotFoundError: Resource '<appId_of_MSI>' does not exist or one of its queried reference-property objects are not present.
It shows fine when doing this
az ad sp show --id <appId_of_MSI>
So in summary: I cannot complete the process of delegating that user's permissions interactively. Is there any other way? Maybe via CLI?
The fallback the solution is to create a separate unmanaged/self-registered app identity. But I want to really avoid this because then I would need to manage and rotate client (app) credentials again, which the MSI took care of for me.
Why o why can't I just assign fine-scoped application permissions 😒
Any help on this is greatly appreciated. Cheers.
In my experience Managed Identities don't support the scenario you are suggesting.
They do not have an app registration and in that way cannot authenticate users interactively.
I would go with your fallback solution; a normal app registration and use that to access Graph API on behalf of the user.
This is what we do in our projects at least.
App permissions -> Managed Identity if possible. Delegated permissions -> normal app registration + secret/certificate in Key Vault, retrieved with Managed Identity.
I am trying to set up an authenticated webhook call from an Azure Event Grid Domain subscription to a web app service in the same tenant. I am able to do everything up to a certain point which is that I am trying to tie the authentication to a specific app role in the subscribing app. Currently, the authentication works, but I cannot seem to figure out how to include a specific role in the token that gets sent to the subscribing endpoint. It may be that it's more of a generic question on setting up an enterprise app registration (which event grid uses) with a configurable role for app registrations. My issue is that I know how to do it when there's an app registration, but in this case I only have an enterprise app.
I have followed the documentation, and this article seems to try to do the same thing, but I don't want to do it in powershell as we have an Identity-responsible who is going to do the actual work as well as me wanting to understand what happens behind the scenes.
https://learn.microsoft.com/en-us/azure/event-grid/secure-webhook-delivery
Does anybody know how to set up the event grid webhook authentication so it includes a specific role (most probably an app role defined in the manifest of the subscribing app's app registration)?
You are following correct way of configuring event subscription.
The role which you wants to add in application can be done as below -
Azure Portal>>All Services>>Subscription>>Select Subscription>>IAM Role>>Add Role assignment>>1.Select the role which he need 2. Assign access to Azure AD user or Service Principal 3. Select the application >> Save.
or
If need to assign some customise role you can create the custom role as below -
https://learn.microsoft.com/bs-cyrl-ba/azure/role-based-access-control/custom-roles?toc=%2Fazure%2Fvirtual-network%2Ftoc.json
Azure Active Directory to secure the connection between your Event Subscription and your webhook endpoint.
https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/event-grid/secure-webhook-delivery.md
I am doing login from Azure AD.Client is SPA(angular using MSAL). If user is not Authenticated, it redirect to Microsoft Login Screen (using MSAL). On successful login, it return an access token.
My roles will be stored in a database. I need to add the roles of that user as part of claim in access token. I am not finding the way to do it.
I do not want to make another call from SPA to API to get the DB roles.
Please suggest some good approach.
Any links explaining the approach will also be very helpful.
I am still in design phase but not able to find the best approach.
In one microsoft site, i found that we can fetch the roles from DB but details were not there.
most of the places, it is written that we need to provide roles in Azure AD users menifest file.
In regular Azure AD, the "roles" claim is exclusively sourced from app role assignments for the signed-in user (or groups the user is a member of), to the app roles for the app the user is signing in to.
There's no feature currently in Azure AD which will connect to an arbitrary database, make a database query in the appropriate form, and include the results in the roles claim in the resulting ID Token.
I can think of three options to achieve your scenario:
After sign-in, call an API to retrieve the roles. Though you mention this is not desirable, it's probably the simplest approach, so it's worth listing. As a result of the user's sign-to you app, you app will usually obtain an access token to an API. If you set up your API to be secured with Azure AD (directly, or through Azure API Management), your SPA could simply get the necessary access token as part of sign-in, and at that point it's trivial to make a REST call to retrieve the role details for the user (and possibly other information useful to rendering your app).
Synchronize (or copy) your role information from your database to Azure AD. For each role, create an app role in the Azure AD app registration. For each user-role association, either create an app role assignment to directly assign the user (user -> app role), or assign a group to the app role and add the user to the group (user -> group -> app role. Keeping this in sync is probably not trivial, so if your scenario allow to move the role information to Azure AD app role assignment, you can forget the database entirely (making Azure AD the authoritative location). Of course, this might not work for your specific case.
Use Azure AD B2C and a custom sign-in policy. You could create an Azure AD B2C tenant, set up a custom sign-in policy to use your (regular) Azure AD tenant as the identity provider, and configure the policy to enhance the claims by calling a REST API to retrieve your roles. In this approach, you still need to have a REST API which can provide the role information, so rather than doing the setup and migrating your app, you may prefer simply calling the API from your SPA (option 1, in this list).
I have a UWP app that uses WebAccountManager for AAD authentication. I also have a service, hosted in Azure, used by the UWP app. That service uses the token the UWP app sends to get another on-behalf-of token (I think that's what it's called) to then call other service APIs as the user (e.g. Microsoft Graph and Outlook REST API). In other words, UWP app calls WebAuthenticationCoreManager.RequestTokenAsync to get a token, sends it to my service, my service calls AuthenticationContext.AcquireTokenAsync to get an on-behalf-of token to use when calling the Outlook REST API, for example.
In the AAD registration for my service, the "Required Permissions" list all the services and permissions/API calls it might make on behalf of the user (E.g. "Microsoft Graph"-> "Have full access to user calendars")
When my UWP app creates the WebTokenRequest to pass into the RequestTokenAsync function, it currently passes an empty string as the value for "scope." What should it be passing for the scope parameter? Should it be passing the full and exact list of permissions that the service declares are required? If so, how do I get that permission list to the client? Just hard-code and update the list whenever the service required permissions list changes?
In Azure Active Directory, there are two fundamentally different ways to specify the permissions your app requires when authenticating.
Static Consent
Dynamic Consent
Back in the Azure Active Directory V1 endpoint, you would set "Required Permissions" to other APIs when registering your client application. This is setting up Static Consent. These permissions are fixed, and when you trigger the user to consent to these permissions, the user has to consent to them all at once. Additionally, if at some point your app wants to add new permissions to other APIs, you will need to force the user to go through the full consent experience again, which may even require special logic on your application.
This is why in the V2 endpoint, Microsoft developed Incremental and dynamic consent.
With the v2.0 endpoint, you can specify the permissions your app needs dynamically, at runtime, during regular usage of your app. To do so, you can specify the scopes your app needs at any given point in time by including them in the scope parameter of an authorization request.
Here, you can specify only the permissions your app needs to complete the flows it is trying to accomplish at that time. If you need more access, you can simply add it during your authentication experience, and it will prompt the user only for those new permissions.
Now let's return to your question. If you are using the V2 endpoint, you should be using Dynamic Consent, which means that the settings in "Required Permissions" do not really matter to you. You should be keeping the list of scopes your app requires in your app settings.
Some situations in the V2 endpoint still require Static Consent, like service to service calls with direct application permissions. For those situations you would pass the scope <resource>/.default as noted here. This might also work for delegated tokens, but it is better to just use Dynamic Consent.