CSC/ECE 517 Fall 2017/E1795 Single signon for Peerlogic web services (WS intergration)

Problem Statement

Description of the problem statement can be viewed on this link.

PeerLogic

To understand the problem statement, let us first understand the terms used in the problem statement:

1. Peerlogic: Peerlogic is a service provider for education peer review systems. The project exposes a number of microservices or web APIs that can be consumed by peer assessment systems. It provides services for reputation algorithms, metareview metrics, etc. To give an example, a peer review system like Expertiza leverages Peerlogic APIs to assess whether a given review was competent enough or not. There are a dozen of such systems that leverage Peerlogic’s APIs for a number of purposes. More details on Peerlogic can be viewed here.

2. Expertiza: Expertiza is a peer assessment system that is build to help students review each others work and provide feedback, facilitating learning. Expertiza uses Peerlogic’s services for various purposes.

3. Single Sign On Portal: Single sign on portal is the system that E1795 aims at building. This will serve as an authentication layer between Peerlogic and all other applications using its API.

The problem

Currently Peerlogic’s services can be used by anyone calling them. There is no system to check if an application accessing the services is actually allowed to do so. It is essential to have a system in place to authorize applications to avoid a number of security breaches that could occur using these open-to-all services and prevent them from being hacked.

Proposed Solution

The proposed solution is to create a “Single Sign On Application” that will be responsible for providing authorization and authentication for the Peerlogic APIs. This application have two major modules:

1. User facing portal: The user facing portal will be a deployed application with an user interface that a user/admin can use to register himself, request an API key for his/her app (in case of user), approve API keys (in case of admin), manage keys, and other similar functions.

2. REST APIs for Peerlogic: There will be REST API created which Peerlogic can call to check whether a request received by Peerlogic is authorized and authenticated. This API is a core feature because it is responsible for actually putting the security system in place. If the API fails to return the correct result, an application not authorized to access Peerlogic may do so, leading to a security breach.

Solution Architecture

In order to understand how the whole system will work, have a look at the figure given below.

The system includes a SSO portal, Peerlogic and different apps trying to access Peerlogic services. The types of users are admin and generic user (who will be responsible for creating a client account with SSO.

Note: In the following description, client has been used interchangeably with app.

1. Once the client users registers himself/the client, and client account is created. He can now request a client ID and a client key to be used by his/her app. (Step 1)

2. SSO sends this request forward to the admin, who either approve/reject this request. The admin tells whether the request is to be approved or not and forwards this information back to peerlogic. (Steps 2 and 3)

3. If the admin, approves the request, SSO generates a client ID and a client token that will be used by the client to send requests to SSO. (Step 4)

4. This client ID and key is seen by the consumer and they add this to the client app. (Steps 5 and 6)

5. When the client app decides it wants to call Peerlogic web services, it communicates with SSO, sending a request for a token, this request includes the client id and client key in order to let know SSO know he is a valid requester for token. (Step 7)

6. SSO generates a unique, one time use token for the client and passes it back to him. (Step 8)

7. The client now calls the Peerlogic web service and adds this token in the request as a header. (Step 9)

8. Peerlogic, after receiving the client request, sends a request to SSO with the token, asking if the token is valid and is allowed access to the service that client is requesting. SSO, at this point, checks does authorization and authentication. If all okay, it returns so. (Steps 10 and 11)

9. If Peerlogic receives a positive response from SSO, it lets client use its API, else returns an unauthorized/unauthenticated access error. (Step 12)

Challenges

There are a couple of challenges we have identified that will be the key points we shall be working on:

1. Generation of token and its authorization/authentication: The process of unique token generation and its verification is the key abstraction. We shall be looking and analysing algorithms that can help us achieve this.

2. Creating a secure database that will be used by SSO: Creating a secure and normalised database to store all the information that SSO shall be using is another challenge.

3. Creating a client id and key and storing it: Given the rise of open source software, it is essential that the client id and key that is generated for an app is stored in a secure place, invisible to the world. We will be looking into ways how open source apps do this and good practices to do the same.