Thrill-ID

Thrill-ID is a centralised authentication and authorization rights used by the entire ThrillTech technology ecosystem. It manages authentication and authorisation for both User and Service accounts.

There are 3 main sub-systems within the Thrill-ID service:

• Systems
• Organisations
• Accounts

Systems describe the ThrillTech systems which comprise the ThrillTech technology platform (for example ThrillPots, Thrill-ID, ThrillPots Gateway, ThrillGate are all "systems"). Each system exposes its own unique set of Resources which are defined as part of the system.

Organisations define the organisations and units to which Accounts are related. Within the iGaming realm, an Organisation describes the operator and its underlying brands. Accounts can then be bound to either the Organisation as a whole, or a brand/organisational unit.

For example, lets take an example of an Operator called MegaBet which has 2 brands, namely MegaSportsBet and MegaCasinoBet. This organisation structure is defined as follows:

{
    "id": "megabet",
    "units": [
        "megasportsbet",
        "megacasinobet"
    ],
    "enabled": true
}

Finally, an Account describes either a User or Service account which can access and interact with the ThrillTech platform. Accounts can be restricted to specific System interactions, or have broad permissions across a number of System types. Accounts can be restricted not only to specific systems, but also to a subset of each system's exposed Resources.

IMPORTANT For the next sections, assume that all calls need to be authenticated. Authentication is done by passing your issued JWT token as a Bearer token in the Authorization header.

Creating a new Organisation in Thrill-ID

To create a new organisation in Thrill-ID, we use the POST /admin/organisations endpoint on Thrill-ID.

Example:

Request: POST http://localhost:9000/admin/organisations

Body:

{
    "id": "new_org_id",
    "enabled": true,
    "units": [
        "org_unit1",
        "org_unit2"
    ]
}

Once your new organisation is created, you are able to create user accounts for that organisation. It is important to note that if the organisation does not exist, attempts at creating accounts for the organisation will fail

Example: Backoffice User Account

A backoffice user account for user jackpot-manager@megabet.com which has access to both brands would most like have Write access to the ThrillPots system.

An example of such an account could look as follows:

Request: POST http://localhost:9000/admin/accounts

Body:

{
    "account_type": "User",
    "username": "jackpot-manager@megabet.com",
    "password": "password of your choosing",
    "org_unit": {
        "org_id": "megabet"
    },
    "permissions": [
        {
            "system_id": "thrillpots",
            "permissions": [
                {
                    "resource_id": "Instances",
                    "permission": "Write"
                },
                {
                    "resource_id": "Reports",
                    "permission": "Read"
                }
            ]
        }
    ],
    "enabled": true
}

Example: ThrillPots Integration Service Account

Now lets have a look at what a service account would look like if the service was intended to integrate with the ThrillPots Gateway service. This account will need Write access to jackpot Instances as well as Config access for the defined sources.

Request: POST http://localhost:9000/admin/accounts

Body:

{
    "account_type": "Service",
    "username": "thrillpots-integration-service@megabet.com",
    "password": "password of your choosing",
    "org_unit": {
        "org_id": "megabet"
    },
    "permissions": [
        {
            "system_id": "thrillpots",
            "permissions": [
                {
                    "resource_id": "Instances",
                    "permission": "Write"
                },
                {
                    "resource_id": "Config",
                    "permission": "Read"
                }
            ]
        }
    ],
    "enabled": true
}