I have a client who told me they have Azure. Fine, I built a Logic App and am ready to deploy. The link they gave me is www.add.portal.azure.com
I see all the users who will use my Logic App. I also see a place to register apps. Instinct tells me I should:
1) Deploy the Logic App to the client Azure portal
2) Register the Logic App in client ADD Azure portal
3) Done!
Devil is in the details and I'm newer-ish to Azure....
Is it valid to assume the client has an Azure subscription which supports my Logic App? I don't know if someone can buy just the ADD.azure.portal.com and not have azure.portal.com
What cost am I asking the client to assume by creating the Logic App if any?
There ADD is full of users. Right now I will have the users authenticate by typing in their email. But I assume there is a Logic App control for add authentication?
Thank you for your patience with a newbie
As far as I know, you can't deploy the logic app just by the link provided from the client. This link is just for Azure Active Directory, if you want to deploy the logic app, you need to ask the client to add you as a user in their azure active directory and assign a role to you(at least "Contributor") in their azure subscription.
Then you can login the client azure portal and deploy your logic app by ARM template in their azure portal, and you can also register the logic app by enable the "Identity" under the "Settings" tab in your logic app.(the screenshot shown as below)
By the way, I'm not sure if I understand your requirements correctly. So if the solution doesn't match your requirements, please provide more details of your question, I will try to help you further. If the answer helps your problem, could you please mark my answer as "accepted", thanks in advance~
Related
I'm new to Azure AD and I'm trying to create an app (that I'm developing) and setup an automated user provisioning (SCIM).
The first thing I need to do is to create an application, so I go the App registration in the Azure AD portal and create one. It's a multi-tent application.
After that I navigated to the Authentication menu and added a Mobile and Desktop configuration only. A Service principal is automatically created in the Enterprise applications menu.
When I go the Provisioning menu that is supposed to allow me to configure the automated user provisioning I get this:
"Out of the box automatic provisioning to AppName is not supported today. Ensure that AppName supports the SCIM standard for provisioning and request support for the application as described here. To determine if the application suports SCIM, please contact the application developer."
Does anyone knows why this is happening? Is it because I've added only a Desktop and Mobile platform configuration? I can't find any good explanation and I can't figure out how to make it work and what I'm supposed to do to make it work.
How am i supposed to make the automatic user provisioning work on my own application?
Thanks!
Provisioning is a feature for Enterprise Applications, which are slightly different in nature from (and have some overlap with) App Registrations. Create an Enterprise Application - a custom/non-gallery app is fine - and you'll be able to enable provisioning on that.
I have been looking at this issue for days and I know from experience that I usually work these things out but this time I have hit a brick wall.
Scenario
I have a python app that gets instantiated inside an Azure DevOps YAML pipeline.
The app calls the Azure DevOps REST API to create a repository
The app uses a PAT (personal access token) to authenticate
Firstly issue is, a personal access token is connected to me as a human user. If I leave the company the PAT will be revoked which is not good for an app that needs to run in a non-user context.
So now I want to setup my Python app to authenticate to the Azure DevOps REST API using client credentials flow.
My issue is, I can't find consistent information about this.
I have created an app in Azure DevOps:
My plan would be to get this all working in Postman and then port my finding to Python code.
So really, I am looking for help with the setup I do in Postman and I can work the rest out myself in Python.
Many posts talk about Azure DevOps and Azure AAD (Azure Active Directory) together but, seeing as I create my app registration in Azure DevOps, as shown in the picture, I don't see why I would do anything in AAD.
(Note, my Azure DevOps instance was created outside Azure. Azure knows nothing about my Azure DevOps instance)
Any pointers to the CORRECT information about how to do this would be good. And remember, I definitely need the client credentials type flow. There is no human interaction between my app and the Azure DevOps REST API.
Update
Here is what I have in Postman right now:
Note:
You can see the check boxes which I am using to toggle application/x-www-form-urlencoded key / value pairs on and off
the resource - 499b84ac-1321-427f-aa17-267ca6975798 is apparently the GUID for Azure DevOps and doesn't change
If I look inside the HTML from the 500 error I see this: Could not find partition for hostId: 499b84ac-1321-427f-aa17-267ca6975798 which is the DevOps resource GUID mentioned above.
And here is the 500 error I get from Azure Devops:
It's all very confusing but I am sure I just need to tweak one or two things to get it working.
I want to use client_credential flow in Azure DevOps for the same reasons as you! Last time I spoke to support they told me it was planned for Q3 2020. Reviewing the roadmap I can't see it on there at the moment. I also couldn't see any feature requests currently raised on Dev Community so you could consider trying to raise the profile of this issue on there.
I have two applications:
MVC Site (User-facing Web App secured via OAuth -> Google)
Web API Site ("Private" Web Services)
These are hosted in an App Service Plan in Azure. These web services will only be consumed by my own applications - I don't need to worry about outside consumption. In fact, I specifically don't want outside consumption. My Web App is using OAuth to Google - that shouldn't matter here.
So to get to the heart of my question: My web services currently have no authentication/authorization model in the code but I don't want it just publicly available to anybody. On prem, we just lock this down via IIS using Windows Auth and set the service account for the consuming web app to run as a user that Windows Auth allows access to. I'd like to do the equivalent in Azure.
I understand Azure isn't exactly the same but I have to believe this is possible. I have even gotten my web services locked down the way I want using the settings in the Authentication/Authorization tab (I can try to navigate to it but I only get my Swagger UI once I login with a valid organizational account). So half of my battle is solved but I cannot figure out how to do the other half - the equivalent of setting the service account for my consuming MVC application to run as.
Can I do this via the portal without having to code specifically to this scenario? I'd really like a PaaS-level or IaaS-level solution for the security portion of consuming the above locked-down services. I'm also open to other avenues if I'm going down the wrong path in having a PaaS or IaaS security solution to this problem. I'm not against making code changes - we did have a one-liner in our RestSharp code to engage Windows Authentication, but the bulk of the work/configuration was outside of code and that's what I'm going for here.
If going the IaaS path you can host the application inside of an VM in the exact same way as you did before when running it directly on-top of IIS. The benefit is that you can get running the same way as before but you will still need to manage the VM; i.e install updates and take care of its security.
However, if you want to have a PaaS solution, then you need to modify the code of your front-end application to pass on the authentication token to the back-end API, assuming the back-end accepts the same authentication as the front-end. See https://azure.microsoft.com/en-us/documentation/articles/app-service-api-dotnet-get-started/ as an example on how to pass on authentication information from one app to another.
Alternatively you can use the app identity to make calls to your back-end API. This way the calls are not related to any user but are instead done in the context of the app. See https://github.com/Azure-Samples/active-directory-dotnet-daemon for more details on how to set it up, both configuration and needed code.
If you want to allow your users to sign-in using their Google accounts then you could handle authorization to your API using the app identity (second alternative above), assuming the API is independent of the requesting users identity.
Enabling authentication for a Azure Web App directly through the menus in the Azure Portal adds Azure AD authentication in-front of your application and require your to pass an access token generated by Azure AD to your API for it to work.
I'm in the process of evaluating App Service and in particular Api apps and logic apps. I want to be able to make use of git deploy for an Api app instance.
This article https://azure.microsoft.com/en-gb/documentation/articles/web-sites-publish-source-control/ mentions that even though it is based on web apps, you can apply the same processes to api apps, however, when I attempted to follow the tutorial using an api app instance, I was unable to see the "deployment" tile on the api app blade in the azure portal. I was able to complete the tutorial for the web app instance.
Does anyone know why I wouldn't be able to see the deployment tile for an api app blade?
I want to use the api app so I can make full use of swagger and the logic app service.
Edit
Thinking about it, do I even need to use an api app or could I get away with using a web app (with swagger meta data) for connecting to logic apps?
Update
Found it - see my own answer.
OK, I found it and it's not a bug. I was being (a bit) dumb. Following this article, I discovered that I needed to click on the Api app host section and then all settings then continuous deployment.
This is, imho, a poor UX decision here, given the blade looks exactly the same as others that do have the deployment tile, but at least I can set up git deploy for my api apps now.
#Simon
This may be a bug - I will poke the Azure Team for it asking that. Even though, WebApp, APIApp and MobileApp are EXACTLY the same service, only changing name. So, if you can see deployment tile for one of them, you should be able to see all others then.
BUT, there is a "invisible business link" around them that make all things working. When you work with Logic Apps, it will search for custom API Apps at - guess what! - you API App list. So, you can host a API application at WebApp, but probably the Logic App will not go for it by default.
Even though I've added apps from gallery to Azure AD, I cannot see when I try to pull the data. But I can see the custom apps added. Like if I've added 7 apps; 2 from gallery(Google Docs, One drive) & 5 custom(native/web apps); I am able to see only 5 apps! Am I going wrong any where?
The Graph API that am using is:
https://graph.windows.net/mycustomad.onmicrosoft.com/applications?api-version=beta
I tried with different api versions but no luck.
Can someone suggest me on this?
In graph API, "applications" represent application configuration that developers register in their tenant. Gallery apps are no different (and happen to be registered in a special tenant). When you acquire an application (like a gallery app, or consent to a custom application someone else has developed), an application instance gets created in your tenant so that we can attach policy and permissions to it. This application instance is called a "service principal".
You can query for this using:
https://graph.windows.net/mycustomad.onmicrosoft.com/servicePrincipals?api-version=1.5
This will return ALL acquired apps, and some default Microsoft apps.
Hope this explains why your query of the application entity shows only the custom apps you've registered in your tenant.
Hope this helps