Modern identity supports the new world built on device-independent, location-anywhere access. New-school provisioning and authentication are requiremed. Its protocols are increasingly built upon frameworks like REST and JSON; examples include SCIM, OAuth OpenID Connect and FIDO. Modern identity leverages IDaaS and identity bridges to manage users and applications across the hybrid cloud.
5. 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
7. Hosted
On-Premises
Sync (API)
Federation SSO
To The Cloud (SSO + Provisioning)
Identity bridge
s
ero
b
Ker
Employee
Dire
ctor
y
SSO
syn
c
Federation IdP
Directory synchronization
Active
Directory
8. To The Cloud (Mobile Identity)
MDM cloud
service
Private key
Profile/policy
Credential
provisioning
Group
A
App distro
Externally Hosted
On-Premises
Group
Microsoft
Certificate
Services
Identity Bridge
MDM
Active Directory
MMC
9. From The Cloud (SSO)
Partner
SAML, OAuth,
Password, X.509
Hosted
On-Premises
OAuth relying party
OAuth authorization service
Federation SP
Federation IDP
OAuth resource server
HTTP
cookie
uth
OA
Identity bridge
WAM-protected application
SAM
L
SAML-enabled application
10. From the Cloud (Provisioning)
Provisioning
IDaaS
Externally Hosted
ERP
Reconciliation
Active Directory
Europe
Identity
bridge
North America
On-Premises
Identity
bridge
Manufacturing
Reconciliation
Active Directory
11. In The Cloud (SSO + Provisioning)
IDaaS
Provisioning
Provisioning
Federation IdP
Authentication
Federated SSO
User
Hosted
On-Premises
13. 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
14. Modern Building Blocks
• JSON (JavaScript Object Notation)
– Adopted in response to the complexity of XML
– Data format representing name value pairs
15. 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
16. Modern Building Blocks
POST https://pingidentity.com:8443/Users
Authorization: Basic Y249RGlyZWN0b3J5IE1...
Content-Type: application/json
{
"userType":"spy",
"externalId":“tstark86753",
REST HTTP verb (add user in
"pacsSerial":"87654321",
"active":true,
SCIM)
"otpSerial":"12345678",
"email":“tony.stark@pingidentity.com",
"userName":"lcarroll",
"givenName":“Tony",
"familyName":“Stark“
}
17. Modern Building Blocks
POST https://pingidentity.com:8443/Users
Authorization: Basic Y249RGlyZWN0b3J5IE1...
Content-Type: application/json
{
"userType":"spy",
"externalId":“tstark86753",
"pacsSerial":"87654321",
In REST, objects and
"active":true,
endpoints have
"otpSerial":"12345678",
"email":“tony.stark@pingidentity.com",
unique URLs
"userName":"lcarroll",
"givenName":“Tony",
"familyName":“Stark“
}
18. Modern Building Blocks
JSON data representation
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"
}
19. 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"
}
21. 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
22. Provisioning: Why Care?
• 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
User
breaches, unauthorized transactions
Provisioning
23. Anatomy of a Provisioning Service
• Protocols
– Examples include REST, SOAP, LDAP, applicationspecific 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
User
Provisioning
24. Provisioning Standards: Why Care?
• 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)
User
Provisioning
Standards-Based
Provisioning
25. The Case For SCIM
• 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
27. SCIM + Federated SSO
SS
SS
Ke
rb
er
os
Partner Two
O
Partner One
Authorization query
O
Federated SSO
SCIM
SCIM provider
Federation SP
s
ry
c
yn
Active
Directory
SCIM consumer
Federation IDP
o
ct
re
Di
y
tor
c
ire
D
c
yn
s
Active
Directory
29. 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
30. OAuth Components and Flow
OAuth
resource server
OAuth
authorization server
OAuth
client/relying party
A
Native application
R
A
refresh
token
access
token
ded
loa
ion
wn
icat
do
ent
ens + auth
ok
6. T e code
nc
fere
e
5. R
2.
Us
er
au
3.
the
To
ke
n/
nr
co
efe
ns
en
ren
t
ce
ret
urn
co
de
rce
ou
es n
n r atio
t
tio
ca sen
pli
e
ap
pr
n
to
ke
ss
to
ce
Ac
ss
8.
ce
Ac
7.
A
1. Browser instantiated
4. Code delivery
Web browser
31. OAuth
resource server
OpenID Connect Flow
authorization server
user information endpoint
n
s
en atio
k
To form
in
er
Us
A
AP
IA
cce
ss
A
OAuth
client/relying party
ID
R
A
ID
token
refresh
token
access
token
OpenID
Provider
32. OIDC Flow Redux
OAuth
resource server
OpenID
OpenID
Provider
Provider #1
authorization server
authorization server
user information endpoint
user information endpoint
s
oi n
nens atiatno
kek r
ToTo form m
fo
in in
es r
sUr e
U
AA
APAP
I AI Ac
ccece
ss ss
A
A
OAuth
OAuth
client/relying party
client/relying party
IDID
RR
IDID
AA
access
refresh access
ID refresh
token
token token
token token
RR
AA
OpenID
OpenID
Provider
Provider #2
35. 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)
37. 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)
38. FIDO UAF
(2) FIDO handshake
FIDO
Server
F
device attestation
(3) Asymmetrci key authn
web site/RP
Binding of user info and public key
ID Proofing
(1) user authentication
to FIDO client
FIDO Client
authenticator(s)
F
device key pair
site-specific key pairs
FIDO
Attestation
Service
F
39. UAF to OpenID Connect
Binding of user info and public key
OpenID Provider
(1) user authentication
to FIDO client
F A
(5
)A
PI
re
qu
es
t/
re
sp
on
se
(4) Token information
(2) FIDO handshake
FIDO client
(3) asymmetric key authn
F
FIDO authentication
module
A
mobile application
(relying party)
ID
A
tokens
R
40. User info, public key and
Key Handle
ord auth
ser passw
(1) u
site
authn
service
activation button
(activation required during
enrollment and optional at
runtime)
U2F
authn
service
device attestation
(2) Challenge
response,
with Key Han
dle
web site/RP
FIDO U2F
site-specific key pairs
(with Key Handles)
device key pair (per batch)
attestation
service
41. U2F to Federation
User info, public key and
Key Handle
Federation IDP
U2F
authn
service
Federation SP
(2) Challe
nge respo
nse,
with Key
Handle
(3)
SAM
L cr
ede
ntia
ls
(1) user password auth
primary
authn
service
(4)
L
AM
S
als
nti
de
cre