I have inherited some code which acts as middleware between our application and MS Dynamics 365.
It currently uses client secret based authentication, however the client secret is stored within a web.config, meaning that anyone who gets the appropriate URL to our app has access to the MS Dynamics org, which is bad...
I have updated the code to use a Certificate instead of a client secret, which makes management/housekeeping easier, but again if anyone gets the url, they have access to the org...
The middleware app code is all C# and uses the Microsoft.Xrm.Tooling namespace (CrmServiceClient) for establishing a connection to MS Dynamics 365.
The application works well, but is just insecure.
Our application is embedded within MS Dynamics as a popup page launched from a Web Resouce (some JavaScript with a window.open) and users have to be logged into MS Dynamics to be able to access this Web Resource.
In Salesforce.com, we use the SessionID to pass to the middleware to establish an API connection, but MS Dynamics doesnt seem to have anything like this available.
The call chain is basically:
MS Dynamics > Embedded page
Embedded Page > middleware app - establishes a MS Dynamics connection using clientid/secret or certificate stored within the Azure App service or Key Vault
Middleware app > our app
Our app > middleware app (to load CRM data) this is really where the security flaw is, if a nefarious user has the url to our app at this point, they effectively have access to MS Dynamics data with no authentication challenge (as the MSD connection is established using clientid/secret stored within the web.config or a certificate, which is stored on the web app)
I dont want to introduce a login screen to our app as it will break the immersion and people will hate it.
Can someone please suggest a better appproach for me?
Related
my problem is that I try to collect data from one of the dataverse table from the c# backend code, but without app registration and getting app id (long business process in my company). Is there any way to achieve using something other than official dataverse web api?
I was trying to use httpClient to send GET requests to the dataverse, as well as DataverseClient nuget package and FetchXMLBuilder. I couldn't connect
You do need an authenticated and authorized user to access dataverse via its API's (Any modality)
If you have an account to the dataverse instance you are looking to query data from and are authorized in the system to do so, you can create an interactive login via the Dataverse ServiceClient, or set up the same via MSAL (or similar) library and access the API that way.
Headless connections however do require a Client Application ID and either a Client Secret or Client Certificate to connect.
I have a client that just changed their Dynamics CRM login to use "One Login" (https://www.onelogin.com/product/sso), I believe with SAML. I was not part of this change. However a Web Leads Form that I built them that creates leads in CRM directly now does not work because it used the following to login in the Web.config of my aspx project.
<connectionStrings>
<add name="Xrm" connectionString="Server=https://***CLIENT***.crm.dynamics.com; Username=user; Password=pass" />
</connectionStrings>
//In the code behind
var xrm = new XrmServiceContext("Xrm");
It now gives this error
the authentication endpoint username was not found on the configured secure token service
Obviously they turned off Username/Password login on CRM.
I have no idea how to proceed next. My thought is that I need to somehow call a login to One Login to get a Token and then pass a token to CRM?
Does anyone know how to do this in C# .net? What questions do I need to ask my client as it relates to what tokens, etc I need to get from One Login. I have never worked with them before.
Or at least the general idea of the concept of obtaining tokens and passing them back and forth. I believe this is SAML?
I would check to see what type of claim is generated by the OneLogin application. Microsoft Dynamics uses two types of authentication. Active directory and OAuth2.
These link will point you to how Dynamics uses authentication
https://msdn.microsoft.com/en-us/library/gg328497.aspx
https://msdn.microsoft.com/en-us/library/dn531009.aspx
http://sharpshooting.github.io/authentication/2015/03/24/oauth2-on-dynamics-crm-online.html
As far as obtaining the claim (if it is Oauth) I would look to some of the existing libraries such as JWT https://jwt.io/ they have some straight forward libaries for c#,
My organization currently uses Office365, and I am creating a Universal Windows Platform app that essentially needs to access the calendars of multiple accounts within the organization. I am currently using the Office365 Rest API, and already can successfully query a single account's calendar data, after getting an OAuth2.0 access token for a particular user.
After searching through multiple resources and existing Stackoverflow questions, I have tried the following with no luck to get multiple user account calendars without having to sign in to each account individually:
Performing a GET request with the graph API from Microsoft Graph API
Performing a GET request using navigation paths to users calendars using this method and other variations. (Returns 403 access denied error)
I also found a possible solution by using EWS Managed API, but I was unsure of its compatibility with UWP and our current Office 365 setup.
Lastly, I looked into building daemon or service apps, but this method seemed really unnecessary and possibly impossible with the current configuration of Azure. It requires asymmetric key crypt. set up within the system, and re-configuring the app as a whole within Azure.
Any help is appreciated.
[EDIT]: FYI all of the calendars have been made public, and can be viewed in the web client of Outlook.
I found to what I think is the only solution with today's version of UWP and the Office365 REST Api.
First I started up a different application that was compatible with the EWS Managed API and made a query to the Microsoft Exchange server that my organization is using. I tracked this request using Fiddler, the http debugger, to view the actual request and response. This way, I could find the exact endpoint of my exchange server.
Then, I navigated to the exchange service's URL in my browser, and saved the service's WSDL file, and imported it as a service reference to my UWP solution.
Finally, I set up a Httpclient, and generated a request to match all of the properties of the request made from the successful EWS Managed API call that I tracked in Fiddler.
I am just starting out with a windows azure mobile services .net backend, and am running into so many headaches as a new programmer. I have gone into my azure mobile services account and downloaded the todoitems demo app (c# for .net backend). I then followed the tutorials regarding adding facebook authentication, but I am absolutely not pleased by this method, as it shuts down the app for a few seconds. As such, I set out determined to create a custom authentication login page which ties to my mobile backend.
I found this article and thought, "Great!" only to realize that I had no clue how to catch a user created account from a textbox and to pass it along to the public class RegistrationRequest. The example at the end of the link shows how to connect to a local machine - but I want it to connect to my actual database at the following location: https://mycustomapp.azure-mobile.net, return a token, and continueon.
What is frustrating is that I am able to obtain a facebook authentication token, as well as user information. BUT, I have no idea how to generate a windows azure mobile auth token so that the client may write/retrieve data from my azure table.
Essentially my question is this - using the above link, how in the world may I take a user's username and password from a textbox, run it through the RegistrationRequest, and not have to pop advil on this? Do I need to pass my facebook token? I assume not?
I am also not using a facebook SDK or anything like that - simply put, I am using the above site's code trying to get an auth token from my azure mobile services, despite having one from facebook already, to authenticate a user against my azure mobile services data table.
If you already have a FB token, the easiest way to login to your mobile service is by using the FB token, then you don't need to make a custom UI/etc.
This can be done by calling
var token = new JObject();
token.Add("access_token", "access_token_value");
await client.LoginAsync(MobileServiceAuthenticationProvider.Facebook, token);
see: http://azure.microsoft.com/en-us/documentation/articles/mobile-services-windows-dotnet-how-to-use-client-library/#authentication, Client Flow for more
if you want to login to your service with a Facebook account, you do not need to implement a custom authentication and to capture user name and password in your own textbox controls.
You should be able to use MobileServiceClient.LoginAsync() and pass as parameters the provider that you want to use. Check this article fro more information.
Is there a mechanism in Azure AD to have a completely headless authentication? Most likely this would mean (in my mind) that the server running the API would have a perpetual authentication session to Azure.
If the purpose matters... We have a need to expose our thumbnailImage attribute from AD and I just need to make it so that the server doesn't care who requests the image. So basically we will have https://domain.com/api/Image/userid and the api will return an Image object (image/jpeg). I have this functioning internally and now I'm just migrating to Azure.
I found this question... I just want to confirm two things...
Daemon or Server Application to Web API is the method I should be looking at
Using this method will function as I'm expecting... a.k.a. WebAPI can access that attribute and use it like I currently use it while inside our internal domain.
Indeed. Azure AD supports the client credential OAuth flow. Yes, you are looking at the right help topic. The corresponding sample application is here: https://github.com/AzureADSamples/Daemon-DotNet.
If you haven't already, use Azure management portal to register your WebAPI as an application in your Azure AD directory and add a client secret (under the section named 'key' in the 'configure' tab of the 'application'). This key will be used as the client credential.
To configure permissions for your WebAPI to be able to call Graph API using client credential flow token, go to the application tab in the Azure Portal, under Azure AD and in the section titled 'Permissions to other applications', add an 'Application Permission' to 'Windows Azure Active Directory' to 'Read directory data'.
What you refer to as perpetual authentication session is basically your WebAPI caching the access token to Graph, and getting a new access token (using client credential flow) when the current access token is about to expire.
Hope this helps.