Is it possible to run a logic app or connector as a service principal, in particular under the consumption plan?
I'd guess forcing the app to run in a non-consumption plan via powershell might give more control over the service principal.
The reason I'd want it to avoid an individual's account to be used during an automated deployment.
The closest I thought was to wrangle https://github.com/logicappsio/LogicAppConnectionAuth to do the oauth automagically using a service principal, however trying similar things for data factory connections proved unfruitful and very time consuming, so I'd rather find out sooner than later if I'm barking up the wrong tree.
API Connections with OAuth authentication, like Office 365 and Microsoft Team connectors, require manual consent. Unfortunately, at this point in time, authentication for those cannot be fully automated.
As you mentioned, this script https://github.com/logicappsio/LogicAppConnectionAuth will avoid some user clicks when authenticating the connectors, but at the end is going to be a manual step.
HTH
Related
I understand that App Registration represents an app that might have UI for users to login.
I understand that a Service Principal is for applications like scheduled batch processing applications.
But from the technical perspective, in Azure Portal App Registration list, I can see both of them in the list and look the same.
Is there anything that an SP can do that an App Registration cannot or vice versa?
It is very confusing! And unfortunately the link juunas pointed to is not only confusing, it contains bad information! To further demonstrate how confusing it is, answers you have received here are also not exactly correct! It's a real mess, and Microsoft is not doing a great job bringing clarity to the subject.
AlfredoRevilla got really close. Unfortunately, he pointed to the same bad documentation as well, which does not add much clarity to the subject.
To start, an Enterprise Application is not a service principal. This can be easily demonstrated by creating a SP using CLI (az ad sp create). After creating a Service Principal this way, you will see the corresponding App Registration...but no "Enterprise Application" will appear. Again, to make things confusing, Microsoft decided to tack-on the ability to view Service Principals not associated with an application object in the Enterprise Apps blade. This is done by using the drop-down to display the misnomered "Application Types" (not to digress too much here, but "Application Type == Managed Identity" is a clear example of how poorly this drop-down is named). More on this later.
So, to your question. Yes! There is something App Registrations can do that SP's can't do, and vice versa. They are actually different object types, just object types that look and seem to be used the same (now that isn't confusing at all, is it??? Way to go Microsoft.)
Unfortunately, I'm going to end up giving an answer that also is not quite satisfying from a technical perspective. I do this only in attempt to make some sort of sensical answer to a very confusing situation...and to avoid digressing into things like multitenancy applications and redirect URLs.
A Service Principal is the identity object in Azure Active Directory that allows roles to be assigned to various objects (resources). Thus the SP can be assigned as a Storage Blob Data Reader, or as a Key Vault Secrets User. Notice how I intentionally avoided using a web API as an example there? I did that on purpose, because Microsoft only wants to talk about this subject in context of API's and applications...bringing little clarity to the subject for non-API use cases. A key concept here is that a Service Principal will be created in your AAD whenever you create an App Registration or register an existing Application object (say from the marketplace or another tenant).
Creating an App Registration is going to essentially define the application itself. It is the view into the Application object. The Registration instantiates the application, defines who can access it (single tenant/multi-tenant), and defines various elements needed for token exchange, branding elements, etc.
But what about that "Enterprise Application" thing? What is it, and why is it tightly tied to the subject of Service Principals? You will find information that mistakenly implies an Enterprise Application is exactly the same as a Service Principal / is a Service Principal. But as pointed out above, a little experimentation in Azure quickly reveals this is not quite the case. Fortunately, it is easy to sort this part out by recognizing there is no such thing as an "Enterprise Application" Azure! Seriously, they do not exist. Microsoft created a blade in the Azure Portal that they named "Enterprise Applications" -- very poor name choice. What this blade does is provide a view to the Service Principal objects in Azure (be it a Service Principal for an Application object, or a Managed Identity Service Principal). That's it! So when you see that "Enterprise Applications" blade, just think "Service Principal identities" and don't get fooled into thinking there is another piece of this puzzle to figure out.
The App registration is the template used to create the SP. The SP is a security principal (like a User) which can be authenticated and authorized. Follow juunas link, specially Relationship between application objects and service principals.
The App Registrations view shows Azure AD Applications, which are identified by its Application ID, while Enterprise Applications view displays Service Principals. You can navigate from the Application to its associated Service Principal using the link labeled with Managed application in local directory in the Application Overview.
Application and Service Principal are associated by the Application ID. Often they have the same name, but they differ in its Object ID.
Please check the mentioned documentation for the purpose of Applications and Service Principals.
I have a standalone web application (not an add-in) and I would like to access Project Server PWA oData from this web application without using the PWA username/password combination.
I can do this for SharePoint oData by registering my web app in Azure AD and configuring the application to require "Read" permissions from "Office 365 SharePoint Online"
If you are interested to do this for SharePoint data, see this article for details: https://www.itunity.com/article/integrating-angularjs-aad-office-365sharepoint-part-1-622
My problem is that I want to do the same for a Project Server, but can't see any relevant Project Online permission in Azure AD.
Has any one ever accessed Project Online using Azure AD tokens?
My 10 Minutes of Internet Research™ leads me to believe this isn't available but that it was a planned feature at one point. [see here]
Without knowing much (anything) about Project Server, this seems like a situation I've dealt with on AWS at work. We have a bunch of endpoints that are secured using IAM (AWS) credentials and we can't leave those creds lying around in our app (because that would be silly). Our solution is to generate access URLs server-side and hand them out, these typically will have a time limit and be restricted to a very specific action.
A quick search for Azure's equivalent to IAM tells me that you might be able to do something similar though I'm unsure it exists for Project Server.
That failing, you could always set up an intermediary micro-service that acts as proxy and has the username/password combo. We do stuff like this all the time with Lambda (AWS's serverless functions).
I'm working on a project with Google App Engine. I am using continuous integration via Travis, and wish to be able to deploy directly from it. Due to a bug that will not be resolved directly, I can't rely on Travis' built-in GAE deployment, so I basically have to use mvn appengine:update manually. This requires me navigate to a generated URL and manually paste to the terminal an authentication code, which I can't do in automated builds.
It was suggested to me, however, that I do some Unix magic instead. While I can easily pick out the URL I need to navigate to from grep, I still need to log in to Google with my credentials in order to actually get the authentication code (which I can then grep out and pipe to the deployment program).
Given that, how do I log in to Google with my credentials, using only curl or similar command-line utilities?
I've accomplished similar things in the past using Service Accounts. These are likely a good fit for your problem.
Service Accounts will allow you to authenticate and upload your app without manual intervention.
Overview
A Service Account will allow you to do "passwordless" authentication like you may already do with ssh, and git, etc. by setting up your keys. This will remove the requirement that you log in manually, or follow the road to madness by trying to do a "manual" login automatically.
There are basically two steps:
Create your service account and key (with the right permissions)
Use that credential instead of what you're doing now
Resources
I think it's better to give a list of resources than concrete instructions since it's basically impossible to express concisely (even though it's a simple process, there's bound to be a lot of little things that annoy), everyone's requirements will be slightly different, and Google is likely to change the process at some point.
Using the Google Cloud Platform Console for App Engine | Permissions
Using OAuth 2.0 for Server to Server Applications
Setting up OAuth 2.0 | Service Accounts
gcloud auth activate-service-account
Hopefully that's enough to get you headed in the right direction.
Note
You'll likely have to spend some time looking at your .appcfg_oauth2_tokens_java and sorting out a variety of other annoyances, but I believe that this approach is the best way to solve your problem.
It sounds like you have a pretty straight-forward setup and that a Service Account alone will get you there, but if you need to get a little weird, the App Engine Admin API is always there.
I've created a website within the company that utilizes our active directory server to authenticate. I am concerned about security surrounding setting up relying parties with "localhost" domains.
I've pretty much followed this guide on setup. You'll notice about halfway down the page, there is a step to set up the development environment, localhost:44336 as a relying party.
I am concerned that someone could easily get the location of our federation metadata document, and simply roll their own project utilizing the same port and get access to our active directory. Is this a valid concern, or am I worrying over nothing? What would be a better alternative to having to use localhost in this configuration?
Yes it's safe. The metadata document only describes information about endpoints and about the token that active directory is issuing. It doesn't inherently have anything sensitive about it.
The actual authentication is still going to be handled by AD and unless the curious user already has a way to successfully authenticate against your AD then it's rather useless for him to hookup into that document.
Could they potentially create an app that uses your authentication protocol? Sure, but what would be the point if nobody can actually authenticate against it. Allowing this sort of behavior to happen is one of the points of ADFS.
The design of the current app I'm working on calls for a WCF Service, hosted in a Windows Service, that pulls data and stores it on the hard drive. It pairs with a windows forms application that will interact with the WCF Service. One of the requirements is that the end user be able to restart the windows service through the Forms app.
So, I'm guessing this can be done using the ServiceController class... but what about permissions? I don't think we can (or should) guarantee that the windows app runs as admin, and the service is running as a Network Service.
The only thing I've seen that reasonably seems to cover the situation is having another windows service running, which could then be installed under an account with higher permissions, which you could call to restart the target service.
BUT I don't want to add that much complexity to the project, especially since it was supposed to be in beta last week.
So is there a way I can just give the Forms app the necessary permissions to restart it's specific companion service?
The follow-up question is down the line we might make it so the service runs on a server rather than the same machine as the app. Would this make it impractical to allow a Forms app to restart the service? If so I may advocate cutting the feature...
Oh, and should note that the target platforms are WinXP and Win7 with .NET4.
Instead of giving permissions to the app, you can assign permissions to the service to be started and stopped.
Every windows service has a security descriptor that is assigned a permissions what you are allowed to do on the service. By default service has permissions for authenticated users to read services state, and for admins to control the service, as well as delete it.
You can set service security descriptor using command sc sdset <serviceName>. For example this command will allow any user to control service (but only admins and Local system are allowed to delete service or change security on the service):
sd sdset <myservice> "D:(A;;CCLCSWRPWPDTLOCRSDRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)"
You might want to tweak the security descriptor a bit if you want to allow only a specific account to be used to control the service. This would work remotely as well, as long as the remote account is authenticated by the machine.
How about making the service responsible for restarting itself? It could expose a method, Restart(string userId, string password) or something similar.
On being called by an authorised user, it could use the approach outlined in this answer. That is:
Set the service to restart on failure
Call Environment.Exit(1)
OS restarts the service for you.
You would call Environment.Exit(0) if didn't want to restart.