To ease OpenConext deployment, several sample implementations of these components can be installed as part of the OpenConext VM. These include:
- Teams, a federated self-service GUI for managing collaboration groups which uses Internet2’s Grouper as its back-end;
- Mujina, a mock SAML2 IdP and SP, and
- Profile, an SP that displays profile, groups and application information to end-users. A MySQL database is shared among OpenConext components for storing configuration data.
There is is ready to use VM image to build an OpenConext Virtual Machine.
You can either:
- Install OpenConext on your own server / VM. This option is recommended if you already have a target machine for OpenConext.
- Let Vagrant install and manage a new virtual machine for you. This option is recommended if you already use Vagrant.
Read more on: Github
Group management capabilities
The remainder of this section focuses on Teams and Grouper, which serve as the basis for the group management capabilities of OpenConext. More specifically, besides serving as an authentication proxy, OpenConext can be configured as a Group proxy. In this context, it allows Group providers to be connected using the Grouper API or the VOOT API. When an SP submits a query to the Group API, all available group information of a given user can be combined taking into account the access control list(s) and attribute release policy in effect for that particular SP. The default OpenConext installation contains the Teams application for managing groups. This provides an easy to use interface for end-users to self-manage groups after login into the application via an IdP. Teams allows an authorised end-user to: create teams; invite and re-invite other team members via email; manage team members; assign basic roles like admin, manager and member; combine groups from connected group providers into new (virtual) teams; search for publicly available teams; request membership information of existing teams.
Finally, OpenConext exposes the OpenSocial/VOOT API for the exchange of user and group information using a standardised REST API. The OpenSocial/VOOT API only implements People and Group REST API calls, it is thus a partial OpenSocial Container implementation. For authorisation purposes, the REST API uses OAuth 2.0 (preferred) and optionally OAuth v1 (deprecated, though still functional).