Category |
Description or Question for solution provider=
|
Response |
Link(s) to Documentation |
General architecture |
Describe how ID match capability is provided =
by the registry solution. For example, is it (a) an integral part of the so=
lution as provided or (b) must it be integrated with an external ID match e=
ngine or (c) can it be provided in some other way? |
KIM does not presently provide built-in ID ma=
tch functionality. Currently, most implementers are not managing identity d=
irectly via KIM but rather provisioning identity data into the KIM registry=
. So the ID match process is typically institution-specific based on what o=
ther products and tools they have in place.
However, recent project work within Kuali is surfacing requirements to hav=
e better support for this. Specifically, the Kuali People Management for th=
e Enterprise (KPME) project (which is HR/Payroll/Time/Attendence) as well a=
s the Kuali Student project. Both of these projects use KIM as their master=
repository of identity data and will need to have good support for maintai=
ning identity therein, including appropriate ID match functionality. Additi=
onally, these projects are implementing systems which are typically the pri=
mary sources of identity within institutions of higher education. |
|
|
Describe how groups management (for use with =
authZ controls and other purposes) is provided. For example, is it (a) hand=
led internally by the solution or (b) integrated with an external group man=
agement engine such as Grouper or (c) provided in some other way? |
KIM supports both of the following:
1) An out-of-the box reference implementation of roles and groups, includi=
ng user interfaces for management of roles and groups.
2) Integration with external implementations of groups and roles through a=
standard set of service contracts defined in KIM.
There is a connector that was developed by the Grouper team which allows f=
or usage of Grouper via the KIM service contracts. Additionally, members of=
the community have integrated with LDAP groups (such as Microsoft's Active=
Directory) as well as other sources for group and role data.
KIM has the concepts of both groups and roles and draws the distinction be=
tween them with groups simply being a collection of principals or other gro=
ups and roles being similar but also allowing for permissions to be granted=
to them.
The group contract is defined by the GroupService :
* http://site.kuali.org/r=
ice/2.0.0/apidocs/org/kuali/rice/kim/api/group/GroupService.html
* http://ma=
ven.kuali.org/release/org/kuali/rice/rice-kim-api/2.0.0/rice-kim-api-2.0.0-=
GroupService.wsdl
The role contract is defined by the RoleService :
* http://site.kuali.org/ric=
e/2.0.0/apidocs/org/kuali/rice/kim/api/role/RoleService.html
* http://mav=
en.kuali.org/release/org/kuali/rice/rice-kim-api/2.0.0/rice-kim-api-2.0.0-R=
oleService.wsdl
KIM also includes an api for performing authorization checks, we call this=
our PermissionService :
* http://site.k=
uali.org/rice/2.0.0/apidocs/org/kuali/rice/kim/api/permission/PermissionSer=
vice.html
* http=
://maven.kuali.org/release/org/kuali/rice/rice-kim-api/2.0.0/rice-kim-api-2=
.0.0-PermissionService.wsdl
Note, however, that we don't really consider these as parts of the "identi=
ty" portion of KIM. Generally speaking, KIM has 5 sub-modules:
1) Identity
2) Groups
3) Roles
4) Permissions
5) Responsibilities |
|
Data model |
Describe how the registry solution supports a=
n extensible set of attributes about (a) persons, (b) applications or other=
external resources, and (c) other, arbitrary entities? |
This is something that KIM does not do a good=
job of currently for identity data. The main way that someone would extend=
the current schema is to do so manually via modification to the database (=
which is a traditional relational database) as well as modify the associate=
d service API layer.
There are a few places in the identity data model where extension is suppo=
rted:
* There is a concept of "external identifiers" which can be used to associ=
ated the identity with any number of desired identifiers.
* KIM supports the concept of "Entity Types". There are two default types =
supported out of the box: PERSON and SYSTEM. Through this mechanism it's po=
ssible to extend KIM to support different types of entities.
* KIM has support for an arbitrary number of addresses, phone numbers, nam=
es, etc. for a given identity record. |
|
AuthZ support |
Describe how the registry data model supports=
defining arbitrary user roles in support of authZ functions. |
This ties into the response to the earlier qu=
estion about groups management. But KIM has support for the concept of "Rol=
es". In KIM a role is essentially a group of identities which can have perm=
issions granted to it.
So a role in KIM that might be used in something like the financial system=
would be an "Account Manager". Account managers can then be granted certai=
n permissions within the system.
In KIM, permissions work off the concept of "Permission Templates". So you=
might define a set of templates like the following:
* Administer Routing for Document
* Perform Custom Maintenance Document Function
* Manually Execute Batch Job
* Upload Batch Input File(s)
* Maintain System Parameter
You then create permissions from these templates which provide additional =
details to help qualify the permission such as:
* Administer Routing for Purchasing Documents
* Manually Execute General Ledger Batch Job
* etc.
KIM also has a concept of storing affiliations which can be used for very =
course-grained roles such as:
* Student
* Faculty
* Alumni
* Staff
* etc. |
|
Features |
Describe how the registry solution supports a=
udit logging of sensitive transactions, including support for the recording=
of historical changes made to sensitive data. Describe how this log includ=
es the requester and authorizer identities, and transaction timestamps. =
|
KIM has partial support for this. Specificall=
y, it uses Kuali Enterprise Workflow (KEW) in order to route changes for po=
ssible approval. KEW records the following information about a particular t=
ransaction:
* Who initiated it
* It's current status
* Who action was requested from
* Who took action
* Timestamps on all of the above
However KIM does not currently make a full copy of each record and store i=
t for historical purposes before updating the existing record. So it's not =
currently possible to do effective date reporting on records. For example, =
you can't ask it what someone's name was 3 years ago, or similar historical=
reporting. This is a feature which has been requested by the community but=
not yet implemented.
Additionally, KEW routing is typically only performed whenever updates are=
made from the user interface adminstration screens. Using the service API =
to update records does not currently kick off workflow processing.
One thing that KIM does support however on nearly all records is an "activ=
e" indicator which services as a form of logical deletion of the record. An=
d all data has a "last update" timestamp which is stored in the database.=
p> |
|
|
Describe how the registry solution supports t=
he secure storage of security questions and answers for use in password rec=
overy. |
KIM was not originally designed to store pass=
words or security questions and there has been no push from the community a=
s of yet to add support for that. |
|
|
Is there support for multiple name and addres=
s types as well as history? If yes, please describe. |
Yes, there is support for multiple name and a=
ddress types. KIM has a few built in ones: =
Name Type:
* Preferred
* Primary
* Other
=
Address Type:
* Home
* Work
* Other
The available name and address (as well as other) types can be extended an=
d there is also a user interface which can be used to maintain these or add=
new types.
See the earlier section on Audit Logging recording KIM's support for track=
ing of historical data. In the case of addresses and names, if these are ev=
er changed the old name/address will be marked as inactive and the new reco=
rd will be created as active. So, in this case, name and address has better=
capability for recording of historical changes than some of the other part=
s of KIM. |
|
Identity Assurance |
Are registration events captured as they occu=
r? Do these events automatically trigger assignment/deassignment of a=
n IAP |
KIM does not currently have support for Ident=
ity Assurance Profiles. |
|
|
Is there support for real time provisioning o=
f Identities/services |
KIM has the apis that allow for creation and =
updating of identity data. There's not much additional infrastructure provi=
ded out of the box that sits on top of this however. So if someone wanted t=
o provision realtime into KIM they would need to invoke the service themsel=
ves.
The main service in KIM through which this would be done is called the IdentityService:
|
|
|
Describe how data is processed (batch, web se=
rvices) |
Data could be processed through either batch =
or web services. Our current web services use SOAP, but there are plans in =
the future to provide RESTful interfaces to these. As mentioned previously,=
the data model is a traditional relational data model and therefore fairly=
straightforward to work with.
One of the caveats with bypassing the service layer however is that KIM ha=
s a fairly sophisticated caching infrastucture that allows applications whi=
ch are consuming information from the registry to cache that data and get n=
otified about updates to it via a message queue which will automatically fl=
ush their local cache. This allows for increased performance at the applica=
tion layer but does open the possibility of clients having stale data in th=
eir cache.
Appropriate caching configuration can alleviate this. We use Ehcache (http://ehcache.org/=
) for caching and take advantage of the Kuali Service Bus (http://ksb/kuali.org) messagin=
g layer to distribute and route notification messages. |
|
|
Is registry dependent on other open source or=
vendor products? If yes, please provide details. |
Yes, all of Kuali Rice (of which Kuali Identi=
ty Management is a module) is licensed under the Educational Community=
License and uses many other open source libraries with compatible lice=
nses.
It is designed to run inside of a standard Java servlet container (such as=
Tomcat) and takes advantage of the Spring Framework, Apache CXF, various A=
pache commons libraries, JAX-WS, Quartz, wss4j (which implements WS-Securit=
y), and JTA (the Java Transaction API) among others. |
|
|
Where is the business logic stored? Is =
there support for delegation to maintain these rules? |
Business logic is currently stored behind ser=
vice implementations which are overridable and customizable for those who i=
mplement.
Additionally, with version 2.0 of Kuali Rice a new module has been introdu=
ced called Kuali Rule Management System (http://kuali.org/rice/modules/krms=
) which is a business rule management system which can be used to maintain =
and execute business rules for routing, validation, and various other purpo=
ses. So there is the possibility for integration with that module at some p=
oint in the future. |
|
|
How does the registry notify external entitie=
s of data changes? (for example name is changed) |
Notifications about data changes are done via=
the reliable messaging component of the Kuali Service Bus. However, not al=
l events that occur within KIM trigger outbound messages at the present tim=
e and the ones that do are not very granular. For example, they are more al=
ong the lines of "entity changed" as opposed to "the entity's name changed"=
. |
|
|
Is code located in public repository |
Yes, see: http://svn.kuali.org/repos/rice/ <=
/td>
| |
|
How are changes, marketing, etc communicated =
to public? (wiki, lists, web presence) |
The Kuali Foundation has various channels tha=
t can be used for communication and the Kuali Rice project itself has some =
of it's own. This includes the following: <=
br class=3D"atl-forced-newline">
- The Kuali News Feed where release announcements and other information c=
an be shared. This then goes out to an RSS feed as well as via email to tho=
se who are subscribed. This is hosted from http://www.kuali.org
- The rice.collab@kuali.org mailing list which people can use to get help=
or ask questions. We also send out announcements about upcoming work and o=
pportunities to this mailing list.
- The Kuali Rice website (http://rice.kuali.org)
- The Kuali wiki: https://wiki.kuali.org
- The release notes, change log, and documentation for each release which=
are written and generated using Docbook. Example here: http://site.kuali.org/rice/2.0.0/reference/html/portal.html
- Bi-Monthly gatherings of the collaboration group. This is an open forum=
and anyone is permitted to attend these and ask questions or provide feedb=
ack for the group. We also discuss project status updates and project activ=
ity at this meetings as well.
- The annual "Kuali Days" conference. Once a year we have a conference wh=
ere there are many sessions and presentations given on the various activiti=
es going on within the Kuali Community: http://kuali.org/kd
|
|
|
Is there proper OSS license? |
Yes, Kuali Rice is licensed under the Educati=
onal Community License version 2.0. We have occasional code audits using 3r=
d party vendors (most recently Black Duck Software to ensure license complian=
ce.
We additionally utilize automated tools as part of our build environment t=
o ensure proper license attribution and acknowledgements in source code. |
|
|
Is there a clear project lead? |
Yes, the Kuali Rice project actually has a fe=
w different leadership positions. The project team is structured as follows=
:
* Project Manager
* Lead Technical Architect
* User Experience Architect
* Business Analyst
* Configuration Managers
* Development Managers
* Developers
The project manager handles the schedule, resourcing, and the budget. Whil=
e the technical architect is responsible for ensuring conceptual integrity =
and architecture for the product as well as doing technical design and anal=
ysis with the other technical leads. The user experience architect and busi=
ness analyst work as functional leads on requirements and ensuring that the=
system works the way it's supposed to and is easy to use. The business ana=
lyst also functions as the Quality Assurance lead for the product as well.<=
br class=3D"atl-forced-newline">
Each of the individual sub-teams on the project are lead by a development =
manager who is essentially the technical lead for that team (they do develo=
pment as well), and then developers develop the majority of the code.
At the time of this writing the Kuali Rice project currently has about 19 =
FTE working on it. Most of these are directly involved in development. Howe=
ver, it's important to note that Kuali Rice includes more than just KIM and=
is rather large in scope. So these resources are working on numerous diffe=
rent projects and modules. |
|
|
Is there an existing project steering committ=
ee/governance? |
The Rice project has the following governance=
bodies:
1) Kuali Rice Board
2) Application Roadmap Committee (ARC)
3) Technology Roadmap Committee (TRC)
All governance bodies are represented by a group of voting members. Each i=
nstitution which has invested in Kuali Rice has a vote as well as each othe=
r Kuali project which has invested in Kuali Rice has a vote. Each of the gr=
oups has a chair and vice-chair who are appointed via an election process a=
nd serve a 1-year term. Once the current chair's term is completed, the vic=
e-chair assumes the chair role and an election is held for a new vice chair=
. All groups meet on a bi-weekly basis.
The board helps the project with resource and budgetary decisions as well =
as high-level strategy and advisement.
The ARC defines the product roadmap and desired schedule via a formal road=
map prioritization process. The ARC has a standing working group called the=
Kuali Application Integration working group (KAI). This group is responsib=
le for functional governance and change management for Kuali Rice.
The TRC defines the product's technical roadmap and strategy. The TRC has =
a standing working group called the Kuali Technical Integration working gro=
up (KTI). This group is responsible for technical governance and change man=
agement for Kuali Rice.
It's important to note that while the TRC defines technical roadmap, the A=
RC is the group which makes the final decision on the roadmap for the produ=
ct based on input from the ARC, TRC, and the Kuali community. |
|