* The 'dynamic groups' concepts
Last time, I said we’d get back to the idea of “dynamic communities,” which Courion co-founder and CTO Brian Milas outlined for us in last week’s newsletter (see editorial link below), and so we shall.
A number of vendors contacted me to say that based on my description of “dynamic communities” they are doing much the same under a different name. They were probably right, because the base concept goes back a number of years. It was actually recalled for me by one of the readers who outlined the “top-down” approach to role creation, which I explored in the last issue. As reader Troy Moreland put it: “For example, start with Enterprise Role creation. Build dynamic roles (groups) based on data like ‘All Supervisors’ or ‘All Employees’ or ‘All Contractors’, ‘All Houston-based Employees’, etc.” He even used the “groups” word in mentioning dynamic roles and outlined a plan similar to the dynamic communities from Courion.
What that recalled for me was the concept of “dynamic groups.” The concept goes back to x.500 directories, 20 years ago. The LDAP creators at the University of Michigan added the concept to their SLAPD (Stand-alone LDAP Daemon) server and improved on it, but I don’t think the name “dynamic groups” was used until the iPlanet directory server in the late 1990s. In the iPlanet documentation (https://www.dbmi.columbia.edu/homepages/zhangma/iplanet/esusrgrp.htm#1072773), the term is defined thus:
“For Dynamic Groups, the members do share a common attribute or set of attributes that are defined in the memberURL filter. For example, if you need a group that contains all employees in Sales, and they are already in the LDAP database under “ou=Sales,o=Airius.com,” you’d define a dynamic group with the following memberurl: https://www.networkworld.com/ldap:///ou=Sales,o=Netscape??sub?(uid=*) .”
Whether you use the old term (dynamic group), the newer concept (dynamic role) or the marketing terms (Courion’s Dynamic Communities, what others call ad-hoc Affinity Groups) the use of dynamism to facilitate identity federation in a role-based access control environment is definitely an idea whose time has come. It means creating rules based on attributes that may or may not already exist, and then bundling those rules into roles to facilitate identity federation. This is how it will be done in the future, if you aren’t doing it already. Skeptical? Here’s an example:
In early federation schemes, users of Site A (e.g., American Express) could manually federate to their account on Site B (e.g., United Airlines). It required manual work by both sites as well as by the user. Later federation schemes present the user on Site A with a list of federation partners, then facilitate the user in joining the Site A account to that at Site B. Using dynamism, though, Site A could contain standardized federation scripts based on well-known public standards, which would allow instant and automatic joining of accounts. A user creating (or modifying) their account on Site A could indicate other sites for potential federation (i.e., sites on which they have accounts). Site A’s “federation daemon” can pick up on these additions and automatically create the join. No manual effort required.
This is a basic, and not-all-that-useful, example of how dynamism could work. I’m sure you’ll think up much better ones. Hopefully, you’ll share them with me.
