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?
Related
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 have an application which is hosted on the on-premises Windows server (IIS) server
now I created a windows server on azure and building a web app for it.where the application needs to authenticate the user by windows server (DC) using kerbrose protocol but I couldn't find any documentation regarding this from Microsoft's side
Is the above query possible to be implemented in the azure web app?
No, it's not possible. Windows Authentication is something for on-premise deployments. For Azure Web Sites Azure Active Directory is clearly the best option. Sync from AD to Azure Active Directory is also quite easy to setup.
If you still want to absolutely use Windows Auth and host your website on Azure, you can create Windows VM and host your website there. You then need to join the VM to your AD. To this, both VMs must be in the same network. So if your VM is on-premise you will need to create an site-to-site VPN.
For more information, follow this SO which also discussed about this.
If your intention is to join the VM hosting the website to a domain then as others have mentioned, this isn't possible.
However, doing Kerberos authentication itself within an Azure website isn't particularly difficult, but it does require manual implementation. Windows natively handles all of this for you on domain joined machines and and IIS exposes that functionality. Since you can't domain join you have to manually do all that heavy lifting and request and validate the tickets yourself.
This involves creating a service account in Active Directory and keeping the account password in sync. Once you have that you need to indicate to the browser that it needs to negotiate auth, which is done with the WWW-Authenticate: negotiate header on a 401 response. The client, if configured to send tickets, will send a ticket in the Authorization: Negotiate YII... request header on a subsequent response. At this point you need to shove that negotiate header and that original service account password into something that can validate Kerberos tickets. Windows SSPI will do this for you, but it's a pain. I built a library that'll do this for you: Kerberos.NET. YMMV with what works best for you.
All of that said, it may be more beneficial to switch over to a more modern authentication mechanism like OAuth/OpenIDConnect/SAML.
There are several ways depending on if you have to allow access to users who are associated with a on-premise Active Directory or not.
You should have a look at this service: https://learn.microsoft.com/en-us/azure/active-directory-domain-services/
It will offer an Active Directory within Azure where you can domain join your VM to and then using Kerberos as authentication protocol (should work the same way like on prem).
The other option would be to create a new Active Directory within your Virtual Network (via 1 or 2 small Windows Server VMs where you create the AD).
The good thing if you are using Active Directory Domain Services would be that you could extend it to your on-prem Active Directory by synchronizing or federating your on-prem AD.
There are more informations regarding these scenarios here:
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-hybrid-identity
For a Azure App Service - Web App you would connect it to your Azure Active Directory (AAD) and use the hybrid identity model to allow users who originate from an on-prem AD access to it:
https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad
Hope this helps a bit, it is a rather complicated topic you are digging into.
I am curious to know why we always need to register our CRM online instance on an Azure Active Directory in order to authenticate the Web API while accessing from outside CRM domain.
That is, for example, if I need to access CRM online instance through another website using CRM's Web API endpoint, then I must register my CRM instance to Azure Active Directory.
Though I am aware that, its a very nominal charge to create an Azure Active Directory, still I would need to subscribe to Azure even if I just want to perform some general research for CRM connectivity through Web API.
Why this is must? Are there any security considerations behind this?
Why can't we use the same authentication mechanism as we used to do with Organization service?
Any details on this will be much appreciated.
The CRM WebAPI uses OAuth2 and Azure AD is the only currently supported authentication platform to provide this (Windows Server 2016 will support OAuth2 for on-premise).
The Organisation service is a WCF service and as such uses SOAP for authentication and authorization. This is an entirely different technology stack that brings it's own set of problems, many of which the OAuth2 protocol tries to solve in this scenario.
Although you manage your CRM Online users through the Office 365 portal the underlying technology for these accounts is also Azure AD. Check if you can use this existing AD tenant created as part of your subscription rather than having to create another.
If you are using CRM online you already have aan Azure Active Directory. If you haven't already done so, you can signup for an Azure subscription and import the underlying AAD into your Azure subscription. You will need a credit card, but as far is I know using the Azure AD is free.
I'm trying to figure out the right architecture from a mix of current .NET authentication/authorization offerings. One question that I haven't been able to find much online information on: What are the benefits of having ThinkTecture IdentityServer 2.0 federate ADFS 2 (which is authenticating domain users using Active Directory credentials), vs having IdentityServer authenticate users against the domain directly?
For my company, I see only 3 possible requirements for ADFS 2, but I'd prefer to avoid installing it if IdentityServer is sufficient (mainly because it's open-sourced, and therefore more readily debuggable, extensible, and understandable):
Claims-based authentication of corporate (Active Directory) users.
Support for Office365 SSO - there are directions for integrating Office365 with ADFS
Federating external (business partner) ADFS services (we don't currently need this, but I'd like to keep the option open)
Is any of this functionality not provided by, or not easily added to, IdentityServer 2.0?
Well IdSrv does not do Windows authentication out of the box. It would be easy to add forms based authentication for AD users - but Windows integrated (SSO) would be more involved.
IdentityServer is a really good product but:
Only authenticates against SQL not AD
Doesn't have SAML support - useful for third party integration e.g. SalesForce
No rich claims rules language
which ADFS does for you.
#leastprivilege answered the first - the rest are definitely not trivial to add.
Don't have much experience with Office 365 but it sits on top of Azure Active Directory which can be hooked up with IdentityServer - refer Federating IdentityServer with Windows Azure Active Directory.
I am migrating one ASP.NET MVC 3 intranet Website to the Windows Azure and DB to SQL Azure.
On Premises my site uses Windows Authentication to authenticate and authorize the user(By Placing AUTHORIZE attribute on controllers).
It would be very kind of you If you can let me know How to go about the same.Thank You In Advance !
You have two choices here:
Use federated authentication and something like ACSv2. This requires a bit of work to setup a relying party, install ADFS2, etc. However, it is the most robust and future proof option. It is a very good option.
Use something like Windows Azure Connect. That will bring Windows Authentication to the cloud by joining your running instances to your domain controller on-premises. In effect, you have something of a VPN between your cloud instances and your on-premises domain controller. There are some caveats to this model today (requires installing agent on DC for instance), but it would be from a 'just works' stand point, the easiest. Longer term, this is less attractive I believe than option #1.
You can get more details for each of these by checking out the Windows Azure Platform Training Kit.
I should also add that you have no option (today at least) of using Windows Authentication with SQL Azure. You must use SQL authentication there, so what I am talking about here only applies to the web site itself.
I'm very successfully using Windows Identity Foundation with Azure AppFabric Access Control Service to authenticate using ADFS v2.
As well as straight authentication, it gives you lots of flexibility over other claims, such as roles (which don't need to be based solely on AD group membership).
In my opinion, its biggest strength is that there is no communication channel required between the Azure platform and your on-premise AD. Everything is done via the browser. From a security perspective, this means that although anyone can reach your application, nobody can authenticate to it unless they can also reach your ADFS server. Access to this can be restricted to on-premise clients only or via VPN, greatly reducing the attack surface.
Also, because ADFS does not need to be exposed externally, it can greatly ease the bureaucratic overhead of deploying it, in my experience.
Only configuration is required, which although it can be a bit of a fiddle initially, is pretty straightforward once you've got to grips with it. You configure WIF to use ACS as it's Identity Provider and create a Relying Party in ACS for the application. Then, you configure ACS to use ADFS as its Identity Provider. You could configure WIF to talk directly to ADFS, but the additional level of abstraction of going via ACS can be useful.
Once you've done your configuration, using the [Authorize] attribute 'just works'.
Note that if you're using Ajax calls into your controllers, you'll need to take some precautions, as Ajax calls don't handle the federated authentication redirect (or the ADFS Shuffle, as I like to call it), but it's nothing that's insurmountable.
All in all, I'm very impressed with the combination of WIF+ACS+ADFS for transparent Windows integrated authentication.