下面这段话是从Designing an IAM Framework with Oracle Identity and Access Management Suite里面看到了,这段话试图说明IAM不仅仅是把帐号provisioning到某个目标系统中。
A number of years ago, when provisioning was all the rage, suddenly every tiny little company that could stuff you into a single LDAP called themselves a provisioning company. “We provision users to LDAP.” Well, a coffee table wit h a small TV on it is not an entertainment center, and creating a single LDAP obje ct is not provisioning; it’s data entry.
Another poor man’s version of provisioning, still being sold by some vendors, entails mapping a list of resources to a multi-valued attribute within a user’s profile. When an admin checks a box next to a resource, it adds that resource to that attribute. This approach assumes that when the time comes, a given application will come to that user’s profile and find out if the user is allowed access. There are some apps that can do thi s, and then there’s the other 99 percent of the world.
And here’s one more, and it probably sounds familiar. It’s called provisioning, but it’s really just a lot of calls to the help desk, followed by the opening, tracking, and closing of a lot of ticketsWhen I hear of this, it’s often accompanied by “we use Lotus for workflow.” Okay, so you’ve automated notifications, but the actual enablement is still all manual, with no real escalations, no fallbacks, no user tracking, no parallel processing, and certai nly no enforced timetables. A user gets his resources when everybody’s done screwing around.
In simplest form, provisioning can be summarized as two functio ns, workflow and connectorsBut driving a complex, real-world organization requires true en terprise provisioning, which mean intelligent, decision-making user enablement across multiple re sources, based on roles and rules (which in turn are based on security and compliance policies), rather than simply creating an inventory of resources at the user level. To support these requirements, full-blown provisioning must include:
- Role-based access control ■
- Request management and tracking ■
- Policy-based workflow and approvals ■
- Partial to full automation ■
- Full compliance ■
Let me tell you how not to provision:
- Using only a meta-directory. There are solutions out there that rely on this as their primary engine. Meta-directories, such as Oracle Internet Directory (which provides the foundation for some of the largest web sites in the world), are powerful things. They support provisioning. But they shouldn’t be provisioning. The way this approach (sort of) works is this: You change the centralized user entry in the meta-directory by updating the attributes that map to rights in back-end applications, and when the meta-directory synchronizes to those back-end databases, the user has the right flags for access. Wow, that sounds simple. So what’s the problem? No intelligence to drive events such as approvals or notifications, or take into account any dependencies. Limited ability to roll back approvals A and B when C gets rejected. No parallel processing. There are other limitations, but hopefully you get the idea.
- Giving the job to your help desk or individual admins. I visit far too many customers where provisioning is a strictly manual process. A help desk app is not a provisioning tool. It’s meant to track tickets. There may be manual stops i n a provisioning process where a help desk ticket or notification may be used to prod someone to take a manual step. But you need to have policy-driven workflow, with request creation and tracking, notifications, escalations, and fallbacks, to ensure timely user enablement and change management.
- Using the workflow in your collaboration tool. If all you’re doing is notifications, then you don’t have provisioning; what you’ve done is semi-automate a still very manual process.