Can KIM be used by other than K* apps?
Or, can KIM solve Josh's problem, ie, provide the Matterhorn project a package with which they can satisfy their ID services needs?
Attending: EricW (lead) ChrisH, Richard James, Tom Zeller, Ann West, Jean Marie Thia, Jason Zylks, Todd Pickett, Hari Mailvaganam, TomB (scribe), Mike McComas (NCSU), 3 others
About 50% hearing about KIM for the first time.
What examples like Matterhorn do people know of?
2-3 do custom app development.
JasonZ: Currently ad hoc approach, app specific way to handle authN, authZ, etc. Other depts around campus also lack common approach.
Richie James: have developed a common means of replicating centrally managed access data from grouper and provisioning into downstream systems, using talend. Eg, the room booking app is fed grouper-defined roles.
KIM doesn't have a provisioning interface. As intended, really. Would that be valuable to include?
Is KIM an identity manager, ie, kinda like Sun IdM? A role manager?
No. It was designed to abstract the common identity service needs from a family of applications, the Kuali apps, not to be an enterprise IdM.
MikeM@NCSU talked about their use of Sun IdM and that now they're looking for something else. Can KIM be that for us?
KIM provides a data model for identity data and roles, etc, but it doesn't prescribe how that data gets in there. Eg, Microsoft Identity Lifecycle Manager, an enterprise IdM system, provisions KIM's database at one campus. Alternatively, KIM's service interfaces can be implemented by existing enterprise sources, and not need to first populate the KIM DB with data.
Will the Rice project do a "portable KIM" package?
Definition of "portable KIM": just enough of the Rice jars to define the KIM service interfaces, to implement them with the KIM DB, ie, that part of the Rice DB needed to implement KIM's service interfaces. The purpose of a portable KIM is to provide app developers a solution for their needs for user accounts, authN, groups, etc. Further, it would enable deployers to decide whether they would prefer to replicate IdM info inthe portable KIM's DB, or if they'd rather implement the KIM interfaces with their own enterprise IdM services.
Good for other OS projects. Could get on the uPortal roadmap too.
Can KIM be a repository of all roles, permissions, etc, across the enterprise?
Well, it has the run-time API for managing and using a rich set of access-related objects, and the KIM DB can store such info. It's group memberships are effective dated. Memberships are managed by a workflow engine, and those actions are tracked, so it's also audited in that sense.
What can the Rice workflow engine do? Can it make a membership contingent upon someone's approval, someone who's authorized to do so?
Yes.
KIM has good API support for reading stuff, but it's probably a little light on management of objects.
Grouper/KIM work highlights some of the issues with KIM APIs, but providing a way to identify gaps and improve them too.
If Grouper developed a "standard" API for group stuff, would Rice put that into KIM?
Possibly. Groups more likely than, say, roles, permissions, more sophisticated access objects.
Is there an opportunity for the Rice project to meet needs outside of the K* apps?
Kuali Rice governance. Representation 50% K* apps, 50% investing partners in Rice. They prioritize Rice activities.
How many Rice governance voices would need to ask for portable KIM in order for it to happen?
Some have an interest aligned with that, sorta. Maybe 50% of that second 50% would need to back it.
If the Rice team can't be authorized to produce portable KIM, might it be possible for the Rice team to support some other group in making that happen?
What's on the KIM roadmap? Not a lot really. Rice roadmap mostly focuses on other things now that KIM's "done". Like better UIs, XML import/export support for roles & permissions.
What's planned for KEW (Kuali Rice's workflow engine)? Pretty much done.
Possible next steps?
Revisit defining a standard API for groups.
Kuali affirm the direction for KIM: a full IdM, a portable KIM, support for someone else to produce a portable KIM, or just as it is with no expansion of scope?
Maybe get more Kuali involvement on the Educause IdM list. Raise awareness of Rice there, and make Rice folks more aware of the range of needs encountered by campus IdM for a broad range of campuses.