Kuali Identity Management (KIM) provides central identity and access management services. It also provides management features for Identity, Groups, Roles, Permissions, and their relationships with each other. All integration with KIM is through a simple and consistent service API (Java or Web Services). The services are implemented as a general-purpose solution that could be leveraged by both Kuali and non-Kuali applications alike.
Furthermore, the KIM services are architected in such a way to allow for the reference implementations to be swapped out for custom implementations that integrate with other 3rd party Identity and Access Management solutions. The various services can be swapped out independently of each other. For example, many institutions may have a directory solution for identity, but may not have a central group or permission system. In cases like this, the Identity Service implementation can be replaced while the reference implementations for the other services can remain intact.
KIM identity concepts include principals and entities. An entity is a person or system which exists within KIM. A principal represents an entity that can authenticate into an application. These are collectively referred to as a Person which can be created and maintained using GUI screens provided by KIM.
Groups consist of one or more principals or other groups. KIM provides services and GUI screens for querying and maintaining groups and their membership.
Permissions are the ability to perform actions. KIM provides services for performing authorization checks against these permissions. Permissions are always granted to roles, never directly to principals or groups.
Like permissions, responsibilities are granted to roles. They define what responsibilities members of that role have, such as Approving certain documents. Responsibilities are how KIM integrates with the KEW workflow engine.
Permissions and responsibilities are granted to roles. Principals, groups and other roles are assigned as members of a role. Qualifications can also be placed on role membership (i.e. a member of "Account Manager" role for account "12345"). Members of a role are given all permissions and responsibilities that have been granted to the roles.
Derived roles are roles which pull their membership dynamically from some external source system. It's not realistic to assume that all roles will or can be built and defined within KIM. Derived roles allow for this dynamic resolution of role membership.
KIM supports pluggable components that can be used to define complex or custom logic for evaluating permissions. These can be published on the service bus or deployed alongside the KIM services.
KIM provides GUI screens for central management and lookup of identity and access-related data. This includes Person maintenance, Role maintenance and Group maintenance. Additionally, there are numerous lookup screens which can be used to query for information about different pieces of KIM data.
KIM itself does not implement authentication services. It's assumed that an implementer will use existing services (such as CAS or Shiboleth) for this. However, KIM provides a service abstraction which allows for integrating with the authentication systems to help extract information about who has authenticated to the application.
Having trouble finding something? Let us know
Copyright © Kuali Foundation 2011