While creating a provider-hosted app for SharePoint 2013 in Visual Studio 2013, in the app creation wizard on 'Configure authentication settings' page we have 2 options.
1) Use ACS
2) Use certificate(for on-premise)
Since I am using Azure as the host and I am forced to use ACS. Is it true? Is there any replacement for ACS for authentication in provider-hosted app in Azure?
I plan to change from Azure to on-premise at a later stage and I see this dependency on ACS annoying.
We can Authenticate with out ACS(or any external authentication provider) by using AFDS(active directory federation service). Federation Server needs to installed in Intranet(AD already exists). The external party (app) gets autheticated through this federation server. No external(outside intranet) authentication mechanism is needed.
Related
I have created a simple web api in ASP.NET Core and wanted to publish to Azure Web App.
I'm using free trial subscription and have only one web app resource created in Azure.
The app service plan is using free tier 'D1' SKU and is the only one present in my subscription.
However, while trying to publish the web api by choosing this web app in Visual Studio publish profile, it says 'there are no existing instances available'.
The web app resource does appear here:
Clicking next while the resource is selected, results in the issue:
I have created a .Net Core Web App in the Azure free trial Subscription with free tier plan
Initially it contains only hoststart.html
KUDU Console of Initial App Service
Created a sample .Net Core Web API Application in Visual Studio and tried to Publish to the App Service which I have created in Azure portal
Make sure you have login to the same subscription in Visual Studio where you have created the web app in Portal
Initially it was prompted to re-enter the credentials after changing the Azure Subscription,I have refreshed the Visual Studio , after few seconds Iam able to see the correct Subscription details.
Iam able to see the App Service which I have created in Portal
Able to successfully deploy the WebAPI to the App service in Portal
KUDU Console of App Service after Publishing the WebAPI from Visual Studio
Deployed WebAPI Output
Update
You are in the correct path, after selecting the web app it asks to create the api.Click on the + symbol and add the API Management
Seems like you created a Web API resource and no API Management resources. Those two are independent Azure services. Former is needed to host your API application. The other one provides additional features to your APIs and is completely optional - you can look it up in the official documentation.
The step to select/configure API Management resource was introduced in deployment wizard at some point. It is confusing and probably could be handled differently.
Unless you need API Management resource, just skip the step and you'll have deployment profile ready.
Our setup consists of on-premises CRM 2016 in IFD configuration with ADFS. We have several custom web apps that are embedded in iframes in CRM as well. Our web apps are MVC running in IIS on .NET 4.7 and use the WS-Federation IIS module for authentication. This provides a pretty seemless experience where the embedded application does the redirect to and from ADFS to authenticate the user after they're already logged into CRM.
Our applications also call APIs we have created, which in turn make calls to Dynamics CRM web API using OData. Our APIs are setup to make calls to the CRM web API as a specific user chosen at deployment (it's a bit ugly, but it works). This causes issues associating created entities with the actual user, as CRM considers them created by the user in the API deployment. We need to fix that so that the user authentication is passed from our web application to our API and then to the CRM OData API.
From searching this site and other resources, I have determined this is not possible with WS-Federation and I would need to use OIDC. But, all the documentation that I have found about using OIDC in this manner has involve using Azure Active Directory and Dynamics 365, which does not apply in my scenario. I haven't found any information for the configuration of a local CRM 2016 instance or ADFS.
How is this accomplished for an all on-premises deployment?
To impersonate a user, set the CallerId property on an instance of
OrganizationServiceProxy before calling the service’s Web methods.
via https://learn.microsoft.com/en-us/dynamics365/customerengagement/on-premises/developer/org-service/impersonate-another-user
Or
To impersonate a user based on their systemuserid you can leverage
MSCRMCallerID with the corresponding guid value.
via https://learn.microsoft.com/en-us/powerapps/developer/data-platform/webapi/impersonate-another-user-web-api
Although I can't guarantee that it will work in version 8.1 and below.
We've enabled multi-factor authentication for our Azure subscription and it seems to work fine when logging on to the portal, but when I try to deploy a web service from Visual Studio it just goes ahead and does it without so much as confirming my password.
This is completely unacceptable for us, it must absolutely require prompting for both a password and an SMS code in order to able to deploy. Deploying something incorrectly, accidentally or without sufficient authorization has the potential to severely compromise the integrity of our service.
When you configure Visual Studio on the developer machine to connect to Azure subscription, did you uncheck "Remember Password" for login screen and "Trust this computer"?
Secondly, you can provide the developer only Read permission on the underlying artifact (i.e. Web App or Cloud Service) using the Role-Based Access Control (RBAC). To deploy, they would have to use deployment credentials.
I followed the steps as per
https://github.com/OfficeDev/O365-WebApp-MultiTenant and added the connected service. However this does not register the app under Windows Azure Active Directory Applications. I have properly linked my office 365 account into Azure. However when I add the connected service it is still empty. Is this a known issue and what is the work around?
No, this isn't a known issue. The "Add Connected Service" wizard is not generating a client ID and secret in your web.config?
As a workaround you could login to the Azure Management Portal and register the app manually, then put the client ID and secret into your web.config.
I just had the same issue and spend some hours on it. Finally it turns out that I had used a user account to log in in visual studio that was assigned to a different MS Azure account.
In my case I was using the user of production environment instead of my own developer account to log in.
I need to migrate some existing WCF services to a new WebAPI-based architecture. Unfortunately, they run on two SharePoint 2013 farms, trusted to one another, and rely on claims authentication to perform task with the application pool account.
I already have running Web API controllers in SharePoint, but I couldn't find a way to automatically authenticate the system user across farm.
Which is the preferred approach I could rely on?