Author: givenscj

Posted on

Developing for Office 365

Here is the outline of the latest ACS Course.  If you are a consulting company and want to get your team up to speed, let me know and we can setup a remote training engagement!

  • Introduction to Office 365
    • Sign up for Office 365 Developer
    • Explore Office 365 Admin Center
    • Explore Office 365 Services (Outlook, Calendar, People, Newsfeed, OneDrive, Sites)
    • Provision an O365 Developer Site
    • Install Office Dev Tools
    • Install the NAPA App
    • Install O365 API Tools
    • Configure Visual Studio for Office 365 Development
    • Exploring Azure AD PowerShell Cmdlets
    • Exploring SharePoint Online PowerShell Cmdlets
    • Exploring Exchange Online PowerShell Cmdlets
    • Exploring Lync Online PowerShell Cmdlets
  • Authentication
    • Generating FedAuth Cookies (Windows App)
    • Generating FedAuth Cookies (Windows PowerShell)
    • Generating Bearer Tokens (Provider Hosted Apps)
    • Registering SharePoint Apps Manually
    • Requesting On-The-Fly Permissions
    • Using Basic Auth against O365 APIs
    • Setup Azure Active Directory
    • Configure Azure Active Directory
    • Synchronize local AD with Azure AD
    • Configure Single Sign-On
    • Using the Microsoft Remote Connectivity Analyzer
    • Registering Azure AD Applications
    • Manual Authentication to Azure AD
    • Using the Azure Active Directory SDK
    • Authorization using Consent Framework
    • Registering Applications with Azure AD
    • Building Apps that utilize Consent Framework
    • Managing Tokens
    • Extending the Azure Consent Framework
    • Implementing On Behalf API
    • End User Telemetry (MyApps)
    • Tenant Admin Telemetry (Cloud App Discovery)
  • Working with REST and CSOM
    • Using the Discovery Service
    • Working with Mail REST APIs
    • Working with Calendar REST APIs
    • Working with Contact REST APIs
    • Working with OneDrive REST APIs
    • Explore REST Services
    • REST List Service Calls (PUT, GET, MERGE)
    • REST UserProfile Service
    • REST Social Service
    • REST Search Service
    • Explore Client Object Model
    • Utilize Client Object Model (.NET)
    • UserProfilesSocial CSOM
    • Taxonomy CSOM
    • Publishing CSOM
    • BCS CSOM
    • Explore JavaScript Object Model
    • Working with Workflows
    • Working with REST
    • Using LINQ with OData
    • Working with OData Limits
    • Working with OData Filters
    • Creating Projects
    • Creating Resources
    • Creating Tasks
    • Creating Custom Fields
    • REST Authentication (Windows, Forms, O365)
  • Programming Apps
    • Explore SharePoint Store Apps
    • Install a SharePoint Store App
    • Create a SharePoint hosted App
    • Deploy a SharePoint hosted App (App Catalog)
    • Deploy a SharePoint hosted App (Side Loading)
    • Create and deploy a Provider hosted App
    • Inviting External Users
    • Exploring App and User Permissions
    • Exploring Context Tokens
    • Exploring Access Tokens
    • Exploring Refresh Tokens
    • Download the Office AMS samples
    • Explore Office AMS
    • Using the SharePoint Web Proxy
    • Exploring Office Apps Store
    • Installing Office Store Apps
    • Browsing and Removing Installed Apps
    • Create a simple mail app with Napa Tools
    • Create a simple mail app with Visual Studio
    • Review sample O365 Mail Apps (EWS Calls, Attachments, Identity Tokens, YouTube integration)
    • Creating a Seller Dashboard account
    • Create and Publish AppStore SharePoint App
    • Use the Cloud Business App template
    • Creating Data Tables and Screens
    • Register a Yammer App
    • Create a Yammer App
    • Make Yammer API Calls
  • Workflows
    • Create basic SharePoint Workflow
    • Create workflow that calls O365 APIs
    • Deploy and configure Workflow Apps using Install Events
    • Utilize JSONP
  • Mobile Development
    • Explore O365 Mobile Features
    • Install Apache Cordova
    • Create a multi device targeted project
    • Add connected services to multi device projects
    • Run a multi-device project (Android and Ripple)
    • Install the O365 Android SDK
    • Work with Android O365 Sample Apps
    • Download required referenced SDKs (GSON, Azure AD)
    • Create an Android App that calls O365 APIs
    • Create a Windows 8.1 App that calls O365 APIs
    • Create a Windows Phone 8.1 App that calls O365 APIs
    • Create a Windows Phone 8.1 App that calls OAuth services
  • OneNote APIs
    • Registering a LiveID App
    • Download and install Live SDK
    • Retrieve LiveID Tokens
    • Retrieving Notebooks, Sections and Section Groups
    • Creating Pages
    • Creating Pages in Sections
    • Importing PDFs
    • Importing Images
    • Exploring apigee.com
  • OneDrive APIs
    • Explore OneDrive APIs
    • Downloading and uploading files
    • Getting user data
    • File and Folder properties
    • Move, copy, delete files
Posted on

My Tribute to Joseph Thomas Alvarez and his mother Maria Helen Alvarez – True Oklahoman’s

This evening I was watching "Saving Mr Banks" and it made me think about my recently passed away friend Joe Alvarez.  Joe and I met three years ago during one of my wife's and I's trips out and about in Rancho Sante Fe (specifically a little place called Dolce).  Joe was a very friendly guy and over several months we got to know Joe really well.  He loved his red wine, and of course flirting with Lidiya (but harmless of course).  Over those few months, I found that Joe had just lost his mother Maria a few months before.  He proceeded to let me know she was co-owner in the first Television station in Tulsa, OK. In addition, she fronted a lot of the money for the Disneyland Hotel (hence why I remembered Joe tonight).  As you can read in one of the links below, Mr. Disney had leveraged all the money he could to build Disneyland, so he turned to Joe's mom and her business partner to build the hotel.  Here is a picture of Joe's mom, Maria, manning a TV camera for her TV station KOTV.  For those of you that live in Oklahoma today, you still watch KOTV:

 

Here is a picture of her at the opening of the Disneyland Hotel:

 

You can read more about this incredibly smart Oklahoman woman here:

After I did all this research on Joe's mom, I brought it up about how cool his mom was one night.  He appreciated it and we talked about all his time growing up in Oklahoma.  After all, Joe had been born in Oklahoma City, Oklahoma before his mother sold the TV/Radio station and moved to San Diego.  When Joe brought up his mom, I told Joe I was born and raised in Oklahoma as well, and needless to say, there is a bond between fellow Oklahoma's similar to that of the bond people have to their country (for example, all you watching the USA in the worldcup).  After we realized we were both born and raised in Oklahoma, we became really good friends. 

We met Joe's lovely wife and his daughter Kennedy on a few occasions, both very lovely people.  We also went to Joe's house a few times, he had this really cool and massive collection of Harry Jackson bronze sculpture cowboys.  They were everywhere, small ones, medium ones and really big ones, all of them, prominently placed in a way that just made you ache for Oklahoma. And they did, every time at his house, it brought back tons of memories for me in growing up in Oklahoma.  Joe was such a friendly guy.  He invited us on more than a few occasions to sit at his finish line table at the Del Mar Racetrack (Joe was the longest standing member of the racetrack after his mother).  It was awesome walking and hanging out with Joe as he was so nice and everyone liked him.  He invited us to his friends houses (some of them incredibly extravagant, yet, all down to earth amazing people).  One fond memory I'll never forget, is competing against Joe with his horse picking skills and challenging him to see who could lose the less or make the most money at the track.  He broke under the pressure and I won…it was quite the victory, as he could read the horse stats like no one I have ever met!

I learned of Joe's death a couple weeks after it happened (I didn't get to go to the funeral, and I didn't get to say anything, which probably bummed me out more than anything).  Some of you may have seen the tweets.  It was one of the saddest feelings knowing that two special Oklahoman's (Joe and his mom), and one of my friends, had passed away leaving the rest of us Oklahoma's to lead the way in this world. I know those last few years of hanging out with Joe, he enjoyed us being around and coming over to our house for our parties.  Joe had a pretty amazing life himself, as you can read in this article, he hung out with some pretty amazing people and had a lot of cool stories (and yeah, he even talked about fish a couple of times):

This blog post is to you and your mom Joe, rest in peace my friend.  I'll try to hold the fort down…

 

Posted on

Cannot find module ‘sax’ – Cordova with Visual Studio

You may run across this error when compiling your Hybrid-App / Cordova application in Visual Studio.  One of my students got it this week.  It looks something like this:

This means that the install of the Cordova extensions did not work properly and you are missing some files.  Mainly these two:

Simply uninstall (yeah, I know it takes a really long time to uninstall and reinstall).  And the files should show up.  If that doesn't work for you, install on another machine and copy over those directories.  Then all will be fine!

Posted on

O365 and Non-ADFS Federation – It’s not O365’s fault

I'm not a fan of ADFS.  It sits right below Azure Access Control Services (ACS).  ACS used to be my favorite identity provider aggregation platform, but how times change (ref this post).  Several new players are entering the market and all of them realize the missing gaps in ADFS and ACS.  Therefore, the drive to make a better authentication toaster is ON!

The goal of this post is to make you realize that you are having the wool pulled over your eyes in terms of the bigger picture around Identity Management when it comes to O365.  To make this point, let's take a look at a typical on-premises solution:

  • A SharePoint customer wants to setup multiple site collections (yes, all host header site collections) to support different customers
  • Each customer has different requirements around supporting federated external customers
  • Some customers prefer Google as their auth, others Yahoo and others Facebook, etc

On-premises

Solving this problem with on-premises environments is a piece of cake.  You have complete control over adding trusted Identity Providers (IdP) all day long. To solve the problem above, its likely you are going to think that adding a Trusted Identity Provider for each required auth mechanism is the answer.  That would be false.  As tempted as you may be to do this, its a really bad idea to have more than one. You should ultimately have a single Identity Provider with that provider supporting multiple "Apps/Replaying Parties (in this case site collections)" that would then show different options when a user needs to auth.  This allows you the most flexibility in that you simply set the IdP once, then configure the apps in the IdP.  Totally seamless, perfect.

Office 365 and Single Sign On (ADFS)

If you had this requirement in O365, you are out of luck.  Do not pass GO, do not collect $200USD.  In terms of O365, you are by default forced to use this one IdP mentality.  For each verified O365 domain, you can only setup a single Federated Identity Provider.  In most cases, everyone I have seen has used ADFS to integrate their on-premises Active Directory to sync accounts and/or configure Single-Sign On to redirect to their ADFS proxy.  This unfortunately, is the Microsoft promoted way of achieving Single-Sign-On nirvana.  I'm not a baby swimming in a pool, so let's take a look at what lives outside the koolaid-y-ish sugar water.  If you do this (which unfortunately, you probably already have), you are locking yourself into the current limited features of ADFS and hoping that ADFS gets some much needed development attention in the future (such as supporting OAuth 2.0). That being true, ADFS is a Microsoft product, you'll find a lot of people that can help you (support and consultant resources) to get it setup within a few hours.  You could also do it yourself by using TechNet/MSDN et all. 

Office 365 and Something else

If you want to use something other than ADFS, well, you better dig in for doing a ton of research on how WS-Fed and WS-Trust works and similarly, OAuth.  If you don't have time for that, then you'll need to request the services of people that do know that space. Unfortunately, having the identity management skills matched with an understanding of the future of App Models across vendors is a rare breed of consultant.  You also have to contend with a cold hard fact:

  • Currently, Office 365 only supports users of your verified domains (such as contoso.com)

Say what?  It means that even if you wanted to use Twitter, Facebook, whatever, the people that signed up have to have used the email address from their verified domain!  Uh…say that again?  Yeah, that means you can't login with your user@hotmail.com account using Facebook.  If you signed up with your contoso.com account on Facebook, then it will likely map your email over in the claims and let you in, but that's up to how fancy your Identity Provider is.  Azure AD is expecting a very specific format of token with specific claims.  If it doesn't get them, then your login will fail.

So if you can't login using something other than a verified account, what's the point?  

I feel this is a major fundamental loss of functionality between on-premises and O365.  If I want to create a site collection with a specific relaying party app to my IP (which then provides a set of auth services), I should be able to do it. It is such a common pattern in on-premises SharePoint. I don't think the band aid of "external access" fits the bill here.  Those links that are generated can be freely sent all over the web punching small barely noticeable holes in your O365 tenant. I'd like to see the governance page in O365 that shows me every link that has been generated across the entire tenant (you can see on a site by site basis using this link – https://domain.sharepoint.com/_layouts/15/start.aspx#/Access%20Requests/pendingreq.aspx).  There is not global admin UI to tell you who has been added or what has been shared – reference notes at bottom of this article. With an IdP in the picture, you simply disable their access and now they will never gain access to anything in your environment. This would require the removal of this "external sharing" feature that bypasses Azure AD in O356.  Wow, isn't that innovative?

Can I even use something other than ADFS in O365?

Heck yeah you can!  I recommend it!  By adoptingchoosing an Identity Provider solution (whether one you install on-premises or cloud hosted) that allows for you to expand
out past basic AD accounts, you will be ready for when Azure and O365 wakes up one day to
realize they should have allowed it in the first place.  You can set this up by removing the ADFS federation and replacing it with new Ws-Fed endpoints of your IdP.  This is enabled using the following cmdlets (this one is using Auth0.com):

  • $cred = Get-Credential
  • Connect-MsolService –Credential $cred
  • Set-MsolDomainAuthentication -DomainName "chrisgivens.com" -FederationBrandName "chrisgivens.com" -Authentication Federated -PassiveLogOnUri "https://chrisgivens.auth0.com/wsfed/ID" -ActiveLogonUri "https://chrisgivens.auth0.com/ID/trust/usernamemixed?connection=yoyo.chrisgivens.com" -MetadataExchangeUri "https://chrisgivens.auth0.com/wsfed/ID/FederationMetadata/2007-06/FederationMetadata.xml?connection=fs.chrisgivens.com" -SigningCertificate "Cert" -IssuerUri "urn:chrisgivens" -LogOffUri "https://chrisgivens.auth0.com/logout" -PreferredAuthenticationProtocol WsFed 

NOTE:  If you have already setup ADFS, you'll need to disconnect from that.  I have yet to test out all the paths, but the one I choose was really painful.  I used the Remove-MsolFederatedDomain cmdlet.  This forced me to remove all users (but did not require me to remove my groups).  Once I removed all users the command succeeded, but proceeded to delete the domain completely from my tenant!  I then had to re-add it, re-verify it, then fire off a DirSync.  Once that once done, I could run the above commands and it redirected properly to my IdP.

After configuring the federation when you go to "login.microsoftonline.com" and type your verified email, it will redirect to your IdP login page.  From there, you will see all the options that you have enabled for that relaying party.  Even though you can enable all the OAuth 2.0 providers you can imagine, an attempt to login will fail miserably.  There are some current technology issues that Azure AD must resolve:

  1. Azure expects a UPN/Email that matches a user in your Azure AD (at a minimum, you would have needed to sign up for a service using that verified domain email)
  2. Azure AD is expecting an ObjectID
  3. O365 Services have to support these accounts (even if that means simply ignoring them)

For the first issue.  Azure AD would have to allow the addition of users other than your verified domain.  Or at your IP, you map a user from external to internal.  For the second issue, again, this can resolved by either Azure, or by the Identity Provider.  IPs can choose to implement this today by integrated with Azure AD to query for the object id based on a valid UPN.

Until this these items are resolved, you can certainly fall back to the "forced" way by Microsoft to use Active Directory users from a verified domain (and yes, you should feel angry about this) by setting up a pass through from your IP to ADFS/Active Directory.  The preferred way is to utilize a client on your Active Directory server (pretty much every IdP has this). As only a few of you know or will understand, if you use ADFS, you will currently lose Office Client features. But don't be worried, later this year, Office will release an update that will support SAML-P.  This will let you utilize many different types of auth (basically anything you can do via browser) with Office clients.  That will be awesome, even though users will never fully understand what just happened.

Take It Up Another Level

Home realm discovery is not extensible in Azure AD.  What is home realm discovery?  Its the login drop page that takes your context, in this case, your email domain, and then redirects you to the proper IdP.  What does it mean to not be extensible?  It means that IdP's cannot create a portal of Apps page.  What does that mean?  Think Universal Access Gateway (UAG).  Imagine UAG-like portals, only hosted by your IdP, such that an external party can login to your IdP, and are then presented with the applications (such as O365), that they have access too.  When they select it, it will immediately redirect you to your O365 site (no need to go to login.microsoftonline.com).  As it stands right now, O365 does not support external home realm discovery pages.  This is also a serious limitation that needs to be added to the road map.

Summary

If enough people push the O365 and the Azure teams to fill the gap of this major difference between the products, I feel it would fulfill many of the requirements we have with customers today and make O365 an even more popular platform!  Here is your call to action:

  • Quit using ADFS, find an IdP with an eye towards the future
  • Highly "Suggest" to Azure and O365 that they support external identities (Vote for it here on UserVoice)
  • "Suggest" to Azure that they allow tenants to have a custom home realm discovery page

Stay classy internet,
CJG

 

 

Posted on

Errors when Installing DirSync.exe

I ran across two different errors with DirSync today.  The first had to do with the fact that I had DirSync on a computer previously and then re-installed it.  Because of this, I received this error:

System.Management.Automation.CmdletInvocationException: Access denied  —> System.Management.ManagementException: Access denied
   at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
   at System.Management.ManagementObjectCollection.ManagementObjectEnumerator.MoveNext()
   at Microsoft.Online.DirSync.Common.MiisAction.GetTargetMA()
   at Microsoft.Online.DirSync.Common.PrerequisiteChecks.ThrowIfSyncInProgress()
   at Microsoft.Online.Coexistence.PS.Config.SetCoexistenceConfiguration.VerifyMachinePreRequisites()
   at Microsoft.Online.Coexistence.PS.Config.SetCoexistenceConfiguration.BeginProcessing()
   at System.Management.Automation.Cmdlet.DoBeginProcessing()
   at System.Management.Automation.CommandProcessorBase.DoBegin()
   — End of inner exception stack trace —
   at System.Management.Automation.Runspaces.PipelineBase.Invoke(IEnumerable input)
   at Microsoft.Online.DirSync.PowerShellAdapter.PowerShellCommand.ExecuteCommand(Command command, Boolean refreshPath)

Looking a little deeper, it turns out that DirSync install will create a user account and then add it to other created local groups.  This is all very similar to how SharePoint installs because both DirSync and SharePoint use MIIS. Because I had already installed DirSync at some point in the past, the account existed, but I'm guessing the password was out of whack.  Since I wasn't sure how to reset the password (and didn't want to spend the time to figure it out), I defaulted to uninstalling everything, deleting that user, rebooting and re-installing. Done.

But it didn't end there.  I was attempting to install a secondary DirSync machine as a cold standby, but was getting an error when attempting to configure it:

System.Management.ManagementException: Generic failure
   at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
   at System.Management.ManagementObjectCollection.ManagementObjectEnumerator.MoveNext()
   at Microsoft.Online.DirSync.Common.MiisAction.GetTargetMA()
   at Microsoft.Online.DirSync.Common.MiisAction.IsSyncInProgress()
   at Microsoft.Online.DirSync.Common.PrerequisiteChecks.ThrowIfSyncInProgress()
   at Microsoft.Online.DirSync.UI.IntroductionWizardPage.PrerequisiteValidation()
   at Microsoft.Online.DirSync.UI.IntroductionWizardPage.OnLoad(EventArgs e)
   at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
   at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
   at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
   at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
   at System.Windows.Forms.Control.CreateControl()
   at System.Windows.Forms.Control.WmShowWindow(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

This means that the DirSync tool was not smart enough to tell you that you were installing it on a SharePoint server (which I didn't realize I was doing) with the ForeFront services already installed.  When you attempt to do this, you will overwrite your SharePoint ForeFront settings with the account mentioned above and then the two will fight over the service.  Obviously, this is bad.  I hadn't really done much research on some of the best practices around DirSync so its a bit of shame on me, but I also didn't find answers to these errors on the web when I google/binged them, so I'm making a mental blog note for others.

Posted on

Eliminate App Web Part IFRAME issues – Use App Installing

I have had a few different conversations with people about the whole App Web Part IFRAME problem lately.  Basically this problem means that you can't make calls outside the IFRAME using your code (it is a security feature of browsers).  This leads to the whole, "how limiting it is blah blah" conversation.  I simply say to them…why are you doing it like that? 

Most people think that using the App Model means that you are constrained to the boundaries that the App Model enforces.  The truth is, you are not.  If you are building useful "longtail" apps for companies, you should realize, the App Model doesn't need to be used as it was originally intended. You can utilize its deployment mechanisms to get your files to the host web.  This pattern is a part of one of the labs in the O365 Dev course.  For example, if you have a workflow that needs a well defined url for external communication (ie the random app web url won't work [think redirect urls]), you can deploy all of the content of the workflow to the host web and then run it from there (no app web needed at all, as a matter of fact, you could delete it completely after deploy).

How do you do this?  Use the App installing event handler.  As part of the App Model and the Visual Studio project, you can create an App installing event handling web which will get called and pass an access token to make calls back to the app and host webs.  Once you have that, the sky is the limit.  You don't have to deploy your code to the app web, but simply copy it from your web server to the host web.  In this essence, you are simply using the App Model as a "means to an end".  This will eliminate all your app web part IFRAME woes.

Posted on

O365 is not secure

I used to think it was.  After all the amazing things you read on the O365 Trust Center, you all but think it is Fort Knox (well, at least one part of it is right Bill Baer?) 

Let me go back to that title. "O365 is not secure…once you start adding users".  Last week I blogged about a security oversight in O365's partner sharing feature.  Basically what this means is that once you accept an invitation from a partner (aka a "user"), you become just another customer in their "customer management" portal. You can read more about this feature here:

http://blogs.office.com/2014/01/28/introducing-the-new-office-365-partner-admin-center/

Do you know who else they have as customers and who is accessing your data and when?  No. They don't really have any logs to tell you when a partner is accessing your portal for accountability.  Nor do you know who on the backend is working on your O365 deployment project.  Just too many unknowns to say it is secure.

O365/Azure Apps

But that's not the focus of this post.  A few weeks ago, O365 released the O365 APIs for Exchange (Mail, Contacts, Events and Files).  All of this piggybacks on Azure Active Directory for authorization utilizing the Consent Framework.  The Azure AD platform allows you to build an application that can make calls to Azure Active Directory or your O365 data. The permissions of the consent framework can allow an application to read the current mail item, all your mails items, your contacts, your calendar…your files. 

As a simple example, one of the more impressive abilities is to create a Mail App.  You can do this using Visual Studio 2013 and creating an App for Office project.  This isn't going to be a developer post so I'm not going to show you any code, but simply talk about the importance of "Mail Apps" and your users.

Once you have a Mail app created, you can deploy it to your O365 instance, or even post it in the Office store.   You can find a small set of mail apps in the following link (these have been publicly deployed to the office store, but you can have rogue apps that simply are registered somewhere in Azure AD and users give them ad hoc permissions):

http://office.microsoft.com/en-us/store/apps-for-outlook-FX102804983.aspx?app=outlook.exe

Many of these are poorly designed (for example, the LinkedIn app is a total disaster, the cert is locally generated and not even a public CA).  In some cases, you may find the deployment endpoint isn't even available so the app install fails.  If you were to install one of these apps, you will find that they simply request access to the "current" mail item.  This is the preferred scenario if you were to use these apps.  In some cases however, you may find that the app is given "carte blanche" to your entire mail inbox.

So back to users and mail apps.  When you are in your Outlook, your users will ultimately find the settings icon and this nice menu item called "Manage Apps":

 

Clicking on this, they will be taken to the "Exchange" app center.  This is where you see administrator installed apps and user installed apps:

 

This is JUST for Exchange.  This has nothing to do with the bigger picture of Azure AD Apps and the consent framework.  There are some governance controls implemented in the Exchange app architecture, however, when it comes to Azure AD and your tenant, the story hasn't been written yet. This goes back to the premise of this blog post.  All it takes to make your highly secure O365 environment to be unsecure is:

  • A user
  • An App
  • A click 

The permissions given to that app can now comprise the integrity of your entire system.  When on-premise, you at least had the ability to prevent incoming requests using your router and DMZ.  In this instance, O365 doesn't have any of that, so once permissions have been given, that's all folks.  So what hacking scenario might come up?

  • Hacker builds an Azure app, puts your company name and logo on it
  • Hacker does some social engineering to find out your name, title, work phone number and other information
  • Hacker asks you to install the app and because it has your logo and company info, your user thinks nothing of it and clicks "trust"
  • Hacker can now gain access to an access token that can be used to download all your email and your my site files

If you are in defense or government, you know hacking enemy number one is China.  For those of you that think that insensitive to say, you haven't watched the traffic logs with the FBI and CIA as it happens, almost on a daily basis.  But the US is not a good guy when it comes to that stuff either, so all is fair in love and war.

O365/Azure App Governance

It is my suggestion, that you disable the ability for users to add apps.  It simply creates security holes that equate to users writing company checks that can't be cashed.  So, with that recommendation, can I provide you the steps to deny a user the ability for users to add apps" in your tenant, *sure*, thanks to some recently surfaced info (see below) [:D] (thanks to @richdizz, @jthake and @Matthias1o1) In terms of Exchange, there are some user roles in Exchange that you can "remove" to prevent users from deploying apps, these roles are enabled by default:

 

————————
[UPDATE 6-5-2014] After this post the following was brought to my attention from the O365 team.  It is a non-UI based way to disable all user consent, thanks to the O365 team for pushing this content out!:

http://blogs.msdn.com/b/exchangedev/archive/2014/06/05/managing-user-consent-for-applications-using-office-365-apis.aspx

————————

Even with the above update, what is still not available to us is an Azure AD UI (to make it more apparent of the risk) that allows me to
disable apps, and/or designate a "safe/white list" of apps that my users *can* utilize in Exchange or Azure AD.

Just for kicks, I have created a UserVoice suggestion that more advanced App Governance features (such as a UI and white list) be added to Azure AD and O365, you can vote for it here:

http://officespdev.uservoice.com/forums/224641-general/suggestions/6010008-create-app-governance-in-o365-azure-ad

My God, What Have You Done?

So, this brings up an interesting point.  Last night at the SanSpug.org meeting I announced that we have moved to Auth0.com as our auth mechanism as it provides the most flexibility and telemetry data.  One person asked, what is telemetry data?  I said every time you login, I get data about you (first name, last name, email, blah blah).  It freaked out half the group.  Only one person was educated enough to know which of the supported auth systems had the least amount of data being sent.  So again, this brings up that interesting point I started this paragraph with…do you know what apps you have simply just clicked on the "authorize" button just so you could use the app?  I bet you don't, my god, what have you done?  Think about all those apps across all your services (facebook, twitter, liveid, google, etc).  So in an effort to help you understand just how bad this is going to get with O365, based on how bad it has gotten in a general sense, here is the links to where you can check what you have authorized for each of the major platforms:

Facebook:

https://www.facebook.com/settings?tab=applications

Twitter:

https://twitter.com/settings/applications

Google:

https://security.google.com/settings/security/permissions?pli=1

LiveID:

https://account.live.com/consent/Manage

eBay:

http://cgi6.ebay.com/ws/eBayISAPI.dll?ManageESubscriptions

Yammer:

https://www.yammer.com/YOURDOMAIN/account/applications

SharePoint:

I suppose you could say that this page (http://youweburl/_layouts/15/viewlsts.aspx) is as close as it gets?  At a farm level, in O365:

https://yourdomain-admin.sharepoint.com/_layouts/15/TA_AllAppPrincipals.aspx

On-premises:

http://centraladminurl/_admin/AllAppPrincipals.aspx

Azure AD:

https://myapps.microsoft.com

Back to the question…"My god, what have you done?"  After clicking on all those links, I'm sure you have an idea of just how bad the problem has gotten.  Some of you might be surprised to find out that your Hotmail/Outlook.com email and OneDrive (consumer) files have probably already been downloaded and analyzed by that cool app you gave permissions too.  Most of you that read my blogs are the cream of the intellectual crop.  You understand what that "Trust" dialog means.  For the rest of the population, not so much.  The meaning of the word "Trust" has been eroded by fancy graphics and the promise of a simple functionality at the expensive of selling your data soul to the app provider.  That all being said,  its time for enterprise solutions to have a "white list" to keep users from eroding the meaning of "Trust", to anyone's dog or cat.  One last thing on O365, no matter how secure you make the back end, its the front end that matters.

CJG

Posted on

Apache Cordova, Apache Ripple, Visual Studio 2013 and O365 APIs

"Mobile first" has become a common theme these days and building code and applications that you can write once and deploy to multiple target platforms is a key to achieving reach and use for your backend platform.  With the O365 APIs being release a few weeks ago, you can now do REST development against O365 exchange services (Mail, Contacts and Calendar, however, no Tasks yet).  A lot of focus has been on putting out samples for the various mobile platforms (Windows Phone and Android as the top two).  That being said, let's take a look at these Android examples and then the new Apache Cordova project templates. 

Android:

The Android SDKs that you can download here need some serious help in order to get them loaded into a Java IDE (such as Eclipse Kepler).  For example, not only do you need the Active Directory library, you also need several Google SDKs (yeah, I said Google).  In order to get all the examples working, you need to download the following:

Once you have all these, you can extract the O365 SDK and you will notice several projects that you can import into Eclipse (you will notice that all of them have errors, this is because you need to add the referenced JAR files to the project build path):

 

Each project will need the "com.microsoft.adal", "office365-base-sdk", json-2.2.4" and "guava-16.0.1" JARs.  Once you have these added, you will notice that all the projects now show no errors.  You are now free to select a project and run it. The first app is called the "Asset Management" app:

 

Opening the application allows you to start configuring it:

The authentication options can be of three types:

Azure Active Directory (AAD) is the OAuth method. Selecting it will allow you to utilize redirection to O365 login page and then back to your application.  Once you have authenticated, you can click the "Show Cars" button:

It simply makes a call to a SharePoint picture library called "Cars" (that you have to create and add items too) to show you the picture of the car and its description:

In addition, there is a "File Discovery" application.  This can be configured by modifying the "Constants.java" file (which is a common thing across the apps) by adding your client id and secret.  Once you have updated the files, running the app will show the following icon:

Once open, you will see that it queries the discovery service and shows all your services (via the Discovery API):

Clicking on the Files service will show you your OneDrive for Business Files:

You may find that you keep getting an exception around the dialog.dismiss method.   This is a bug in the code, all you have to do is wrap it in a try catch block and the code will run ok.

There is also a mail app (but it doesn't have a .project file so it won't import as a project).  Unfortunately I was never able to get it to work because it kept throwing memory errors, but supposedly you can also get it to show you your mail. You will also need a couple of extra JAR files to get it to compile:

Apache Cordova:

Not into building platform specific Apps like the Android ones above?  That's where the Apache Cordova platform comes into play!  If you do a quick Google search, you will find this site:

http://cordova.apache.org/

This site simply describes itself as "A platform for building native mobile applications using HTML, CSS and JavaScript".  Basically what that means is that it is a translation middleware of common web standard elements as common inputs and then transform your code to a target such as Android or Windows Phone.  The neat part is that Apache Cordova is now integrated into Visual Studio 2013 Update 2.  You can download the Apache Cordova project extension here:

http://www.microsoft.com/en-us/download/details.aspx?id=42675

This will give you the ability to create Hybrid Apps:

 Once you have created a Hybrid App, you will see the following in your Solution Explorer:

In Visual Studio, you will have a set of target devices and also the ability to specific your debug target:

 

Notice here, the "Ripple" debugging target.  Before you start debugging, you can modify the supported features of the target device via the App Manifest's "Plugins" tab:

 

 Now this is where things get interesting.  You can right-click the project and select "Add->Connected Service".  From here you can add either "Windows Azure Mobile" or "Office 365" services. 

 

The view is similar to if you were doing an MVC or Web Application Project, but the output is VERY different.  What you will notice is several folders and JS files are added:

 

The above "settings.js" does some initialization of the O365 SDK. The remainder of the files have some pretty powerful code in it that all but builds your application logic!

 

Once you have all of these files in your project, you have to add them to your "index.html" page:

 <body>
    <p>Hello, your application is
ready!</p>

    <!-- Cordova reference, this is
added to your app when it's built. -->
    <script src="cordova.js"></script>

    <!-- cjg699 references -->
    <script src="./services/mobile services/cjg699/service.js"></script>

    <script src="scripts/jquery-2.1.1.js"></script>
    <script src="services/office365/settings.js"></script>
    <script src="scripts/aadgraph.js"></script>
    <script src="scripts/exchange.js"></script>   
    <script src="scripts/o365adal.js"></script>
    <script src="scripts/utility.js"></script>   
    <script src="scripts/index.js"></script>
    <script src="scripts/o365.js"></script>
   
    <input type="button"
id="btnGetEvents" name="btnGetEvents"
onclick="GetEvents();" value="Get Events" />
    <br />
    <br />
    <div id="Events">
    </div>
</body>

Once that is done, you can add your own O365.js file with your logic.  In this case, I am simply making a call to get the events:

function
GetEvents() {
    var authContext = new
O365Auth.Context();
   
   
authContext.getIdToken('https://outlook.office365.com/')
    .then((function (token) {

        // authentication succeeded
        var client = new Exchange.Client('https://outlook.office365.com/ews/odata',
token.getAccessTokenFn('https://outlook.office365.com'));

       
client.me.events.getEvents().fetch()       
        .then(function (events) {
            // get currentPage of
calendar events
            var myevents =
events.currentPage;

           
$("#Events").empty();

            for (i = 0; i <
myevents.length; i++)
            {
               
$("#Events").append("Subject: " +
myevents[i]._Subject)
            }           

        }, function (reason) {
            console.log(reason);
        });
    }).bind(this), function (reason) {
        console.log(reason);
    });

}

 Pressing "F5", Google Chrome will start with the Ripple emulator:

 

You can now click on the "Get Events" button which will attempt to execute the code, but first direct you to provide consent:

Clicking on "Get Events", you will see your mail:

 

One important note, the JavaScript code will cache your access token.  If you didn't get your permissions setup properly, then you'll have a bad token cached.  You will need to call the "SignOut" method to clear the CacheManager and the bad token as they don't expose the CacheManager directly.

If you wanted to test on Android, you would simply change the drop down target and press "F5" again.  It would then attempt to start the current Android SDK Emulator and upload the APK file, you would see exactly the same UI and button and the same results!

Unfortunately, at the moment, the JavaScript API for O365 is only provided in the Hybrid Apps project and is not really compatible with the other project types (such as MVC).  Apache Cordova, the Ripple emulator and project templates such as Hybrid and Cloud Business Apps are the future of application development!

Posted on

Azure Access Control Services (ACS) is dead

I recently went through the exciting process of setting up our SanSpug.org site to support various authentication mechanisms (LiveID, Google, Federated Auth, etc).  I started off using Azure Access Control Services (ACS) because I thought it had everything I could ever want in a login aggregation platform.  However, I soon realized that it just wasn't able to meet the simple needs of a small SharePoint User Group.  And now that I know it can't meet those needs, I doubt it really meets the needs of large organizations either. 

A bit about ACS

To be fair,  ACS was the first of its kind.  I remember when it was first released, it was sooooo cool.  It really was.  I built some cool labs off of it (the old UI), then the UI "disappeared" (at least, the link was gone from Azure at one point), only to reappear again in the latest incarnations.  ACS isn't a part of the main Azure portal.  It has its own interface, which has confused me to this day being that all the other services are moving into the current portal.  Here's a screen shot of the two:

 

Why they are separate probably has to do with (put some random excuse here, but likely because of "legacy" configurations). It would make much more sense that Azure added ACS as its own separate application in the Azure Portal. 

So what can we do with ACS?  If you are familiar with ADFS, then you get the point.  I can created "Identity Providers", "Relaying party applications" and claims rules between the two.  The latter being one of the strengths of ACS (Quick history lesson, ADFS 1.0 was a real piece of junk, that left only one option, that option being ACS. It could do all the things that ADFS 2.0 was about to do).  So what kinds of identity providers can we add?  Well, here they are:

 

Hmm, interesting.  So they have preconfigured providers for LiveID, Google and Yahoo.  Fair enough, those don't actually need an application (client id and client secret) created for them.  But "Facebook".  Ummm, that one needs an app created for it to do federated auth.  Ok, let's do it.  Added a facebook app used to be fairly easy back in the day, now the UI sucks.  And the process to get a simple "App Stub" created requires a canvas page?  Whatever.  Fail on facebook's part.  Ok, back to ACS.  So they are allowing us to do federated auth to OAuth providers.  Ok.  So how do I add others?  Like Twitter?  Maybe Yammer?  Oh…YOU CAN'T!  But you can do WS-Federation all day long.  Boring.  Oh, did I mention the Google one doesn't work anymore?  Yeah, Google seems to have disabled the interface that ACS was using.

Ok, so ACS is dead "to me".  So what do I do now?  Do I build my own?  Ugg, that means I need to register an app in EVERY possible OAuth provider on the planet.  Similar hoops to jump through (approve the app, screen shots, canvas page, terms…ugg, no thank you). 

Let's do some research, maybe someone built a better ACS?  Maybe someone did all that work to register an app EVERYWHERE? After a few google searches, some tweets…I find….Auth0.com. 

Auth0 is the ACS killer.  I have no doubt that after the right people at Microsoft see what they have built, Auth0 will be picked up in a M&A transaction.  I'm going to tell the guys to hold out and get 4-5 offers and bid the price up.  I have no doubt, they will go for $100Ms in a liquidity event.  So why are they so cool?  Because you can add ANYTHING!  Check this $^&%^% out!  Database, Social and Enterprise:

Database (think ASPNETDB – this is a biggy for SP2015 by they way):

 

Social (oh right…ACS gives us…Facebook…totally lame):

 

Enterprise:

Wait…do you see the one at the bottom?  Yeah…that's SharePoint Apps for on-premises (courtesy of Chris Beckett consulting services).  Oh…do you see the O365 and Windows Azure AD one?  Oh yeah…that's Azure AD Apps…umm, so why are you using ACS again?

Telemetry and Metrics

Are you freaking kidding me?  ACS would never have thought this up.  You get telemetry on when and how your users are logging in:

 

The logs are also pretty sweet:

 

You see the profile JSON response in the Logs that contains the Access Token (if provided) so if you need to debug something, you have everything you need!

 

Wait…it gets better (but maybe a bit confusing for you that haven't been doing this stuff for a while).  In addition to allowing your Apps access to all these federated OAuth platforms, it itself is an App registry.  You can create your App in the Auth0 interface, which is then exposed as a WS-Federation end point!!!  Holy $%&^&$^!  Forced to use ACS, but you think it sucks like I do?  Hey…add your Auth0 WS-Federation endpoint, and just like one of those "I saw it on TV adds", "Set it and forget it!":

 

APIs:

Oh baby…if they weren't already ahead of the competition.  This is the future.  Forget about all those APIs you have to write to and learn.  Why bother with the auth parts?  All you need is to call the API and get that JSON response back.  Here's what they support:

 

Rules:

Do you have some ACS rules?  Yeah, they support that too…what they don't have is an ACS rule importer.  That would be so slick. Easily migrate from crappy old ACS, to shiny new Auth0:

 

Custom Emails:

Just to add insult to injury…woah…custom emails…custom whatever!  When someone hits your fed auth endpoint…send em an email based off the claims!

 

Is ACS Dead?  Yeah, to me it is.  To the masses that didn't know any better, consider yourself educated.  As the word spreads, I'm sure there will be a mass ACS exodus very soon!

Chris

Posted on

OneDrive vs OneDrive and OneNote vs OneNote – Why the disconnect?

So you think you know OneDrive eh?  If you were knowledgeable, you'd ask, which of the three?  Maybe you knew that, maybe you didn't.  But I'd venture to say that many don't really understand the programmatic aspects between the various versions.  Additionaly, since I'm going to talk about APIs, I might as well throw the OneNote API into the mix.  One Drive exists in three states:

  • OneDrive for business (the version that runs in your O365 tenant)
  • OneDrive Pro (the version that runs in your on-premises environment)
  • OneDrive Consumer (the version that runs in your LiveID environment) 

OneDrive for business and OneDrive Pro are simply SharePoint document libraries that exist in your My Site.  The APIs for gain access to these are as "simple" as making basic document library API calls for any SharePoint document library.  These SharePoint file APIs are documented here:

 http://msdn.microsoft.com/en-us/library/office/dn292553%28v=office.15%29.aspx

Notice that you must specify the url of the site (in this case it is your My Site url) in order to give context to API calls.  For a typical O365 instance, this looks like:

"https://acs579-my.sharepoint.com/personal/givens_acs579_onmicrosoft_com"

All REST calls and CSOM will need to be instantiated with this url. Now consider folder nagivation.  In SharePoint, you must use the "GetFolderByServerRelativeUrl" method on the web object. An example of this call looks like this:

https://acs579-my.sharepoint.com/personal/givens_acs579_onmicrosoft_com/_api/web/GetFolderByServerRelativeUrl('/personal/givens_acs579_onmicrosoft_com/Shared Documents')

Umm…does anyone else think this is a super long and incredibly dumb way of getting to a file folder?  Yeah, thought so.  Let's take a look at a typical OneDrive consumer API call, which are documented here:

http://msdn.microsoft.com/en-us/library/windows/apps/hh826531.aspx

As an example, to get your current one drive folder, one simply has to do a GET to:

https://apis.live.net/v5.0/me/skydrive (yes it is still called "skydrive")

Wait, do you see that?  Instead of "https://acs579-my.sharepoint.com/personal/givens_acs579_onmicrosoft_com/_api/web/GetFolderByServerRelativeUrl('/personal/givens_acs579_onmicrosoft_com/Shared
Documents')" it is "me".  Woah, what a concept. 

Now let's look at getting a file or posting a file.  Each file and folder has an id.  To get a folder, you simply do something like:

GET https://apis.live.net/v5.0/file.a6b2a7e8f2515e5e.A6B2A7E8F2515E5E!114
GET https://apis.live.net/v5.0/folder.a6b2a7e8f2515e5e.A6B2A7E8F2515E5E!114

Instead of…oh nevermind…its waaaay tooo long to copy and paste.

The implementation of file operations in SharePoint is horrendous and needs a total overhaul.

Now, let's take a look at OneNote.  In SharePoint, every site can have a OneNote notebook.  This notebook is rendered and edited using Office Web Apps and the OneNote.ashx handler.  Many of the features you have come to love work using the browser, but alas, we have zero programmatic capabilities. In contrast, the OneNote for consumer has a massively beautiful API to it as you can see here:

http://msdn.microsoft.com/EN-US/library/office/dn575421%28v=office.15%29.aspx

Wow, the ability to create and post to pages using a super simple HTTP REST API.  The OneNote endpoint is simply:

https://www.onenote.com/api/v1.0/pages

They are putting massive dev time into this API, but I'm afraid we won't be seeing it anytime soon in O365 or on-premises.  Check out the list of features coming via the OneNote blog (that's pretty amazing set of upcoming features):

http://blogs.msdn.com/b/onenotedev/

What should you do?

Vote for the OneDrive implementation of "me" here in UserVoice:

http://officespdev.uservoice.com/forums/224641-general/suggestions/5983861-migrate-onedrive-apis-to-sharepoint-online

Vote for the migration of the OneNote APIs here in UserVoice:

http://officespdev.uservoice.com/forums/224641-general/suggestions/5983855-migrate-onenote-apis-to-sharepoint-online

Additionally, if you are an MVP:

Make sure that you express your extreme disappointment when they send out emails saying O365, yet talk about LiveID consumer features.  It is extremely disrespectful to waste our time like that.