overture/ego repository overview

⁠ EGO

A scalable stateless Authorization Service for Federated Identities including Google and Facebook

⁠Table of Contents

• Documentation⁠
• Introduction⁠
• Features⁠
• Tech Stack⁠
• Quick Start⁠
• Development Install⁠
  • Step 1 - Setup Database⁠
  • Step 2 - Run⁠
• Tech Specifications⁠
• Usage⁠
• Shoutouts⁠
  • Browserstack⁠

⁠Documentation

Explore documentation with the Ego Read the Docs⁠.

⁠Introduction

Authorization Service built to provide Single Sign On for various microservices in an application. EGO works with Identity Providers such as Google, Facebook to provide social logins in the application. EGO provides stateless authorization using JWT (JSON Web Tokens)⁠ and can scale very well to a large number of users.

Interactive documentation of the API is provided using Swagger UI.

When run locally this can be found at: http://localhost:8081/swagger-ui.html⁠

EGO Architecture

⁠Features

Here are some of the features of EGO:

• Single Sign on for microservices
• User-authentication through Federated Identities such as Google, Facebook, Github (Coming Soon), ORCID (Coming Soon)
• Uses JWT(Json Web Tokens) for Authorization Tokens
• Provides ability to create permission lists for users and/or groups on user-defined permission entities
• Built using well established Frameworks - Spring Boot, Spring Security

⁠Tech Stack

The application is written in JAVA using Spring Boot and Spring Security Frameworks.

• Spring Security⁠
• JWT (JSON Web Tokens)⁠: This project uses jjwt library⁠ for JWT related features.
• OpenID Connect⁠

⁠Quick Start

The goal of this quick start is to get a working application quickly up and running.

Set the API_HOST_PORT where ego is to be run, then run docker compose:

API_HOST_PORT=8080 docker-compose up -d

Ego should now be deployed locally with the swagger ui at http://localhost:8080/swagger-ui.html

⁠Development Install

⁠Step 1 - Setup Database

1. Install Postgres
2. Create a Database: ego with user postgres and empty password
3. Run the migrations found here: SQL Script⁠ to setup tables.

⁠Database Migrations with Flyway

Database migrations and versioning is managed by flyway⁠.

1. Download the flyway cli client here: flyway-commandline⁠
2. Unpack the client in a directory of your choosing
3. Execute the flyway client pointing it to the configuration and migration directories in this repository.

Get current version information:

./fly

Run outstanding migrations:

./fly migrate

To see the migration naming convention, click here.⁠

⁠Step 2 - Run

• EGO currently supports three Profiles:
  • default: Use this to run the most simple setup. This lets you test various API endpoints without a valid JWT in authorization header.
  • auth: Run this to include validations for JWT.
  • secure: Run this profile to enable https
• Run using Maven. Maven can be used to prepare a runnable jar file, as well as the uber-jar for deployment:

$ mvn clean package

To run from command line with maven:

$ mvn spring-boot:run

⁠Tech Specifications

ego JWT will have a similar format as the one described in RFC: kf-auth-rfc⁠ An example ego JWT is mentioned below:

{
    "alg": "HS512"
}
.
{
    "sub": "1234567",
    "iss": "ego:56fc3842ccf2c1c7ec5c5d14",
    "iat": 1459458458,
    "exp": 1459487258,
    "jti": "56fd919accf2c1c7ec5c5d16",
    "aud": [
        "service1-id",
        "service2-id",
        "service3-id"
    ],
    "context": {
        "user": {
            "name": "[email protected]",
            "email": "[email protected]",
            "status": "Approved",
            "firstName": "Demo",
            "lastName": "User",
            "createdAt": "2017-11-23 10:24:41",
            "lastLogin": "2017-11-23 11:23:58",
            "preferredLanguage": null,
            "roles": ["ADMIN"],
            "groups": ["GroupOne", "GroupTwo"],
            "permissions": ["Study001.WRITE", "Study002.DENY"]
        }
    }
}
.
[signature]

⁠Notes

• "aud" field can contain one or more client IDs. This field indicates the client services that are authorized to use this JWT.
• "groups" will differ based on the domain of client services - each domain of service should get list of groups from that domain's ego service.
• "permissions" will differ based on domain of client service - each domain of service should get list of permissions from that domain's ego service.
• Unit Tests using testcontainers will also run flyway migrations to ensure database has the correct structure

⁠Usage

⁠Application Authentication

Applications can be added to EGO with a client ID/Secret pair. The ID and Secret can be used to authenticate with EGO to retrieve a JWT.

An application JWT will not have roles but will list the groups the application is associated with. Other applications are responsible for controlling authorization for applications based on the content of their signed JWT.

⁠Register application

To register an application with EGO make a request as documented at /swagger-ui.html#!/application-controller/createUsingPOST⁠

This request must have an ADMIN role JWT in the Authorization field.

Keep the client ID/Secret pair in a secret place, for use by the application only. Do not make these values visible in the browser or in your code base.

⁠Authenticate

Authentication uses the oauth client_credentials flow. This can be handled out-of-the-box by many REST clients (ex. Insomnia⁠).

The Authenticate request details, to recreate manually:

• POST request to https://{{ego-domain}}/oauth/token
• Body content, content-type: x-www-form-urlencoded
  • grant_type:client_credentials
  • client_id:{{application's client id}}
  • client_secret:{{application's client secret}}

curl example:

  http://localhost:8081/oauth/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'grant_type=client_credentials&client_id=my-app-id&client_secret=secretpassword'

⁠Shoutouts

⁠Browserstack

Many thanks to Browserstack⁠ for giving our test capabilities a powerup!