Migrating an Office Task Pane App to a Toolbar Add In

If you’re one of those less-informed people, like myself apparently, you may have recently received an email or otherwise found out that the Office task pane app you published in the Office Store a while ago is no longer in compliance.  It is now a requirement that any task pane apps that were previously submitted – back when that was the only app form factor available – need to be refactored to support the Add In toolbar model.  This announcement was easy to miss since it only appeared rather randomly once on some Office team blog.  Rather ironic given that this comes from the team that provides so many office communications tools.

But I digress…once you find out you need to update your app to support the new model (as well as the old model, since not every single customer is on Office 365 and/or Office 2016), how do you do it?  Unfortunately the fine folks that made this policy change neglected to provide a guide on how to do so.  They merely provide links to very general and fairly vague documentation, so since I just went through this process I thought I would capture it for others who may need to do the same thing.

Here are the steps I went through to move my Outlook task pane app to the Add In toolbar model.

Step 1 – Get the latest version of the Office Tools for Visual Studio

The actual location to get this may vary depending on your locale and version of Visual Studio, so I’ll just leave it at “go get it and install it”.

Step 2 – Start Working with Your Application’s Manifest File

Interestingly enough, once the latest tools are installed, it’s actually gone a step backwards from a tooling perspective.  When I double-click on my app manifest in Visual Studio 2015 now, it no longer opens the visual designer that lets you set attributes in your manifest.  Instead it just opens the underlying Xml file and you get to edit Xml by hand.  I could swear I’ve seen this before…oh wait – I did – like 15 years ago.  Visual Studio does at least provide some editing advantages over Notepad, so there is a certain amount of forward progress.

Step 3 – Update the top-level OfficeApp Element

The main change needed to the manifest file is going to be to add a VersionOverrides node and populate it with the correct data.  Note that you can keep all of your existing content in your Xml file, which you’ll actually want to do to ensure that it is supported on clients that do not have Office 2016.  In order to add the VersionOverrides node though, you first need to update the top-level OfficeApp element.  This is to add some namespaces that are needed to support the content in VersionOverrides.  Here’s an example of my new OfficeApp element:

xml0

One important point to note:  my element includes the “mailappor” namespace and is of type “MailApp”.  If your app is not an Outlook add-in, then the values you will need to add will be different.  While I could try and point you to some documentation, I actually recommend doing this to make sure you have it exactly right (I found the documentation to be a bit painful):  just create a new project in Visual Studio for an Office Add In that is the same type as the one you are updating.  Then you can grab the correct namespaces and types from the Xml file for the manifest it creates.  Much quicker and easier than searching for and through sketchy documentation.

Step 4 – Add the VersionOverrides Node at the END of Your Existing Content

Here’s something that isn’t at all obvious – you can’t just add the VersionOverrides node anywhere in your app’s manifest.  You need to add it at the end – after any Rules you may have (like in a Rule node), which is after your Permissions node.  Your VersionOverrides node may be perfectly formed, but if you place it any higher in the manifest, you will get an Xml validation error and your life will suck.

Step 5 – Add Your VersionOverrides Node and Start Editing

For this step, I’m just going to paste in a big bunch of Xml and then start talking through what it is and how it’s all linked together.  So to begin, here’s the Xml – both some stuff from my original manifest file and the new VersionOverrides node:

  xml1

Okay, let’s start breaking some of this down.

Step 5.1 – The VersionOverrides Node

My VersionOverrides node looks like this:

xml3

The main thing I want to point out here is the namespace.  Again, my app is an Add In for Outlook, so it uses that namespace.  If your app is not for Outlook, it will be different.  Again, look at the content in your sample application you created above to get the correct value.

Step 5.2 – Set All of the Common Property Values

Within the VersionOverrides node, there’s a chunk of properties that will likely be used in different form factors – for example reading a message, composing a message, reading an appointment, etc.   So let’s look at this chunk of Xml:

 xml2

As you can see, these are the resources for your app – icons, icon titles, tool tips, that sort of thing.  You’ll notice that you need icons that are 16×16, 32×32 and 80×80.  Add those to your Add In’s web site and then plug in the Url.

For the functionFile I cheated…just meaning I don’t have any UI-less triggers, so I just plugged in the home page for my Add In’s site.  If you have a javascript file for this, then you would put the Url here.

The ShortStrings and LongStrings section are where you put the strings that will be used for the icon titles and tool tips.  Plug in whatever is appropriate for your app.

Now, here’s an important one – look at the item with the id “messageReadTaskPaneUrl” – THIS is where you plug in the Url that you used before in your original task pane app.  For example, I’m going to paste in side by side here a couple of chunks of Xml from above.  The first one is for my original task pane definition, and the second one is my messageReadTaskPaneUrl node:

xml6

Hey look – the Urls are the same!  Finally, starting to make some sense.

Here’s the big thing that is not clearly called out in the documentation – look at the id’s all of the elements in the resources section.  You’re going to plug these same id’s in when you declare the various form factors your application supports – such as message read, message compose, etc.  Let’s see how that works next.

Step 5.3 – Add Your Form Factor Implementations

This step is what ties it all together.  You create a definition for each form factor you want to support, like Message Read, Message Compose, etc.  I’m going to paste in the Xml for one of my form factors below and then talk through it:

xml7

Let’s look at some of these individual elements now:

  • ExtensionPoint xsi:type – this is what defines the form factor, in this case Message Read
  • Label resid=”groupLabel” – this corresponds to the ShortString I have in the resources section with the id “groupLabel”
  • Label resid=”paneReadButtonLabel” – this corresponds to the ShortString I have in the resources section with the id “paneReadButtonLabel”
  • Title resid=”paneReadSuperTipTitle” – you probably get this by now – corresponds to the id in ShortStrings
  • Description resid=”paneReadSuperTipDescription” – again, guessing you understand here. What you’ll see is the icons you’ve defined show up in the toolbar (in the Outlook 2016 client) or in the Outlook Web Access UI.  In the toolbar the icon will have the title I put in the “paneReadSuperTipTitle”, and when you hover over it you will get a tooltip that contains the paneReadSuperTipDescription.
  • Icon node – you’ll see the three different icons, with each one pointing to the different id’s that were added in the resource section.
  • Action – this is the money node – the SourceLocation has a resid value that points to the id in our Resources section with the Url that we used in our task pane app; in my example that’s https://weatheroutlook.azurewebsites.net/AppRead/Home/HomeRead.html.

That’s really it – once you understand how all the pieces relate to each other in the manifest file, then it’s really pretty simple to add other form factors (or ExtensionPoint nodes as they’re called in the Xml).  After that, you just need to click the Publish item on the shortcut menu for your App project and click the Package the add-in button.  It’s a little silly because all it does is open a window with your manifest’s Xml file.  Then you can click the button at the bottom of the page to Visit the Seller Dashboard, update your manifest, and you’re done!  Just wait for it to get through the validation process successfully and your Office Store application will be updated.

That’s it – hopefully you can use this guide to walk through the process of updating your own applications.  I’ve uploaded my own manifest file so you can see the entire thing and hopefully it will help you see how it all plugs in together – you can get it from https://1drv.ms/u/s!AEFcZajG99GWlIYw.  In case it doesn’t automatically download for you, look for the WeatherOutlook.zip file. Good luck!!

 

Know When Your Office 365 Email Gets Stuck in Transit From Office365Mon

One of the things that we’ve done from day one when monitoring Office 365 is to let you know if your Exchange mailboxes are working or not.  While that’s an absolute necessity and quite valuable, it still left part of the story untold – until now.  One of the things we heard from customers is “my mailbox seems fine, but I sent an email 30 minutes ago and it hasn’t arrived yet”.  Or “I was told they sent me an email a couple of hours ago but I haven’t seen it yet”.  For those that have witnessed this behavior before, you know that sometimes email gets stuck in transit.  Your mailbox may be working fine, but if messages aren’t going out or coming in, then it can be a real problem.

At Office365Mon.Com, we’re addressing this with our new Email Transport Monitoring feature.  The Email Transport Monitoring feature lets you monitor both outbound messages – those that you send – and inbound messages – those that you receive.  You can set a delivery time for each direction, and if our health probe messages don’t arrive within that timeframe, we’ll send you a notification.  Like all of our other notifications at Office365Mon, that can be emails, text messages, and/or our webhook service.

Configuring monitoring for your email transport is incredibly simple.  Go to our web site and start here:  https://www.office365mon.com/Configure/EmailTransport.  This is a screenshot:

configemailtransport

It’s pretty simple – if you want us to monitor email transport, just check the box and tell us how long to wait before notifying you when a message doesn’t show up.  If you don’t check the box, then we won’t monitor it for you.

Once we’ve started monitoring it for you, there are some very nice reports you get.  To begin with, you’ll see the message delivery times for everything we’ve been monitoring over the previous 12 hours:

emailtransportrecent

In addition to that, you get monthly summary numbers so you can see what your delivery times have been:

emailtransportmonthly

Also, we have a report that shows you every message that was so slow it triggered a notification, so you can always review the history of when you had issues.  In addition, you will see email transport performance information rolled up into our Power BI reports.  The raw data for these reports is also available for download from our site if you have the Report Data feature enabled, and you can also programmatically retrieve it via our reporting REST API.

This is another in a long line of customer suggested features we’ve implemented.  Like the others, it’s a super scalable cloud-only monitoring feature that doesn’t require you to install any software, anywhere.  It’s available today as a Preview feature on our site at http://www.office365mon.com.  Just go to the Configure menu and click on Email Transport Monitoring – then check the boxes for the directions you wish to monitor.  All customers get this feature free to try for 90 days so check it out and let us know what you think.  After 90 days you can get this feature with our new Enterprise Platinum license.  See our site at https://www.office365mon.com/Products/Pricing for more details on pricing.

As always, thanks so much for all of the great suggestions.  We listen and continue to build on your needs.

From Sunny Phoenix,

Steve

Office365Mon Now Provides Reports Anywhere with Dashboard Reports

One of the most common requests we receive at Office365Mon has to do with the different types of reporting we provide on the availability and performance of a customer’s Office 365 tenant.  There are dozens of reports out of the box, as well as snapshot reports with the up to the minute availability of these services, and many of our customers have asked how they could get these reports for their own internal web sites.  Today we are announcing a feature to do exactly that – the Dashboard Reports feature from Office365Mon.

The Dashboard Reports feature is designed to let you take the virtually all of the reports available in our site that we get when we monitor Office 365 for you, and add them to any web site you wish with literally a single HTML tag.  In addition to being simple though, it’s also secure.  In order to use Dashboard Reports, you need to go to the Office365Mon site and get a secret key that is required to display Dashboard Reports.  That prevents anyone else from displaying your Office365Mon data.  In addition, you can remove and add keys as needed, so if a key is compromised at some point you can quickly and easily remove it.

In addition to the reports that we’ve had in our report gallery, the two most common requests we had from customers who want to display data in their own internal sites has been the current status information widgets from the My Info page (https://www.office365mon.com/Features/MyInfo).  To enable the display of these widgets in the Dashboard Reports features, we created two new reports and added them to the report gallery.  They display the same information as you find on the My Info page, and look like this:

Service Status

serviceinforpt

Tenant Status

tenantinforpt

Complete instructions for adding reports to your site using the Dashboard Reports feature can be found here:  https://www.office365mon.com/Configure/Dashboard.  It takes just a couple of minutes to create a key to use with your Dashboard Reports, and then to create the HTML tag to actually render it.  The documentation also describes how you can do things like color the report background as well as select which report to show.  Here’s an example of a Dashboard Report being shown in a completely different site from Office365Mon:

dashboardreport

The new Dashboard Reports feature makes it super easy and simple to build your own custom Office 365 health dashboards now with just a few lines of HTML.  Visit our site at https://www.office365mon.com to learn about it and all of the other Office 365 monitoring features available from Office365Mon.Com.

From Sunny Phoenix,

Steve

Monitor for Changes in Your Version of Exchange Online with Office365Mon

At Office365Mon we monitor all sorts of things about Office 365.  One of the early customer requests that we incorporated into our service was the ability to monitor for changes in the version of SharePoint that have been pushed out to your SharePoint Online tenant.  We have had several customers ask for the same type of monitoring and notification when changes occur in Exchange Online, and today we’re happy to announce the availability of just such a feature.

New versions can bring with them changes in the user interface and potential issues for customizations and apps.  That’s why for many customers, it’s critical for them to know when the version of SharePoint Online or Exchange Online changes.  Enabling Office365Mon to stay on top of these changes is quite simple.  When you go into configure your Office365Mon subscription, there is a box that you can check to monitor for version changes:

Monitor for Exchange Online Version Changes

exoversionchange

Monitor for SharePoint Online Version Changes

spoversionchange

One of the main differences between the two is that to monitor for changes in version for Exchange Online, we need a higher level of access to the mailbox being monitored than if we’re just monitoring for availability and performance.  As a result, we strongly recommend that you set up a separate mailbox just for monitoring if you want to have us check for version changes.  This is one of our standard security best practices in any case for Least Privileged Access, and the extra permissions needed to monitor for version changes only reinforces operating with that philosophy.

One of the other changes that we made as part of this feature release is to add webhook notifications for changes in version for both SharePoint Online and Exchange Online.  A webhook allows you go get a programmatic notification, and then you can execute your own workflows when you receive it.  For example, when you get a webhook notification that the version has changed, you can kick off a process to do validation of the features in your tenant or custom applications to ensure that they are all still working as expected with the new version.

We hope you find these new capabilities useful to the management of your Office 365 tenant.  It’s yet another feature set that has been driven entirely based on feedback from our customers.  Please try it out and let us know what you think!

From Sunny Phoenix,

Steve

 

Introducing Monitoring for Azure Secured Web Sites from Office365Mon

Today we’re excited to announce another new monitoring feature at Office365Mon.  Beginning today, we are now offering you the capability to monitor virtually any web site or REST API using the same proven, enterprise grade monitoring capabilities of Office365Mon.  The same service we use for Office 365 monitoring can now be used to monitor your sites that you deploy to Azure web sites, or your SharePoint hosted apps for on-prem or Office 365 sites, or virtually any other site!  You get the power of a monitoring infrastructure that sends out 10 to 20 million health probes a month to keep you in the know of your own web sites and REST APIs now.

All of this will come with the same kind of integration that you’re used to seeing at Office365Mon.  Setup will be extremely quick and easy, all done in your browser as well as via our Office365Mon Management API.  You’ll get the same sort of alert notifications as you do with the other resources we monitor for you – text messages, emails, and webhook notifications.  You’ll also see all of the data we capture about the health and performance of these sites in the same exact reports you use today, whether that’s one of our Standard or Advanced reports, you download your report data from our site, or you use Power BI with the Office365Mon Content Pack.  Here’s an example of a performance report that’s monitoring both Office 365 sites as well as other sites we have hosted in Microsoft Azure:

websitemonitoring

As you can see from the chart above, we’re monitoring:

Your sites and REST APIs can be hosted anywhere of course, as long as it has a public endpoint we can connect to.  It can be an anonymous site, or it can be secured with Azure Active Directory.  We can also monitor REST APIs as long as they don’t require any parameters.

This feature is available in Preview today and ready for you to begin trying out.  Get started by creating your Office365Mon subscription and then adding some sites to monitor here.  Pricing and licensing has not been set yet, but the good news is that like all new features, all existing customers will get 90 days to try it out for free.  Especially while this is in Preview, it’s a great opportunity to take a look and give us any feedback you have so we can fine-tune it to meet your needs.  Like many of the things you see at Office365Mon, this is another feature that was created based on feedback from our customers.

We hope you enjoy this new feature and will take the time to try it out.

From Sunny Phoenix,

Steve

 

Cloud Solution Services Now Available from Office365Mon and TechStar Group

Today I’m very excited to announce a new offering from Office365Mon and our newest Gold Star Partner, TechStar Group.  We are teaming together to take the skills and experience we’ve built while creating one of the most scalable and extensible cloud service solutions you’ll find for monitoring Office 365 – Office365Mon of course!

At Office365Mon we send out tens of millions of health probe queries every single month.  Now we’re bringing those skills out to help you with your move the cloud as well as part of our partnership with TechStar Group.   Our architecture and design demonstrates superb quality at a scale that is beyond what most of even the largest enterprises do. We send out tens of millions of health probe queries every month at Office365Mon, and we do so utilizing all of the leading edge technologies needed to accomplish such a huge task – Azure Active Directory, Office 365 APIs, Azure web apps, Azure cloud services, Azure storage and queueing, SQL Azure storage, and more.

Now, we’ve teamed up with our Gold Star Partner TechStar Group to unleash our team of experts on your cloud projects. We cover everything from architecture and design for new Azure and Office 365 projects, development, cloud migration, and much more. All projects are given oversight by former Microsoft Senior Principal Architect and Office365Mon founder Steve Peschka, so you can rest assured that the work being done will meet the highest quality bar. In addition, TechStar Group brings a number of former Microsoft employees and others with many years of successful technology delivery projects to the table. Together we offer a shared team that’s capable of delivering on the biggest and most challenging cloud projects.

We hope if you are working on cloud applications, services, migrations, etc. that you’ll consider contacting us to find out how our battle tested team of cloud savvy architects and engineers can help you make your own move to the cloud a successful one.  Please contact us to talk to us about your needs:

  • Office365Mon:  Steve Peschka, speschka@office365mon.com
  • TechStar Group:  Garrison Walls, garrison@techstargroup.com

Thanks as always.

From Sunny Phoenix,

Steve

 

YARBACS or Yet Another RBAC Solution

RBAC is all the rage (as it should be) these days, but it’s not really new.  The concepts have been in use for many years, it’s just a case of bringing it into modern cloud-based scenarios.  Azure continues to invest in this concept so that we can increasingly lock down the control and use of various cloud-based services they offer.  There’s other “interesting” aspects to these scenarios though that can impact the availability and usefulness of it – things such as existing systems and identities, cross tenant applications, etc.

It’s these interesting aspects that bring me to this post today.  At Office365Mon we are ALL about integration with Azure Active Directory and all of the goodness it provides.  We also have had from day 1 the concept of allowing users from different tenants to be able to work on a set of resources using a common security model.  That really means that when you create Office365Mon subscriptions, you can assign subscription administrators to anyone with an Azure AD account.  It doesn’t require Azure B2C, or Azure B2B, or any kind of trust relationship between organizations.  It all “just works”, which is exactly what you want.  IMPORTANT DISCLAIMER:  the RBAC space frequently changes.  You should check in often to see what’s provided by the service and decide for yourself what works best for your scenario.

“Just works” in this case started out being really just a binary type operation – depending on who you are, you either had access or you didn’t.  There was no limited access based on one or more roles that you had.  As we got into more complex application scenarios it became increasingly important to develop some type of RBAC support capabilities, but there really wasn’t an out of the box solution for us.  That led us to develop this fairly simple framework of YARBACS as I call it, or “Yet Another RBAC Solution”.  It’s not a particularly complicated approach (I don’t think) so I thought I’d share the high level details here in case it may help those of you who are living with the same sort of constraints that we have.  We have a large existing user base, everyone is effectively a cloud user to us, we don’t have any type of trust relationship with other Azure AD tenants, but we need to be able to support a single resource (Office365Mon subscription) to be managed by users from any number of tenants and with varying sets of permissions.

With that in mind, these are the basic building blocks that we use for our YARBACS:

  1. Enable support for Roles in our Azure AD secured ASP.NET application
  2. Create application roles in our AD tenant that will be used for access control
  3. Store user and role relationships so that it can be used in our application
  4. Add role attributes to views, etc.
  5. Use a custom MVC FilterAction to properly populate users from different tenants with application roles from our Azure AD tenant

Let’s walk through each of these in a little more detail.

 

Enable Support for Roles

Enabling support for roles in your Azure AD secured application is something that has been explained very nicely by Dushyant Gill, who works as a PM on the Azure team.  You can find his blog explaining this process in more detail here:  http://www.dushyantgill.com/blog/2014/12/10/roles-based-access-control-in-cloud-applications-using-azure-ad/.   Rather than trying to plagiarize or restate his post here, just go read his.  J   The net effect is that you will end up with code in your Startup.Auth.cs class in your ASP.NET project that looks something like this:

app.UseOpenIdConnectAuthentication(

new OpenIdConnectAuthenticationOptions

{

ClientId = clientId,

Authority = Authority,

TokenValidationParameters = new System.IdentityModel.Tokens.TokenValidationParameters

{

//for role support

RoleClaimType = “roles”

},

… //other unrelated stuff here

Okay, step 1 accomplished – your application supports the standard use of ASP.NET roles now – permission demands, IsInRole, etc.

 

Create Application Roles in Azure AD

This next step is also covered in Dushyant’s blog post mentioned above.  I’ll quickly recap here, but for complete steps and examples see Dushyant’s blog post.  Briefly, you’ll go to the application for which you want to use YARBACS and create applications roles.  Download the app manifest locally and add roles for the application – as many as you want.  Upload the manifest back to Azure AD, and now you’re ready to start using them.  For your internal users, you can navigate to the app in the Azure management portal and click on the Users tab.  You’ll see all of the users that have used your app there.  You can select whichever user(s) you want to assign to an app role and then click on the Assign button at the bottom.  The trick of course is now adding users to these groups (i.e. roles) when the user is not part of your Azure AD tenant.

 

Store User and Role Relationships for the Application

This is another step that requires no rocket science.  I’m not going to cover any implementation details here because it’s likely going to be different for every company in terms of how and what they implement it.  The goal here is simple though – you need something – like a SQL database – to store the user identifier and the role(s) that user is associated with.

In terms of identifying your user in code so you can look up what roles are associated with it, I use the UPN.  When you’ve authenticated to Azure AD you’ll find the UPN is in the ClaimsPrincipal.Current.Identity.Name property.  To be fair, it’s possible for a user’s UPN to change, so if you find that to be a scenario that concerns you then you should use something else.  As an alternative, I typically have code in my Startup.Auth.cs class that creates an AuthenticationResult as part of registering the application in the user’s Azure AD tenant after consent has been given.  You can always go back and look at doing something with the AuthenticationResult’s UserInfo.UniqueId property, which is basically just a GUID that identifies the user in Azure AD and never changes, even if the UPN does.

Now that you have the information stored, when we build our MVC ActionFilter we’ll pull this data out to plug into application roles.

 

Add Role Attributes to Views, Etc.

This is where the power of the ASP.NET permissions model and roles really comes into play.  In step 1 after you follow the steps in Dushyant’s blog, you are basically telling ASP.NET that anything in the claim type “roles” should be considered a role claim.  As such, you can start using it the way you would any other kind of ASP.NET role checking.  Here are a couple of examples:

  • As a PrincipalPermission demand – you can add a permission demand to a view in your controller (like an ActionResult) with a simple attribute, like this:  [PrincipalPermission(SecurityAction.Demand, Role = “MyAppAdmin”)].  So if someone tries to access a view and they have not been added to the MyAppAdmin role (i.e. if they don’t have a “roles” claim with that value), then they will get denied access to that view.
  • Using IsInRole – you can use the standard ASP.NET method to determine if a user is in a particular role and then based on that make options available, hide UI, redirect the user, etc. Here’s an example of that:  if (System.Security.Claims.ClaimsPrincipal.Current.IsInRole(“MyAppAdmin “))…  In this case if the user has the “roles” claim with a value of MyAppAdmin then I can do whatever – enabling a feature, etc.

Those are just a couple of simple and the most common examples, but as I said, anything you can do with ASP.NET roles, you can now do with this YARBACS.

 

Use a Custom FilterAction to Populate Roles for Users

This is really where the magic happens – we look at an individual and determine what roles we want to assign to it.   To start with, we create a new class and have it inherit from ActionFilterAttribute.  Then we override the OnActionExecuting event and plug in our code to look for the roles for the user and assign them.

Here’s what the skeleton of the class looks like:

public class Office365MonSecurity : ActionFilterAttribute

{

public override void OnActionExecuting(ActionExecutingContext filterContext)

{

//code here to assign roles

}

}

Within the override, we plug in our code.  To begin with, this code isn’t going to do any good unless the user is already authenticated.  If they haven’t then I have no way to identify them and look up the roles (short of something like a cookie, which would be a really bad approach for many reasons).  So first I check to make sure the request is authenticated:

if (filterContext.RequestContext.HttpContext.Request.IsAuthenticated)

{

//assign roles if user is authenticated

}

 

Inside this block then, I can do my look up and assign roles because I know the user has been authenticated and I can identify him.  So here’s a little pseudo code to demonstrate:

SqlHelper sql = new SqlHelper();

List<string> roles = sql.GetRoles(ClaimsPrincipal.Current.Identity.Name);

 

foreach(string role in roles)

{

Claim roleClaim = new Claim(“roles”, role);

ClaimsPrincipal.Current.Identities.First().AddClaim(roleClaim);

}

 

So that’s a pretty good and generic example of how you can implement it.  Also, unlike application roles that you define through the UI in the Azure management portal, you can assign multiple roles to a user this way.  It works because they just show up as role claims.  Here’s an example of some simple code to demonstrate:

 

//assign everyone to the app reader role

Claim readerClaim = new Claim(“roles”, “MyAppReader”);

ClaimsPrincipal.Current.Identities.First().AddClaim(readerClaim);

 

//add a role I just made up

Claim madeUpClaim = new Claim(“roles”, “BlazerFan”);

ClaimsPrincipal.Current.Identities.First().AddClaim(madeUpClaim);

This code actually demonstrates a couple of interesting things.  First, as I pointed out above, it adds multiple roles to the user.  Second, it demonstrates using a completely “made up” role.  What I mean by that is that the “BlazerFan” role does not exist in the list of application roles in Azure AD for my app.  Instead I just created it on the fly, but again it all works because it’s added as a standard Claim of type “roles”, which is what we’ve configured our application to use as a role claim.  Here’s a partial snippet of what my claims collection looks like after running through this demo code:

yarbacs

To actually use the FilterAction, I just need to add it as an attribute on the controller(s) where I’m going to use it.  Here’s an example – Office365MonSecurity is the class name of my FilterAction:

[Office365MonSecurity]

public class SignupController : RoutingControllerBase

There you have it.  All of the pieces to implement your own RBAC solution when the current service offering is not necessarily adequate for your scenario.  It’s pretty simple to implement and maintain, and should support a wide range of scenarios.