Five Things You Gotta Know About Modern Identity

Mark Diodati Technical Director—CTO Office

@mark_diodati

mdiodati@pingidentity.com

Tues 13-10-15

Agenda

• Cloud Identity

• Modern Identity’s Building Blocks

• Provisioning and SCIM

• OpenID Connect

• FIDO

CLOUD IDENTITY

Digging Into Identity

On-Premises, Hybrid, Cloud

on-premises

cloud

hybrid

Cloud Identity

• Identity Management as a Service (IDaaS)

– Externally hosted, turnkey SaaS applications that perform identity management

• Users and applications may be on-premises or hosted

– OPEX, flexible with changes in economies of scale

• Identity bridge

– On-premises component to connect on-premises and externally hosted environments

– Supports multiple identity services

Cloud Orientation

to

from

in

To The Cloud (SSO + Provisioning)

Hosted

On-Premises

Active Directory

Employee

Kerberos SSO

Fed

erat

ion

SSO Syn

c (AP

I)

Directory sync

Federation IdPDirectory synchronization

Identity bridge

To The Cloud (Mobile Identity)

Externally Hosted

On-Premises

Active DirectoryMicrosoft Certificate

Services

MDM cloud service

MMC

Private key

Identity BridgeMDM

Profile/policy

Group

Group

A

Credential provisioning

App distro

From The Cloud (SSO)

OAuth relying partyOAuth authorization service

Federation SPFederation IDP

SAML-enabled applicationWAM-protected application

SAML

OAuth resource server

HTTP

co

okie

OAuth

Partner

Identity bridge

SAML, OAuth, Password, X.509

Hosted

On-Premises

From the Cloud (Provisioning)

Externally Hosted

On-Premises

Provisioning IDaaS

Active Directory

Identitybridge

Reconciliation

Manufacturing

No

rth

Am

eric

a

Euro

pe

Identitybridge

Reconciliation

Active DirectoryERP

In The Cloud (SSO + Provisioning) Provisioning

Federation IdP

HostedOn-Premises

Federated SSO

Provisioning

IDaaS

Au

the

nti

cati

on

User

MODERN BUILDING BLOCKS

Digging Into Identity

Modern Building Blocks

• REST (Representational State Transfer)

– Adopted in response to the complexity of SOAP

– Uses HTTP for its request/response

– Objects are represented as URLs

– Example HTTP verbs

• GET: retrieve object attributes

• POST: create object with new attributes

• DELETE: delete object

Modern Building Blocks

• JSON (JavaScript Object Notation)

– Adopted in response to the complexity of XML

– Data format representing name value pairs

Modern Building Blocks

• Most modern identity standards leverage JSON over REST

– Peanut butter and jelly

– OAuth (authorization), SCIM (provisioning), FIDO (authentication), OpenID Connect (multi-protocol)

• Some notable exceptions are SAML and XACML

Modern Building Blocks

POST https://pingidentity.com:8443/Users

Authorization: Basic Y249RGlyZWN0b3J5IE1...

Content-Type: application/json

{

"userType":"spy",

"externalId":“tstark86753",

"pacsSerial":"87654321",

"active":true,

"otpSerial":"12345678",

"email":“tony.stark@pingidentity.com",

"userName":"lcarroll",

"givenName":“Tony",

"familyName":“Stark“

}

REST HTTP verb (add user in SCIM)

Modern Building Blocks

POST https://pingidentity.com:8443/Users

Authorization: Basic Y249RGlyZWN0b3J5IE1...

Content-Type: application/json

{

"userType":"spy",

"externalId":“tstark86753",

"pacsSerial":"87654321",

"active":true,

"otpSerial":"12345678",

"email":“tony.stark@pingidentity.com",

"userName":"lcarroll",

"givenName":“Tony",

"familyName":“Stark“

}

In REST, objects and endpoints have

unique URLs

Modern Building Blocks

POST https://pingidentity.com:8443/Users

Authorization: Basic Y249RGlyZWN0b3J5IE1...

Content-Type: application/json

{

"userType":“superhero",

"externalId":"tstark86753",

"pacsSerial":"87654321",

"active":true,

"otpSerial":"12345678",

"email":"tony.stark@pingidentity.com",

"userName":"tstark",

"givenName":"Tony",

"familyName":"Stark"

}

JSON data representation

Modern Building Blocks

POST https://pingidentity.com:8443/Users

Authorization: Basic Y249RGlyZWN0b3J5IE1...

Content-Type: application/json

{

"userType":"spy",

"externalId":"tstark86753",

"pacsSerial":"87654321",

"active":true,

"otpSerial":"12345678",

"email":"tony.stark@pingidentity.com",

"userName":"tstark",

"givenName":"Tony",

"familyName":"Stark"

}

PROVISIONING

Digging Into Identity

Provisioning: Definition

• Addition, deletion and modification of users – Typically across heterogeneous applications

• Workflow – From simple to complex

• User self-service

• Initiated via a feed from an external system (e.g., HR)

• Primary user constituency is the employee and (increasingly) partners and contractors

• User access requires provisioning

– Access are not possible without an identity in the target application

– SaaS applications require identity siloes, due to service level and security concerns

• Results of poor provisioning

– Decreased productivity

– Excessive access: compliance violations, data breaches, unauthorized transactions

Provisioning: Why Care?

User Provisioning

• Protocols

– Examples include REST, SOAP, LDAP, application-specific APIs, CSV, FTP

• Schemas

– In order: user, group, entitlement, manager, extensible objects

– Attribute data model (e.g., multi-valued, compound)

is irregular across different identity stores

Anatomy of a Provisioning Service

User Provisioning

• Identity at scale

• Many protocols and multiple user constituencies means that provisioning are difficult to manage

• Proprietary provisioning connections are fragile

• Application revisions require analysis and potential rewrite of the consumer (e.g., provisioning system)

Provisioning Standards: Why Care?

User Provisioning

Standards-Based Provisioning

• SCIM is our last best hope at standards-based provisioning

• Support by application vendors will be necessary – Participation by Cisco, Microsoft, Google, Ping

Identity, and Salesforce hints at broad industry support

• Optional standard user schema

• As of October 2013, most of the v2 features are defined – v2 is not compatible with v1.1

The Case For SCIM

SCIM Components

Externally Hosted

On-Premises Create u

ser(H

TTP P

OST)

Identity system(SCIM consumer)

SaaS application(SCIM service provider)

SCIM + Federated SSO

Active Directory

Active Directory

SCIM consumerFederation IDP

SCIM providerFederation SP

Kerberos SSO

Directory sy

nc

Federated SSO

SCIM

Directory sync

SSO

Au

tho

rization

qu

ery

Partner One Partner Two

OPENID CONNECT

Digging Into Identity

Why Not Just Use OAuth?

• OAuth is:

– Valuable as an access delegation protocol

– A good fit for native mobile applications

– Friendly for developers

• OAuth is not:

– A user identity protocol

– An “identity at scale” protocol

OAuth Components and Flow OAuth

authorization serverOAuth

resource server

Web browserNative application

1. Browser instantiated

3. T

oken

refe

renc

e re

turn

cod

e

4. Code delivery

2. U

ser a

uthe

n/co

nsen

t7. Access token presentation

6. Tokens downloaded

8. Access to application resource

A

accesstoken

R

refreshtoken

AOAuthclient/relying party

5. Reference code + authenticationA

OpenID Connect Flow OpenIDProvider

OAuthresource server

API AccessUser in

formatio

n

OAuthclient/relying party

A

accesstoken

R

refreshtoken

ID

IDtoken

A

authorization serveruser information endpoint

A

Tokens

OpenIDProvider

API AccessUser in

formatio

n

OAuthclient/relying party

A

accesstoken

R

refreshtoken

ID

A

authorization serveruser information endpoint

A

Tokens

OpenIDProvider

ID

AR

OIDC Flow Redux OpenID

Provider #1OAuth

resource server

API AccessUser in

formatio

n

OAuthclient/relying party

A

accesstoken

R

refreshtoken

ID

IDtoken

A

authorization serveruser information endpoint

A

Tokens

OpenIDProvider #2

ID

AR

OpenID Connect Protocols

Optional discovery of OpenID providers

OpenID Connect Protocols

Optional automated registration of clients (e.g., server applications, mobile devices)

OpenID Connect Under The Covers

• OAuth 2.0 specifications

• JSON Web Token (JWT)

• JOSE

– JSON Web Signature (JWS)

– JSON Web Encryption (JWE)

– JSON Web Algorithms (JWA)

– JSON Web Key (JWK)

FIDO

Digging Into Identity

FIDO—A Tale of Two Protocols

• FIDO Unified Authentication Framework (UAF)

– Local mobile biometrics

– Initially proposed by Lenovo, Nok Nok, PayPal, others

– Also supports non-biometric authentication

• Universal Second Factor (U2F)

– “Smart” smart card

• Initially proposed by Google and Yubikey (first to partner)

FIDO UAF

F

authenticator(s)

(2)

FID

O h

and

shak

e

FIDO Client

FFIDOServer

device attestation F

device key pair

site-specific key pairs

(1) user authenticationto FIDO client

Binding of user info and public key

(3)

Asy

mm

etrc

i key

au

thn

FIDOAttestation

Service

web site/RP

ID Proofing

UAF to OpenID Connect

F

(2)

FID

O h

and

shak

e

FIDO client

F

OpenID Provider

(1) user authenticationto FIDO client

(3)

asym

met

ric

key

auth

n

FIDO authenticationmodule

A mobile application (relying party)

Binding of user info and public key

(4)

Toke

n in

form

atio

n

(5) A

PI re

quest/

resp

onseID A R

A

tokens

FIDO U2F web site/RP

device key pair (per batch)

site-specific key pairs(with Key Handles)activation button

siteauthn service

(activation required during enrollment and optional at

runtime)

U2Fauthn service

(1)

use

r p

assw

ord

au

th

(2)

Ch

alle

nge

res

po

nse

, w

ith

Key

Han

dle

User info, public key and Key Handle

device attestationattestation

service

U2F to Federation Federation IDP

primaryauthn service

U2Fauthn service

(1)

use

r p

assw

ord

au

th

(2)

Ch

alle

nge

res

po

nse

, w

ith

Key

Han

dle

User info, public key and Key Handle

(3) S

AM

L cr

eden

tial

s

Federation SP

(4) SAML credentia

ls

Copy right ©2013 Ping Identity Corporation. All rights reserv ed. 42