...
- This is based on my personal high-level chunking, in which much of the stuff we seem to largely be in agreement about falls under the rubric of an "identity registry".
- I tend to separate out the registry from the mechanisms by which data in the registry is made useful (propagation and provisioning of identities to downstream systems, handling of access management, presentation facilities like directories and such. This may be because here at Duke we've long had things roughly chunked that way in our software implementations. I don't actually *like* the way we've always done things in some senses, so I'm quite open to rethinking that.
- When I've used this diagram before, I've left the policy management circle out of the picture, usually because I'm using it to talk to the folks I want to engage about policy articulation :-). My idea putting it in the way I have in this version of the diagram is that policy management cuts across a large part (but not all) of the picture, and if the other components are represented as overlapping clouds, policy management might be viewed as what the clouds are obscuring in a sense.
- In the small type inside each cloud, the black text relates to things I'm pretty certain fit inside the category, and the pink or green text relates to things I'm not sure are relevant or I'm not sure fit well in one or another cloud within the diagram.
Other Materials
Matt Sargent from the Kuali group has an interesting alternative approach to breaking down this space available here
Questions
Scoping Questions
- What's the overall scope of identity for our purposes? Clearly, it includes person identities, but should an IDM suite be expected to also manage identity information for systems? How about management of aggregated objects – groups? Roles?
- Is our focus to be purely on core IDM functionality (which might be defined as functionality exposed only to other systems and to technical specialists, but not to end-users) or should our scope be broader and include end-user interfaces (things like self-service facilities for data management)?
- Does OSIdM4HE consider the management of permissions and privileges as in-scope or out-of-scope?
- What about management of access control policies?
- And federation tools?
- There are a few components we can likely all agree are needed in order to successfully implement an IDM suite – workflow support, notification mechanisms, primary authentication services – should these be considered in-scope for the IDM or should they be considered "external infrastructure" that the IDM suite relies upon and presupposes as a co-deployment, but doesn't make direct provisions for?
Chunking Questions
- Can we agree at this point as to whether an identity repository (where aggregated identity information would be stored by the IDM, separate from their origin systems) is or isn't a requirement for the OSIdM4HE?
- Is delegation a feature purely of the permission and privileging portion of the IDM, or should it be considered as a feature that's embedded throughout all the components of the IDM suite?
- Does the separation of identity provisioning and access provisioning make sense, or should "provisioning" be a more general "chunk" for our discussion, and include both (or perhaps, if access control is considered out of scope, is this not a valid question)?