Delivering Identity at Internet Scale

© 2016 ForgeRock. All rights reserved.

Delivering Identity at Internet Scale

Andy Hall


Session Contents• Identity Services• Why Internet Scale• How scale creates problems• Approaches to address the issues

2


Identity Services• Authentication

App1 App2 App3

Identity


Identity Services• Authentication• SSO

Identity

App1 App2 App3


Identity Services• Authentication• SSO• Federated Identity

Identity

App1 App2 App3

Identity

App1 App2 App3


Identity

App1 App2 App3

Identity Services• Authentication• SSO• Federated Identity• Authorization

Identity

App1 App2 App3


Identity

App1 App2 App3

Identity Services• Authentication• SSO• Federated Identity• Authorization• Self-service

Identity

App1 App2 App3


Internet Scale

Mobile devices: 7.5 billionIoT Devices: 4.9 billion

Analysts predict rapid growth

Identity will be at the center

Estimated 4 connected devices per person by 2020 (source: Strategy Analytics)


So what’s the problem?


Internet Scale

• Scale • Elasticity• Geographically dispersed• Consistency• Security

Internet

Elastic Load Balancer


Session Management

• Cluster load balancing• Failover Storage• Session held in server memory• Session persisted for failover

Stateful deployment


Microservices and OAuth2/OIDC• Distributed OAuth architecture• Datacenters in geographically separate locations

• Client can obtain token from any server

• Client must validate token on any server

12

Identity Identity Identity

Microservice

IrelandAWS

GermanyAWS

GermanyOn-prem

Microservice


So what’s the solution?


Session Management: Stateful

• Cluster load balancing• Failover Storage• Session held in server memory• Session persisted for failover

Stateful deployment


Session Management: Stateless

• Simplified load balancing• No failover storage required• No in-memory Session• Session stored in client

Stateless deployment


How do Stateless Sessions Work?

• Uses JSON Web Token (JWT)• Session is Signed

•HMAC Shared Secret•Session can be Encrypted

•RSA 256

Comparison of Stateful and Stateless


Example: Stateful vs Stateless

Stateful communication: global replication Stateless communication: no replication


Demo

18


Deployment CharacteristicsStateful Sessions Stateless Sessions

Memory: Stored in Server memory CPU: Decrypt/Verify Signature

Session persists in Database Session persists in Client

Vertical Scalability Horizontal Scalability

Load Balancer: Sticky Load Balancer: Round Robin


Performance ComparisonTest Setup: Stateful• 2 OpenAM servers• 2 OpenDJ servers• Standard failover• External Load Balancer

Test Setup: Stateless• 2 OpenAM servers• No failover• Session Signing• External Load Balancer

Dell PowerEdge R620


Performance Test ObjectiveSession Management performance comparison

• Sustained duration• 5,000 concurrent users• Login, validate, logout• Basic Stateless

• Signing• No blacklist

Gatling (http://gatling.io)


Performance Graphs

Stateful Sessions3,000 Login/Second

Stateless Session5,000 Login/Second


Performance AnalysisExpectations:Stateful faster, in memory SessionsStateless processing time slower

Actual Result:Process Stateless Session quickStateful code path obvious factor

Comparison of path through code base


Microservices

24


Microservices and OAuth2/OIDC• Distributed OAuth architecture• Datacenters in geographically separate locations

• Client can obtain token from any server

• Client must validate token on any server

25


Microservice

IrelandAWS

GermanyAWS

GermanyOn-prem

Microservice


Stateless OAuth2/OIDC• Use an OIDC token• Embed extra claims in OIDC token

• New token validation endpoint• /idtokeninfo

• Validates token• Returns claims as json

26


Microservice

IrelandAWS

GermanyAWS

GermanyOn-prem

Microservice


However…

27


Session Logout• Purpose of logging out:

• Reduce time window to exploit session (stolen or CSRF)

• Remove cookies from client• Destroy/invalidate session state

• But how if the state is on the client??


Approaches• Blacklist

• On logout add session to blacklist• Only store unexpired sessions on blacklist• Requires some state on server• Needs to be checked on every request• Needs to be replicated

• Blacklist cache• Bloom filters


Bloom Filters!• Exciting data structure of the decade!• Represent very large sets, using only a few bits per element• Probabilistic answers to “is x in the set”:

• Definitely not, or• Maybe (with some probability of false positives)



Usage• To check if session has been logged out:

• Check Bloom Filter first - if answer is ‘no’ then session is definitely still valid

• Otherwise, delegate to blacklist to check for sure• Can still cache (much smaller) set of requests to Blacklist: BF -> LRU -

> Blacklist


Tuning• Bloom Filters never produce false negatives, but can produce false positives

• Can tune the probability of false positives to any desired probability!

• Two parameters to tweak:• Size of the BitSet (# bits per element)• Number of hash functions


False Positive ProbabilityGiven a maximum number of items to insert, n, and a maximum false positive probability, p, can compute optimal size of bit set (m) and number of hash functions, k:

NB: lots of independence assumptions!


ExampleTo allow 10,000 elements with a 1% (expected) chance of false positives:


Examples# BLACKLISTED SESSIONS SIZE (1% FPP) SIZE (0.1% FPP) SIZE (0.01%

FPP)

10,000 11.7kB 17.6kB 23.4kB

100,000 117kB 176kB 234kB

24,000,000 27.4MB 41.1MB 54.8MB

1,000,000,000 1.12GB 1.67GB 2.23GB


Scalable Bloom Filters• Size of BF scales linearly (for given FPP) with number of elements to store

• But what if we don’t know how many elements needed?

• Scalable Bloom Filters:• Chain bloom filters together• When one is saturated create a new

one• Always insert at end, check all in list

for maybeContains


Scalable Bloom Filters• Problem: FPP for chain of Bloom Filters is (bounded by) sum of FPPs for each filter

• Solution: decrease FPP for each successive filter by geometric series:

• e.g., with r = 1/2, P0 = P/2, P1 = P/4, P2 = P/8, …

• Also increase size of each bucket by another geometric progression (e.g., doubling)


Removing Expired Sessions• Only need to blacklist sessions until

they have expired• Then remove them to reclaim space• Counting Bloom Filters - increment

counter instead of setting a single bit, can decrement to remove (more complex, more space)

• Alternative: record last expiry time of all elements with each bucket in Scalable BF

• Destroy bucket when all sessions inside have expired


Summary• Delivering Identity at Scale

• Scale equates to a dynamic, elastic environment

• Dynamism introduces consistency challenges

• Consistency required for security• Deviously difficult to do well

• Good news• Most of the challenges can be

addressed with good Computer Science


Thank You!Andy Hall

Product Manager, [email protected]

Technology

Delivering Identity at Internet Scale