SPHINX Toolkit’s service management and authorisation procedures
The SPHINX Service Manager (SM) component keeps the registry of services managing information such as the service name, description, URL, version, call method, exceptions, security, and permissions based on role management.
Different roles are supported by this component. For example, a role name “admin” is featured that manages the users by creating, updating and deleting users and their access rights to services and resources; the “admin” can also define a service by providing all the necessary information (service name, description, URL, version)and this information (the service definition) which is stored in the services repository of the SM component.
It can also serve as a mediator responsible for authenticating clients and authorising access to services or resources. Users of the SPHINX services are required to authenticate in order to gain access to the services requested. Different privileges are defined per user and service account, relevant to the roles and permissions assigned to such account. After authentication, a session ticket is provided to the user which is included in requests for registered services to validate the authority of the user and allow access to the requested service.
The ticket shall not be replicable and guessable. At this point, it should be noted that each ticket is associated with a session and can either expire after timeout, be infinitive or be used for a specified number of times. The SM component determines whether the ticket is valid, and the session is still active. If the ticket (token) is not valid or the user does not have the authority to access the service(s), an error message is returned. Otherwise, the requestor of the service can invoke the requested service(s).
Based on VOLERE methodology (Robertson & Robertson, 2017) as adapted by the SPHINX Project, there are two technical requirements/specifications for the SM component.
On the one side, the component produces and stores a registry of SPHINX Services. That is, the SM allows users to add/delete or update services at the registry.
On the other side, the component embeds an appropriate authentication and authorisation scheme, in order to allow users to access the SPHINX services based on roles and permissions assigned to the user and service accounts.
More information about the Service Management component can be found at Deliverable 2.6 which is publicly available here.