Dynamic groups and content security strategy

Lot's of organizations think because they have lots of employees (hundreds of thousands) they can not use groups because there would be too many combinations. They look at all of the millions of ways content CAN be personalized and think that it will be. In reality, content personalization should be from the content perspective by defining groups that correspond to the content service - not the way employees are organized.

For example, a large company has employees with the following attributes:

• Status: A, B, or C
• Level: 1, 2, or 3
• Region: R1, R2 or R3
• Function: F1, F2, or F3

People level 2 and 3 are managers. (in reality the companies we work for have 100s of attributes so the possible combinations number in the millions)

Common mistake

Let's start with a collection of documents called "Managers Toolkit".

• The security teams asks: Who needs access to this?
• The authors answer: Managers Only.
• Conclusion: Lets create a group called "Managers". WRONG!

Why is this wrong?
Let's think this through. Let's go ahead and create a group called managers. At first it's nice, all the content that needs to go to managers is tagged with the "managers" group. First we tag all the documents in the "Managers Toolkit" section, then you also tag items in the "managers lounge" and in the "Managers FAQ" and the "Managers Reports" with the same group. Look how efficient we are!

Then one day someone says, hey, this content in the "Managers FAQ" also needs to go to everyone (manager or not) who works in finance. hmm...ok... So now we have 2 options - add finance people to the managers group which won't work since then they get access to all the other content or create a new group called "finance" and then go through all the documents in the "Managers FAQ" collection and retag them. Its a lot of work, but you bite the bullet and do it. But two weeks later you have to add Marketing...then, eventually you have content tagged like this: Managers Level 2, Managers Level 3, Finance, Marketing, Union A. Union B and the phone is ringing constantly with people asking why they can see the 1 document in the list that was mis-tagged, or why they are seeing something they should not see.

Trust me, this does not have a happy ending. Eventually you have exactly what you wanted to avoid, millions of groups - except they aren't groups. They are combinations of attributes hap-haphazardly applied to millions of pieces of content. Your model of efficiency has become a complex and unmanageable nightmare. With every change you either have to open and retag all 1001 items, or compromise the definition of one of your existing groups. Plus, since your security model reflects the business organization, everytime 2 groups merge, dissolve, or split - guess what? Yep, you get carpel tunnel retagging everything.

The better way

Define groups around the content services that exist. In the example above we have a collection of documents - "Managers FAQ". To secure this new collection, we create a group called...drumroll please... "Managers FAQ Readers". Then all documents in that collection are secured with that group. Then, if you need to expand or contract access, you can, by changing the definition of the group.

If you think about it, this is how the whole internet works. If I create a collection of content called "The New York Times" - I then secure access it, with a group called "New York Times membership list". If I create a service call "weather", I create a group called "weather subscribers" to control access to it.

Why is this so hard to remember?

Time after time I have seen sites large and small with security and personalization groups organized around the way people are organized rather than the way the content is organized. This is for two reasons. First, it is harder since it requires you to think about and define your content services. This is harder for engineers than just defining the existing groups as they are defined in the HR IS system or in LDAP (because it involves talking to the business) which is why they tend to do it the wrong way. Second, it's more counter intuitive than you think because of the way the initial question is asked. "who should have access to this?" has an answer - "managers" so it seems like an obvious group name. So I find its better to only ask that question AFTER the group has been created. If you create a service or collection of content called "General FAQs" - go ahead and create the group - "General FAQs readers" then, if the answer turns out to be "everyone" then just add that rule to the group definition. Then if they change their mind, your covered.

Dynamic Groups, Soft Groups

No matter which way you do it, you don't want to have manage these groups manually. Constantly watching for users to change status, level, or region is a good job for a computer (they love that kind of tedious work!). So you need a dynamic mapper (we have also called it a soft group calculator before) and it is a feature of most enterprise directories. It lets you define a group by user attribute - so that the definition of group like "Managers FAQ Readers" is a rule based on attributes like:
All users where (Level=2 or Level=3) or (Function=Finance) and (Status=Active) or name=Ben Shoemate (yes you can add named individuals) etc.

Once the rule is defined, a calculator goes through all the users in the LDAP. If there is a match, the group is added to the users profile. Then, when the user logs in to the portal, we simply read the groups off the user profile. In other words, the user carries their membership cards around with them so that the portal doesn't have to execute all the rules of all the groups at run time, slowing the login process.

Bottom line

When you define a new content service- create 2 new groups: Union A Benefits Readers, and Union A Benefits Authors.
One for the readers, one for the authors.
Avoid the temptation to say "This other service is targeted to the same people so I'll use the same group" (Union A News for example) - because (1) what is true now, may not stay true. (2) Someone will want to get the news, without the benefits access eventually, and (3) someone will change one group not realizing it controls both content services.

This lets you have a true layer of separation between the content and security and allows for much better flexibility. Also, since the calculation of who is in which groups is done "offline" the portal has better performance since it doesn't have to calculate membership on login. The users groups are carried with them.

Ben Shoemate Ben is a senior information architect and co-founder of Burleson Technology Group.