Components in ecosystem Perun
Core handle all Perun`s base tasks related to management of all stored entities (e.g. users, groups, resources,...) and their mutual relationships. It ensures consistency of data stored in DB which are then presented to other Perun`s components, system end users or services it manages.
Core also allow synchronization of users and groups with external sources. It's necessary to provide XML definition of connector, which maps data from external source to entities in Perun and also query, which loads the data from external source. External source can be any type of SQL database, LDAP or practically any system, that returns data in expected format.
These three components works together and ensures, that services configuration is successfully propagated to all resources managed by Perun. Perun uses push style of service configuration. This ensures, that current configuration state (reflecting any changes in Perun) is delivered to all related resources as soon as possible (e.g. in case of resource outage) and we can monitor and report any error, that happen during service configuration on destination resource.
Services are usually configured on destination resources with help of Bash and Perl scripts, that can be conveniently installed and keep updated using .deb or .rpm packages. Perun also support sending new configuration state to an email or URL.
Perun is able to manage any new service you are about to use in future. You just simply need to define what information service require from Perun, store such information in system and write 2 scripts, that generates new configuration files and apply them to service on destination resource.
Registrar is a component, which allows to create custom registration form to the virtual organization/project or to the particular group. Application form can be protected by various authentication systems which can provide additional information about the user, so the registration form can have some fields prefilled. For example if the access to the registration form is protected by the federated login, most of the fields on the registration form will be preffiled from the received attributes from user's identity provider.
On the registration form virtual organization/project manager can define various fields like texts, input fields, drop-down lists, logos and many more. All data entered by the users can be checked for proper syntax before submitting the form.
Project manager can define two types of the registration forms. Initial registration form is used for the newcomers to the virtual organization/project. Extension registration form is used for the uses who wants to extend theirs membership in the virtual organization/project, if the project manager defined membership expiration period. Extension registration form is also usually used to update user's information stored in Perun. Project manager can define how the application forms will be approved, manually or automatically.
For each operation with the registration form, virtual organization/project manager can define mail notifications, for example: send an email with the user's name and organization to the virtual organization/project manager when user submits the registration form. Or notify user when his/her application has been approved.
Cabinet is a component where users can report theirs publications where they acknowledge to the project or resource providers. Cabinet is able to import publications from various publication management systems run on universities. Project manager or resources provider can consider giving you more resources or privileges for future research based on reported publications.
Perun stores information in the database and has several APIs through which external applications can read data stored in the Perun. Quite a lot applications understands LDAP protocol, therefore Perun provides LDAP interface for its data. Perun can provide undefined number of LDAP interfaces with different settings
Every operation made in Perun is audited in the auditer log. Who, when and what was done is audited. Component called Auditer sits on top of the audit log. External applications can register listener on Auditer, all listeners then received audit messages. If the listener disconnects for whatever reason, auditer will send all missing audit messages after successful reconnection.