...
Release | Item | Description | |||
---|---|---|---|---|---|
2.3 | Improve folder privileges | Change folder privileges so that instead of the STEM privilege, there is an ADMIN privilege on folders. The ADMIN privilege would mean you have all rights to the folder, you can rename it, delete it, change privileges, and effectively every other privilege. The CREATE privilege would be changed to also include creating folders (in addition to groups and attributes). And the STEM_ATTR_READ and STEM_ATTR_UPDATE would remain the same. Note, so the name doesnt conflict with the group ADMIN privilege, the stem privilege will be called STEM_ADMIN. | |||
2.3 | Improve loader | Add the ability for the loader to run on multiple nodes to it has better availability. Also add the option for unresolvable subjects to not cause loader jobs to fail (note, if the source is unavailable it should fail and not remove all members, and it should only allow unresolvables up to a certain configurable threshold) | |||
2.3 | Finish the new UI, replace admin and lite UI | Add features into the new UI (from 2.2) so that everything from the admin UI and the lite UI can be performed in the new UI. Add user based auditing and overall auditing. Add new features like the ability to easily configure "rules" in the UI | |||
2.3 | Add remaining attribute/permission operations to WS | Add ability to manage attribute and permission definitions 100% via the WS. Currently many things can be done via the WS but not all. Currently the gaps can be addressed via the UI/API. | |||
2.2 | Grouper has an administrative UI, the Membership Update Web UI, and as of v2.0, additional Web UIs for attribute, role, permission, and user invitation management. Further, several substantial UIs have been created by Grouper users, usually designed to meet needs in a specifically identified context. This roadmap item is aimed at addressing how Grouper should engage, support, or borrow from these efforts to provide UI capabilities that are closer to contextual needs more often than at present. | ||||
2.2 | Add ability to tag objects in Grouper (via the new attribute framework) so that folders, groups, permissions can be grouped into a "service". The API/UI/WS could filter search results based on the service to make it easier for users to perform tasks in Grouper. See documenation page. | ||||
2.2 | In order to make Grouper more easily deployable across environments, and more easily upgradable, add ability for cascaded config files, and expression language in config file entries. There can be a default configuration file, and an override file so that only the changes from the default can be tracked in the overlay. See Grouper configuration overlay. | ||||
2.2 | Provide group, membership, and group management role information via SCIM, in partnership with SURFnet. | ||||
2.2 | Treat privileges as Group lists | Remove the pluggability of Grouper privileges (Group READ/UPDATE etc), treat them as group lists to improve WS operations, simplify the UI, etc | |||
2.2 | Built-in support for managing unix GIDs by assigning a numeric ID to each group and folder. | ||||
2.2 | Migrate from legacy attributes to the new attribute framework in a transparent way. The old API and WS and UI should still work correctly. Plan to migrate lists and hooks as well. | ||||
2.2 | COmanage integration | Work cooperatively with the COmanage project to integrate Grouper within COmanage. Integer group ID's, WS operation tweaks | |||
2.2 | Subject security realms | Differently users might have different privacy requirements for the Subject API. Security by realm is implemented in the JDBC2 source adapter. Callers pass in which "realm" the search should take place in, and the source can adjust how the search takes place, what attributes look like, etc. | |||
2.2 | Grouper user data | Store information about a user in grouper in a generic way. e.g. recently used objects. favorites, etc. | |||
On-going | Grouper Core enhancement | Continue adding capabilities to meet requirements from the field. | |||
On-going | Community contributions | Solicit and publicize community contributions of extensions and complements to Grouper. | |||
Not yet assigned | Auditing in UI | Add user based auditing, and overall auditing | Not yet assigned | Security plugins | Spring security, Shiro, .NET plugins for Grouper WS that might be able to be distributed with the plugin itself. Initial proof-of-concept code available: https://spaces.at.internet2.edu/display/Grouper/Unicon+Grouper+Contributions. |
Not yet assigned | Access Management Standard WS API | Similar to the CIFER effort, develop a standard WS API | |||
Not yet assigned | Further KIM-Grouper integration | Work cooperatively within the CIFER project to refine the Kuali KIM services interfaces and extend existing integration beyond group-level into roles & permissions. | Not yet assigned | More WS operations | Add ability to manage attribute and permission definitions 100% via the WS. Currently many things can be done via the WS but not all. Currently the gaps can be addressed via the UI/API. |
Not yet assigned | Register for notifications | Add ability for users to register to be notified of changes to specified objects. | |||
Not yet assigned | Further uPortal-Grouper integration | Complete Phase II deliverables. Time frame for Phase III deliverables still to be determined in concert with uPortal team. | |||
Not yet assigned | More provisioning connectors | Add further connectors to reflect specified group, membership, role, and permission information into external systems and services. | |||
Not yet assigned | Scaling REST webservice | An page in the Administration guide, Grouper always available web services and client, demonstrates one way to provide always available services using a specialized client. The CIFER REST web service will need the server-side capability to provide that always-available functionality. In addition the REST API should be able to access multiple, read-only caches so it can efficiently handle any increase in query requests, most of which will not need to directly access the primary database. | |||
Not yet assigned | Namespace Uniqueness Constraint | Active Directory has some constraints regarding the storing of group and membership objects of the same name. This item would create an optional API-level constraint which would prevent you from re-using a name across multiple objects (stem, group, attribute, etc). |
...