I got on my soapbox again.

Our Identity and Access Management (IAM) deployment has always been a critical tool for the organization – but even more so over the last 12 months.

IAM not only secures access, SSO in particular has made me look pretty darn good by reducing friction throughout the organization.

Yet, when it came to our Office365 integration, we did need a hand from our IAM vendor because of the nuances of that platform.

Things were going really, with our partner filling in some of the knowledge gaps we had on the O365 side.  We got some kudos on how we clearly secured the IAM platform, and all the other SSO integrations we had done.

But when we got to O365 provisioning, we were presented with quite of list of applications (entitlements) we could select from the O365 backend (kind of mess back there Microsoft).

Our partner suggested that some clients use community groups when assigning applications in O365 – like “Accounting always gets PowerBI and Teams”.

“ABSOULTELY no!” was my response – and I went IN on our Entitlement Based Philosophy.

Centering on “communities” is the cardinal sin of my Entitlement Based Policy (EBP) philosophy.  Bundling community entitlements is SO tempting to make provisioning easier – but as the organization and roles change, it will turn policies into pretzels in the long term.

I have seen this problem – especially when it comes to user provisioning – my whole career in organizations of any significant size or complexity.

To solve it, people try creating “community templates” with a preselected bundle of entitlements based on departments, job titles or similar groupings.

That sounds good – but inevitably you have to create variations on the templates as roles change or some special cohort in the same department or with the same title, need some unique entitlements.

Now you made the problem worse.  What exactly is the difference between the Accounting template and Accounting Power Users template?  What if someone adds a new entitlement to one of those community templates – did every single person using that template need it?

And really – the concern should be who has access to critical data or systems – THAT was the question you wanted answered quickly and accurately in the first place.

So, I flipped it and created an Entitlement Based Policy mindset in the team.

I do not care what department a user is in or what “title” they have when it comes to entitlements. If authorized, we grant access to resources – but authorization is not always a function of their title alone.

That is why we start with the entitlements themselves.  The secret is enumerating them as clearly (and narrowly) as possible – and avoid the use of COMMUNITIES in naming or defining the entitlements.

Focus on the entitlement, what authorization can be provided, who needs to approve – spend your time and effort there. Needs shift over time, and if the entitlements are clear – it easy to subscribe or un-subscribe users to them.

Take that Office365 example.  It is so tempting to bundle entitlements around communities, as was suggested as an option by our vendor (so there would be an Accounting Policy that would provision a collection of O365 applications as users are provisioned, for example).

We turned that around – each O365 ENTITLEMENT is the grouping in the policy hierarchy.

In this simplified example, there would be a “Teams Users” policy and a separate “PowerBI Users” policy.  Restricted authorization levels would get more specific naming for the entitlement as needed. When entitlements licensed bundled together and shared widely – try naming groups for the licensing instead of the broad community (ex. “Office365 E3 Bundle” instead of “Standard Users”).

This way as a user authenticates and flows down the policy – they are granted only the entitlements they require – and changing subscriptions can be targeted and easily executed as needed.

This is certainly more work up front – but I know it is worth it – because I broke my rule when we first rolled out our IAM.

Embarrassingly, it was for own team where I got lazy.

Initially, I had two main verticals reporting to me – the Threat Intelligence & Management team and the Security Infrastructure team.

Forgetting myself, I just created a community-based entitlement for “Information Security”, that gave them access to our security tools – which they largely shared.

But recently, IT Governance, Risk and Compliance started reporting to me.

They didn’t need access to the security tools – but were in this “community” – and  I needed to go back and create new entitlement-based groupings.

While a bit of a mess – I was happy.

You see, in the last four years or so, I never needed to revisit IAM policies for the rest organization.  For them, I had followed my rules from the start – and by making my mistake – I proved I was right about Entitlement Based Policies.

My personal organization – quite predictably – changed underneath me. While it was initially simpler – it was clear why I should have avoided community-based rules in the first place.