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.
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.
Good morning everyone,
My apologies if this post is too similar to this post:
Dynamics 365 and Azure integration
but I am struggling to understand exactly what is needed in order to setup a web service on an Azure server that is consumable by a Dynamics 365 plugin. Based on my research it appears that it goes as follows but I would like to see if any knows of a better guide.
1.) Construct the web service as normal on the Azure Windows Server.
2.) Register a proper DNS Domain name (friendly-name) and route it to the Azure server.
3.) Secure that Azure server/URL with a certificate.
4.) Call the web service from my C# Dynamics 365 plugin.
Is that everything or might I be missing something critical? Thank you!
4 might be an issue, given you want to use certificate based security, not sure that will work, you might need to use another mechanism, e.g. basic user name and password. Otherwise looks okay.
Plug-in isolation, trusts, and statistics
Web access
Sandboxed plug-ins and custom workflow activities can access the
network through the HTTP and HTTPS protocols. This capability provides
support for accessing popular web resources like social sites, news
feeds, web services, and more. The following web access restrictions
apply to this sandbox capability.
Only the HTTP and HTTPS protocols are allowed.
Access to localhost (loopback) is not permitted.
IP addresses cannot be used. You must use a named web address that requires DNS name resolution.
Anonymous authentication is supported and recommended. There is no provision for prompting the logged on user for credentials or saving
those credentials.
Our current API use seesionID for the authentication. We plan to use Azure API management to manage our web api. However Azure web api management has their own authentication. How can we link those two together. Our customer can use the same logon information.
Conversations about authentication and identity in Azure API Management can get tricky because there can be three different identities and then there are the different contexts of runtime requests vs management requests. So, to be sure I'm answering the right question, let me try and get some terms defined.
The three identities:
API Provider: This is the Azure user who has created an API Management instance.
API Consumer: This is a developer who is writing some client software to consume the API.
End User: The user of the application written by the API Consumer and will be the one who actually initiates runtime requests to the API.
I am assuming that you are the API Provider. What I'm not sure about is whether your customers are the API Consumers or the End Users.
Azure API Management provides identity services for API Consumers. Consumers can either manually create a username/password account or use some social identity provider to create an account. They then can get a subscription key that will allow Azure API Management to associate requests to the API Consumer.
I think you are asking if you can connect the sessionID, which I am guessing you use to identify End Users, to a subscription key used to identify API Consumers. If that is correct, then the answer is no (except for the scenario described below), because we need to identify the API Consumer key before any policies are run to ensure we run the correct policies.
You can change our Api Consumer subscription key. So, if you only have a low quantity of customers/End Users you could create an Api Consumer account for each End User. However, you would only be able to map sessionID to API Consumer Subscription Key if sessionID was a constant value. I'm presuming based on the name, that value changes at each login.
Although Azure API Management provides identity services of API Consumers, it does not provide full identity management for End Users. We leave that to external partners like Azure AD, Thinktecture Identity Server and Auth0. I'm assuming that your existing system is already using some kind of identity provider to generate the sessionId. What you can do with Azure API Management is validate that sessionId using policies in the API Management Gateway. To do that we would need to know more about the format of the sessionId.
Sorry for the long post but it is a confusing topic and I wanted to be as clear as possible.
I have implemented Azure Active Directory Oath2.0 authentication and now I have to implement Claims-Based and Active Directory authentication in Java for Dynamics 365 Online/On-Premise.
I'm following this topic: https://msdn.microsoft.com/en-us/library/gg334502.aspx and here it says that Dynamics 365 online supports the following authentication scenarios: Claims Based Authentication or Active Directory Through Federation.
The problem is that I don't know from where to start and what configurations have to be done. I've played with azure portal and with the dynamics 365 online admin panel, but just can't figure out what I have to do :).
Can I use some info from https:// login.microsoftonline.com//FederationMetadata/2007-06/FederationMetadata.xml to perform such authentications?
Do I need do install a local Active Directory server?
I highly recommend looking through some Azure AD samples on how to setup oAuth2.0 to various Microsoft services. The dev landing page has tons of a great samples. Here is the java sample.
If you're trying to sign in purely Azure AD users the access some resources, then this is pretty straight forward. You'll want to register an app in the Azure Portal, setup all the delegated permissions and app configs necessary (the sample will help with this), then use the ADAL library to perform the oAuth2.0 flow. This flow will return back tokens that can be played to whatever service you requested access in the form of http requests.
This page states that before an application can access the API (I'm particularly interested in the Calendar API), it must be registered with Azure AD. Is this also true for organizations that may host their own Exchange servers?
Could someone provide a breakdown of what's necessary for me to get started with accessing the API to access the users' Calendar? I'm aware of the API reference, but I'm not entirely sure what's necessary to do before I can use the API.
That page is for Office365, not self hosted ones.
You can access your local/self hosted Exchange server with Exchange Web Services by using username/password, or even your local AD if you set it up correctly.
The API it is talking about is not available to on-premise Exchange Server, it is only available to Exchange Online in Office 365. This may change in the future, but currently you cannot use it in on-premise. Exchange Web Services is the way to go for on-premise.