Mike Conklin at University of Rochester is blogging about his experience while going through various stages of an identity management project. One of Mike's academic exercises (as he puts it) is anwering a question of how to manage mailing list membership. Mike writes that “after posing this question to several vendors in our IdM evaluation meetings, I actually think that there are no current solutions out there that will allow you to create dynamic distribution lists with opt-in/opt-out capabilities".

No current solutions? Sounds like a challenge to me and boy do we like a challenge here at Identigral. First, let's consider the use case stripped from its technology foliage:

• A school wants to offer a newsletter to all of its Geology majors. Maybe it will provide information about guest lecturers or other events. As new students join the Geology program, they should be automatically subscribed to the newsletter based on their declared major.
• There are students with other majors who have an interest in geology and would like to receive the newsletter as well. These students should be able to subscribe (opt-in) to the newsletter
• There are students in Geology who would like to unsubscribe (opt-out) from the newsletter

The challenge here is that you've got a set of rules that automatically determine membership (if you're a Geology major, you are auto-subscribed) but if you don't fall into the rule-based criteria, you should be able to ask and get in anyway (opt-in). If you do fall within the criteria, you should be able to ask and get out (opt-out). Here's how an identity administration tool such as Oracle Identity Manager (OIM) would solve this problem. I am going to be using OIM terms but if you've got a different product, you should be able to translate.

In OIM, we'll have the students and resources. A resource can be anything, it's just an abstraction for capturing metadata associated with the student's relationship to the resource. A newsletter can be a resource, an LDAP-compliant directory can be a resource, a pair of shoes can be a resource (especially if they're Jimmy Choos!!), a meal card, and so on. Our goal is to accurately track the relationships between students and resources and the state of the relationship. When a student joins the university and chooses a meal plan (grits! grits!), the university issues the student a meal card. The meal card has an ID number, it has a student's meal plan on it, etc. We can then draw a line between our student and the meal card. For example, student Joel Seligman has a Breakfast Only meal plan. OIM labels this step as provisioning, i.e the university has provisioned (issued) the meal card to a student.

The resource has state (more accurately, the relationship has state but ok) - it can be Provisioned,Disabled or Revoked. There are other states too but we'll skip them for the sake of brevity. Provisioned means that the student has the resource and the relationship is active, Disabled means that the student has the resource and the relationship is inactive but can be made active again and Revoked means that the student had the resource but now the relationship is permanently destroyed. If the university decides to revoke the student's meal privileges and send Joel to solitary confinement, they would revoke the meal plan resource (poor Joel!)

There are 3 types of provisioning supported in OIM:

• Request-based provisioning: A request can be manually entered by a user or on user's behalf. Approval workflows are started after a request is submitted and provisioning (or de-provisioning) of the resource is started after the approval is completed. Thus, request-based provisioning is really two processes (approval and provisioning/de-provisioning).
• Policy-based provisioning. This type of provisioning refers to the automation of target resources being granted to users based on rules that make up a policy. Rules are based on attributes that make up the user's profile. In addition, you can also use access policies to kick-off approval processes that can be run as part of the policy-based provisioning cycle.
• Direct provisioning. This type of provisioning is a special administrator-only function. You can provision, disable or revoke a resource for a particular user without having to wait for any approval processes

Here's how OIM solves the mailing list membership problem that Mike posed:

• A school wants to auto-subscribe all of its Geology majors to a newsletter. This becomes an example of policy-based provisioning where the policy in OIM looks at the student's major and automatically provisions a Geology newsletter when the student joins the major. The policy could also automatically disable or revoke the subscription when the student leaves the university or switches majors.
• There are students with other majors who have an interest in geology and would like to receive the newsletter as well. These students should be able to subscribe (opt-in) to the newsletter. This is accomplished in OIM via request-based provisioning. A student could request the newsletter and be approved by, for example, the newsletter owner. You could also skip approval.
• There are students in Geology who would like to unsubscribe (opt-out) from the newsletter. This is done in OIM via request-based provisioning. A student could request to disable the subscription (disable the resource) and be approved by, for example, the newsletter owner. You could also skip the approval.
• As an extra feature that's not in Mike's scenario, what about students who become unruly when discussing geology? It can be a very contentious subject and certain dissidents may need to be removed from the list by the administrator. In this case, direct provisioning would be used by the newsletter owner to disable or revoke the newsletter resource for some student

Bonus: a starter kit for those of you interested in pursuing a career in geology