The Stack:
Client: AngularJS & Firebase
Server 1: Microsoft Exchange Server
Server 2: NodeJS
AngularJS app loosely communicates with NodeJS through async task-queues. Client does not directly interact with NodeJS instances.
The Problem:
Perform simple operations on a User's calendar, with a task queued on a client and executed on a NodeJS instance.
What I've Tried:
ews-javascript-api: Works well, except there isn't a streamlined authentication mechanism. That is, it doesn't support OAuth authentication. In my opinion, managing each User's Exchange credentials is not a suitable solution.
iCalendar Events Subscription: (Still evaluating this approach.)
I guess fundamentally, what I am trying to do is have a User subscribe to calendar events in my app. I don't mind writing an API for Exchange Web Services but, it seems like overkill.
I am going to keep working on this, but if anyone knows of a simpler solution, it would be greatly appreciated.
I am the author of the library ews-javascript-api.
have you taken a look at https://stackoverflow.com/a/43785262/5884960?
I have provided information on how to use OAuth in the answer to the question in link. caveat is that you have to on-board each Office 365 separately, you can not run a node daemon and connect to multiple Office 365 Organization (without complex environment setup with org on boarding steps). This is quirks of Office 365 OAuth requirements not limited to the library itself. c# version have same limitation.
I have provided another library for helper authentications for ntlm and cookies, for Office 365 you just need ews-javascript-api.
Related
Is there a "best" way of achieving this?
Basically I want to leverage my company's Azure AD tenant to build a fully featured internal application. Using Microsoft Graph, I can retrieve users via their identifier guids, and use the identifiers as foreign keys for various tables in our on premises database, instead of having a dedicated User table, which would need to be populated and synced up with the AD. There are many other prospective uses for Graph, but leveraging users is the priority right now.
A large chunk of my application is built already. I am able to lock down my client app using the package react-aad-msal, requiring users to authenticate through single-sign-on. I have also successfully been able to pass that token back to the protected .NET Core API, accessing various endpoints as the authenticated user.
From here, I am not sure how I can develop the calls to Microsoft Graph. At which point should I make the connection? Should the client application connect to both the on-prem API, as well as Graph? Or should it only connect to the on-prem, which would then connect to Graph? Curious to know the pros and cons of either method.
I've also heard tell that Microsoft is working on their own package: #azure/msal-react, and that react-aad-msal should no longer be used (as it only supports msal 1.0 and not 2.0. I have no idea which version is better for my needs). While msal-react is still in development, apparently I should be using #azure/msal-browser. But I cannot find a good example of a react app using msal-browser to authenticate.
Here is a Sample on how to use MSAL with React to call Microsoft Graph.
The only different in your case will be that instead of calling Microsoft Graph, you will call your own API.
Bottomline is - there is no direct integration package yet for react. Which can also be read from the official statement on the msal-js repo:
After our current libraries are up to standards, we will begin
balancing new feature requests, with new platforms such as react and
node.js.
You can also use .net core instead. Please go through the sample here which can help.
We're are about to build a new intranet system for our company, leaving SharePoint behind. The system will be built using Ruby on Rails. Since we're using Office365 for mail, calendar etc., we would like to authenticate our intranet users through Office365.
I'm aware of Microsoft Graph API, but I have a hard time figuring out of there is a possibility to authenticate users from a third-party application. Moreover, we would like to retrieve general information about the user, like profile picture and calendar information.
Is anybody knowledgeable about Microsoft Graph API and know if it's possible to achieve our goals using the API?
You're on the right track. You would authenticate with Azure AD, which is in the 365 ecosystem.
I wrote (and answered) a detailed guide here:
How to get the JWT (using OpenIdConnect) from HttpContext, and pass to Azure AD Graph API
Note that this is the OpenIdConnect flow. I think the Saml2 flow is somewhat different.
Don't take my advice on storing the authentication codes or try to acquire the token silently - it ended up causing issues in production that weren't seen in test. Rather, just use the user object id as your key attribute.
The microsoft documentation on the topic is a little cerebral and abstract, so it'll take a little head scratching, but have a look at the samples mentioned in the post I linked above, they'll get you started.
Yes, using Microsoft Graph is the right way to go about achieving the stated goals here.
There are quiet a few samples and tutorials provided on the Microsoft identity platform code samples page that will teach how to build an app that calls Microsoft Graph.
I have followed Adrian Halls book to create a cross platform app with a Mobile Service API backend. I have successfully got unsecured access to the backend working from Android, iOS and Desktop (WPF) clients. I am moving on to adding security to the API using the Authorise attribute. I would like to add social authentication using MicrosoftAccount (formerly passport/Live ID).
Since Adrian wrote his book the Microsoft.Azure.Mobile.Client and the authentication and authorisation landscape seem to have moved on. The samples given in the book no longer build and Microsoft's social authentication and AAD authentication seem to have been rolled into one API.
I have spent days searching for up to date and relevant information but there seems to be lots of stuff on the internet that is either out of date or only shows examples of authenticating using Facebook or Google from Xamarin clients or authenticating against Azure AD.
I am using .NET 4.7 and WPF for the desktop app. I am also using Microsoft.Azure.Mobile.Client V4.0.1. and my questions are:
Should I be using the Microsoft.Identity.Client to authenticate users from my desktop client; and,
If so can someone point me to an example of the client flow that I need to follow, specifically how do I get the authorisation token that I need to pass to the new MobileServiceClient.LoginAsync() function that uses the identification provider and token parameters?
If so can someone point me to an example of the client flow that I need to follow, specifically how do I get the authorisation token that I need to pass to the new MobileServiceClient.LoginAsync() function that uses the identification provider and token parameters?
According to your requirement, you want to use client-flow authentication with MSA. As I known, MSA authentication uses the Live SDK for signing users.
Since Live SDK is deprecated, you could leverage OneDrive SDK for CSharp for logging with MSA, and you could follow the detailed steps for achieving this purpose:
Install the client libraries via NuGet:
Microsoft.OneDriveSDK
Microsoft.OneDriveSdk.Authentication
Log into Microsoft Account Developer Center and create your app, add the native application platform, then Register your app with Microsoft Account.
Then you could follow the code below and add to your WPF application as follows:
For more details about OneDrive SDK for CSharp, you could refer to here and Authentication Adapter for the OneDrive SDK.
UPDATE:
It's my fault. I did not mention that the above code would automatically open a web browser. Per my test, you could configure the parameter returnUrl to https://login.microsoftonline.com/common/oauth2/nativeclient when constructing your MsaAuthenticationProvider instance.
I was in a similar boat - and here is summary from the top of my head - There two security libraries currently in play for authorization- ADAL, and MSAL.
ADAL
This is the first library that came out, and services like B2C must each be handle separately using this library.
MSAL
One security framework to rule them all!
https://github.com/Azure-Samples/active-directory-xamarin-native-v2
This library has a go live license, but technically it's still in Beta.
Head to Mobile.azure.com for the last info in creating a mobile application, and this article on a V2 endpoint.
When you register an application for Authorization - there are two categories a "Converged" application, and a "Live SDK application" ( see https://apps.dev.microsoft.com/#/appList) - why they would choose these names is beyond me to understand. IMPORTANT Translation - Converged application ONLY work with MSAL, the other ONLY works with ADAL. THAT will go a long way for you to get the authentication working, as the Application / Client ID must match the correct SDK, and hence endpoint.
In the end, we chose to stay with ADAL for now as we were having problems with MSAL. MSAL is the future however, as all services will be incorporated, and it should be an easier SDK to use.
Here are some links that I kept, all of which refer to ADAL or MSAL:
http://aka.ms/aadv2
https://azure.microsoft.com/develop/identity
https://learn.microsoft.com/en-ca/azure/active-directory/develop/active-directory-authentication-scenarios#native-application-to-web-api
https://github.com/AzureAD
https://github.com/AzureAD/microsoft-authentication-library-for-dotnet
These links are about month old - HTH
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 about to build a community platform from scratch. We are going to create the WebServices first and the community might have some third party components, so having solid WebServices is a good idea anyway.
Since the service is stateless we need authentication for every single call. Is it a good idea to implement the OAuth protocol for our service provider to perform this task although we are the only consumer right now?
By the way: We will deliver a mobile application before a website is launched.
The whole point of OAuth is to allow other websites (consumers) to get access to your data (you are the provider). Since you are the only consumer of your data, there is no need to implement OAuth at this stage of development.
Be lean, build something fast and put it in front of users/testers. Only at this point you will discover real bugs and get a feedback on the service so that you can improve it and steer the development in the right direction.
Note: OAuth as provided by App Engine (second paragraph) only supports users with Google Accounts (even if OpenID is used).
From my experience I created the REST WS in a authentication agnostic way: jersey methods accept everything, then there are several filters in order to validate the requests.
I used OpenId authentication for the web part, OAuth and BASIC AUTHENTICATION (with SSL) for API.
Probably it is not needed to create everything from the beginning, but remember to de-couple as much as possible your REST endpoint from the authentication: you will have a great benefit when you want to release APIs.
Last "philosophical" thing: OAuth is not totally stateless, in fact you have a temporary token that authenticates a user and it is similar to a session in the browser!