sphinx-project.eu / News  / Blog  / SPHINX Toolkit’s service management and authorisation procedures

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).

Technical Specifications

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.