Claims vs. Groups

Some time ago I promised to explore the super awesome world of claims, but somehow I never got around to it. With apologies, let’s take a look at how groups are dead* and claims are the new hotness.

*Groups aren’t dead, and claims have been around for years, but work with me—my wife just had a baby last week.

Groups have been the rage since the dawn of networking. They made wrangling our security infrastructure exponentially more manageable than just granting explicit access rights to users. Groups have allowed us to do some pretty cool stuff in the Windows landscape, in fact:

• Assign access to files, folders, printers

• Allow cross-domain access to resources

• Deliver mail to multiple recipients

• Allow multiple users to access a single mailbox

• Deploy software

• Control group policy scope

And then groups got even fancier with Best Practices governing access to resources, wherein a user should be added to a global group, which then gets added to a domain local group governing the specific resource access level. There is so much you could do with groups!

I spent the better part of a year creating role groups for a large corporation, where each role group represented a specific job in the organization, and when a new user started, they just got added to that one role group. This worked extremely well in actual practice, but the Help Desk didn’t understand it, and would add the user to the role group, each individual global group to which the user might need access, AND to the domain local resource groups.

What was meant to reduce complexity ended up being a disaster of permissions overlaps, and no amount of training the Help Desk could get them out of the habit of just adding users to resource groups. When all was said and done, an organization of 1100 users ended up with well over 10,000 groups to access a handful of resources.

There had to be a better way.

Exchange 2010 introduced a concept called the ‘dynamic distribution list’ (DDL). This was a mail-enabled group that had no explicitly assigned members (and no recipient limits!). Instead, Exchange would query Active Directory for some particular user attribute and deliver the message to everyone who matched. So, say you wanted to send a message to everyone in Accounting. You could create a DDL called “Bean Counters”, have it query Active Directory’s “department” attribute, and deliver the message to everyone who has “Accounting” in that field. Or you could limit it to accountants in Tulsa by querying both the city and department attributes.

This was both revolutionary and incredibly simple. How had attributes been overlooked for a dozen years? Well, they kind of hadn’t. In the SSO world, attributes are the workhorse of authentications, and they call them claims. Claims can be a single attribute or a combination of several, and usually, include some sort of certificate information. And hey: Active Directory has all these great attribute fields just sitting around being almost completely unused!

Windows 2012 picked up this same query-based capability and added file-access control. Now you could grant the Finance department access to their network share without a million groups defining access! Or better yet, you could delegate control to someone responsible for the Finance department’s data and let THEM decide which attributes were relevant to gaining access.

SQL server has supported claims for a few years, as well, further reducing the need to build AD groups to support access into specific application workloads.

And that’s kind of the key, right? AD should be worried about identity. Applications (and their owners) should worry about access. If you can offload the access requirements and give those apps the tools to query AD, you can focus on systems instead of permissions. If your users are in the right OU, they get your group policy. If their department fields and job titles (and the super-secret hidden Division attribute, if you want), why not let that be the governance for accessing files and applications?

And the really super awesome thing is that when a user changes within the organization, there’s no worrying with groups. How many times has someone moved from one job to another and been left with some or all of their old access? If access is query-based? Never. So all that work I did with building role groups at my old job can now be handled by simply setting application security around attributes. No more need to have an “HR Generalist” group that’s a member of “Regional HR Managers”, which is, in turn, a member of “Global HR Managers”, and on and on until you get a wildly overlapping and convoluted permissions mess.

Leveraging attributes & claims, when the user is changed, their permissions, policies, Azure SaaS apps, distribution lists, etc. change with them. Beautifully simple.