Что нам стоит ААА построить?

Oleksii Petrov

Skelia Ukraine / ETWater

Who am I? 

System Architect

Team Lead

PHP Developer

Find me on

@alexhelkar

alexhelkar

https://github.com/alexhelkar

Identification

Authentication

Authorization

Accounting

Domain

I-A-A-A

Identification

Identification

Coffee Shops

Coffee Shop: Workflow

Killer Feature

As a

Coffee shop owner

In order to

Give a discounts to returning customers

I want to

Earn more money

Coffee Shop:

Discounts Solution

Coffee Shop:

Discounts Solution

Stateless
Coffeeshop

HTTP Cookies (1996)

Cookies: Subsequent Request

Cookies: Embedding data

Where the data lives?

Adding Security

Adding Security

Subsequent Requests

Is that still secure?

How to protect yourself?

What if?

What if?

Hooray!
We invented Sessions...

Now, state is our problem

Now, state is our problem

Scale: Step 1

Scale: Step 1

Scale: Step 2
Shared Cache

Scale: Step 2
Scaling the system

Scale: Step 3
Distributed Cache

Scale: Step 3
Eventual Consistency

Scale: Step 4
Sticky Session

The Web has changed

(2008)

REST

RIA

SPA

AJAX

MVC

Stateless REST

State Awareness

Plugable storages

We are not asked to save server's state anymore

Easy to scale

What about Identification? 

Let's design a Token

ID Token Requirements

Self-contained

Expiration Date

URL-safe

Secure

ID Token Design: Self-contained

{
  "exp": "1497052800",
  "name": "John Doe",
  "admin": true
}

Data

Base64(Data)

ew0KICAiZXhwIjogIjE0OTcwNTI4MDAiLA0KICAibmFtZSI6ICJKb2huIERvZSIsDQogICJhZG1pbiI6IHRydWUNCn0=
{
  "alg": "HS256"
}

Meta

Passphrase

my-secret-passphrase

ID Token Design: Security

Base64(Data)

ew0KICAiZXhwIjogIjE0OTcwNTI4MDAiLA0KICAibmFtZSI6ICJKb2huIERvZSIsDQogICJhZG1pbiI6IHRydWUNCn0=
ew0KICAiYWxnIjogIkhTMjU2Ig0KfQ==

Base64(Meta)

ID Token Design: Security

HMACSHA256(
  Base64(Meta).Base64(Data),
  "my-secret-passphrase"
)
d0Ao0wmaXL_X3uxLPL8K58DJvyq7vjbrFJFg85mrMe4

SIGNATURE

Base64(Meta).

Base64(Data).

SIGNATURE

eyJhbGciOiJIUzI1NiJ9.eyJleHAiOiIxNDk3MDUyODAwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.d0Ao0wmaXL_X3uxLPL8K58DJvyq7vjbrFJFg85mrMe4

Hooray!
We invented a

JWT Tokens...

Workflow

HMAC

RSA

A Unicorn?

Real Life Example

Token

Authentication Server

Resourse Server

The Platform

Issues?

Invalidate a single
Token

Change a JWT Secret Key

Create a Blacklist

Shared Cache

Create a Blacklist

Distributed Cache

Short TTL

Really?

JWT Benefits?

Store on a client?

Session/Local storage could be a security issue

Easier to use?

NO! It's not! Session management is you problem

More secure?

Same as signed cookie. You can sign anything you want

JWT Benefits?

Built-in expiration?

Expiration could be used in ANY server-side implementation

Easier to use?

NO! It's not! Session management is you problem

More secure?

Same as signed cookie. You can sign anything you want

JWT Benefits?

Data goes stale

Any data you put in token will live until expiration date

Tokens invalidation

Impossible to resolve this issue and remain stateless

JUST A TOKEN FORMAT!

JWT just a format for a token as many others out there

How Metro solves their problem?

+ Blacklist

+ Local cache
on station

+ Eventual
Consistency

+ Central server

https://habrahabr.ru/post/141213/

What to use?

OAuth2

Authentication framework

Bearer Tokens

State stored on a servers

JWT

Could be premature. Hard to keep stateless. (Remember Metro?). Useful in scoped env.

Could migrate later, because clients do not matter

Let's talk microservices

Real Life Microservices

API Gateway

Microservices

Otolaryngologist

Service

 

Neurologist

Service

 

Surgeon

Service

 

Doctor's Appointment

Do you really think that programmers invented microservices?

API Gateway

(pattern)

Common things...

Rate Limit

Parameters validation

Authorization

Load balancing

Circuit breaker

CORS Headers

IP Restrictions

Usage Limits

Caching

Request Transformer

Response Transformer

How it looks?

The "Pattern"

Not a SPOF

Enhance 3rd parties

Resell 3rd parties

Solutions

Kong

API Gateway

AWS

API Gateway

Amazon

Mashape

2015

AWS Gateway

Our case

Our case

Authorization (V1)

Authenticated Users

Can access only own data 

Anonymous Users

Can access only anonymous data by ID 

Authorization V2

Domain

Hierarchy

Sharing Access

Shares Read Access

Family Access

Company Access

Service Accounts

Limited Access to one/multiple companies

Others

Limited Access to one/multiple users

Admin Accounts

Full Access to all accounts

Hierarchical Data

Observations

Users

User Groups

Sharing Concept

Resousrce

{
    "name": "User",
    "actions": ["User::READ"]
}

Resousrce

{
    "name": "User",
    "actions": ["User::READ"]
    "actionsToIds":[
       "MODIFY": [
          "454f99ea0ed23",
          "ae0381edcb6f6"
       ]
    ]
}

Resousrce

{
    "name": "User",
    "actions": ["User::READ"]
    "actionsToIds":[
       "MODIFY": [
          "454f99ea0ed23",
          "ae0381edcb6f6"
       ]
    ],
    "children": [
        {
           "name": "Project",
           "actions": ["Project::REPORTS"]
        }
    ]
}

User

{
     "id": "0e78bce089b43"
}

User

{
     "id": "0e78bce089b4"
     "shared": [
        "56a0a8e364ed": [
           // Resources list
        ]
     ]
}

User

{
     "id": "0e78bce089b4"
     "shared": [
        "56a0a8e364ed": [
            {
               "name": "Project",

               "actions": ["Project::REPORTS"]
            }
        ]
     ]
}

User

{
     "id": "0e78bce089b4"
     "shared": [
        "56a0a8e364ed": [
            {
               "name": "Project",

               "actionsToIds": {
                  "Project::REPORTS": [
                     "80dfd6e7c112"
                  ]
               }
            }
        ]
     ]
}

User

{
     "id": "0e78bce089b4"
     "shared": [
        "56a0a8e364ed": [
           // Resources list
        ]
     ]
     "usersSharedToMe": [
        "8ddc2a735157"
     ]
}

Group

{
     "id": "e6443763fa73"
     "shared": [
        "56a0a8e364ed": [
           // Resources list
        ]
     ]
     "usersSharedToMe": [
        "8ddc2a735157"
     ]
}

Rule of Thumb

Most concrete Authorization Rules should WIN

Collapsing Rules

Collapsing Rules

{
     "id": "0e78bce089b4" // USER 1
     "shared": [
        "56a0a8e364ed": [ // USER 2
            {
               "name": "Project",

               "actionsToIds": {
                  "Project::REPORTS": [ // ACTION 
                     "80dfd6e7c112" // PROJECT
                  ]
               }
            }
        ]
     ]
}

Collapsing Rules

[
   {
     "filter": [
        "userId": "56a0a8e364ed", // USER 2 
        "actions": [User::FULL_ACCESS]
     ] 
   },
   {

     "filter": [
        "userId": "56a0a8e364ed", // USER 1
        "projectId": "80dfd6e7c112", // Resource 
        "actions": [Project::REPORTS] // Action
     ] 
   }
]

Out of a demo

API Endpoint + Method

Defines scope of ACL rule to be sent

User Groups

ACL Service managing who consist in what group

Resource ID field

Defined in configs

AWS S3 Example

{
  "Id": "Policy1487428541537",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1485128492714",
      "Action": [
        "s3:AbortMultipartUpload",
        "s3:CreateBucket",
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::your-bucket/*",
      "Principal": "*"
    }
  ]
}

And remember ...

There is no Unicorns

out there

Thanks!

Questions?

Find me on

@alexhelkar

alexhelkar

https://github.com/alexhelkar