Highlights from the Next Generation Service Platform event on 17-18 June in Munich.

1. Next Generation Services Platforms
Munich 17/18th June 2015
The Telcos winning the migration to service
providers have understood and internalized API
Management operations, and are now focused on
mashing up local capabilities in an open
ecosystem as no problem is solved through just
one providers APIs. But remember APIs are just a
small piece of technology, the solution is much
broader then simply presenting APIs to internal
groups, partners, 3rd parties and customers.

2. Structure
• Dean Bubley WebRTC update
o 6B WebRTC- capable devices by 2019
• Dragana Linfield, Etisalat
o Etisalat Digital Case Study, Leveraging WebRTC to extend digital
communication services
• Francesco Vadalà & Vincenzo Amorino, Telecom Italia
o Future Strategies and the Impact APIs has on Telco Industry
• Sebastian Grabowski, Orange Poland
o BIHAPI Business Intelligence Hackathon API
• Michal Ajduk, Play Poland
o Play API, Enriching 3rd Party Services with Operator Capabilities
• Antonio Cruz, SAPO
o API Management Patters

3. WebRTC Market Status & Contextual Roadmap
Dean Bubley, Disruptive Analysis
NGSP, June 2015
dean.bubley@disruptive-analysis.com @disruptivedean

4. Any web-connected device will be WebRTC capable over time. Main limitation today is the
lack of IE and Safari WebRTC support, plus its not yet a ratified standard.
WebRTC on >6bn devices by 2019
Million WebRTC
devices worldwide,
year-end
Source: Disruptive Analysis 2014 Edition WebRTC Report
0
1000
2000
3000
4000
5000
6000
7000
2011 2012 2013 2014 2015 2016 2017 2018 2019
Other (TV+M2M/IoT)
Smartphones
Tablets
PCs
Copyright Disruptive Analysis Ltd 2015June 2015

5. Lead WebRTC use-cases, June 2015
Copyright Disruptive Analysis Ltd 2015Source: Disruptive Analysis WebRTC report update June 2015
Customer service & platforms
• Mayday, Amex etc.
• Contact centres
• Developer SDKs/platforms
• Mobile consumer VoIP & social chat
• Education/training/healthcare
• Free standalone video-calling
• Conferencing niches & web extensions
• Innovative UC & collaboration
Live &
commercial
• Full-scale corporate conferencing & UC
• Telco VoLTE/IMS extension
• CDNs, File/screen-sharing
Pilots /
pre-
commercial
Trials &
demos
• Entertainment & consumer electronics
• IPTV & personal broadcast
• M2M & IoT
• Public Safety
What is interesting in some ‘WebRTC’ implementations is they use the technology with
customizations in their own container rather than relying on the browser. This reflects the pre-
standards status and patchy browser coverage. Plus highlights the lack of importance
interoperability plays in most use-cases.

6. Telcos & WebRTC: growing fast
Copyright Disruptive Analysis Ltd 2015June 2015
Developer /
PaaS
Service
extension
Verticals / New
services
Not yet
commercial
European SP
videoconferencing
and many others
Asian MNO dev
pltfm
Integral to
some iOS
RCS apps
Asian MNO
chat app
Growing WebRTC adoption by Telcos, beyond simple experimentation.

7. | 1
Etisalat Digital Case Study
Leveraging WebRTC
to extend digital communication services
Dragana Linfield
dlinfield@etisalat.ae

8. | 4
Etisalat introduces HD voice and video calling with new C’Me app
http://7daysindubai.com/etisalat-introduces-voice-and-video-
calling-with-cme-app
http://ameinfo.com/technology/it/software/etisalat-introduces-hd-
voice-and-video-calling-with-new-cme-mobile-application/
C’Me is a proprietary IP Communications Client – we’re seeing more telcos follow this path
given RCS and VoLTE’s costs and delays.

9. Supports most of the common IP Communication features. Main challenge is
interoperability with other telcos if its to offer a traditional telco comms proposition, and if
it does not, then the value proposition will be limited by limited community.
|
• Existing Etisalat MSISDN works on any device
• Android/iOS (smart phone/tablets)
• App to non app calls
• Existing billing relationship for prepay/ post pay
• English/Arabic language
6
Etisalat C’Me: Communicate from any device with your mobile number
• Social Networks: Follow your social
media messages (e.g. Twitter) in one app
C’Me is a Single identity, multi device unified communication solution that allows user to access rich
portfolio of services using their smart phones, tablets and PC/MAC over any network.
‐HD Voice/Video Call
‐Rich Chat with live video window:
‐sharing (location/PTT etc.),
‐Group chat, Stickers
‐ Send SMS from C’Me

10. Etisalat are using WebRTC to extend traditional comms services as well as offer them
through APIs to be used within apps, services and business processes.
| 9
Etisalat WebRTC Platform – Telephony made simple
A cloud‐based platform enabling Etisalat to deploy new
services based on Comms APIs and accelerate innovation.
This will allow voice, messaging and real time presence to
be consumed in a new and more exciting way.
Simplifies complexity and technology barrier involved in
providing a communication services for the application
developers
Objectives:
1. Develop and rollout new communications‐enabled services.
2. Bridge between Web and Telco services
3. Address Enterprise and SME market
4. Expose APIs (Voice, Messaging) and start engaging regional
developers to develop apps

11. Similarly extending C’Me and exposing capabilities through an API
|
WebRTC can help C’Me to extend reach to anywhere, any device, any network and any time
Extend Network Capabilities to reach SIM‐less device (browser , PC, social networks)
Opening to Innovation‐ expose C’Me API through WebRTC to regional developers to develop
innovative services
11
C’Me – browser integrated
communication experience
WebRTC
Platform
WebRTC opportunity: Extend the reach of C’Me

12. The challenge with this use case remains channel to market, other people than telcos appear
able to sell it. While Telcos struggle.
|
PLATFORM FOR FUTURE INNOVATION AT WEB SPEED
• A seller doesn't want to reveal his number.
• Subscribe to a privacy service ‘Call Me’ button.
• Control when to receive calls. Notification by voice message/ email/ SMS.
• Buyer simply ‘Clicks to Call’
• When the car is sold, ‘Call Me ‘ button is deactivated.
13
Seller set-up Page
Call me
Buyer Page
Call Me from Web Browser – Give customers privacy and control

13. Future Strategies and the Impact APIs has
on Telco Industry
TELECOM ITALIA GROUP
Next Generation Service Platform – Telecom API - 2015
Munich, 17-18 June 2015
Vincenzo Amorino
Francesco Vadalà
The Telecom Italia Experience
SmartPipe & NetAPI dept.

14. 5
Telecom Italia API project is one of the longest continuously operating programs of any
Telco. Recent focus has been on processes, and has seen significant internal uptake in APIs.
While the focus in 2016 will be on making money through the services made possible.

15. 6
Significant rise in API use – mainly internal consumption to 2B per month

16. 11
Conclusions
• Telecom Italia Network API Platform is not a "black box", rather it is an
approach to platform design and service integration built and evolved
over the years.
• The Network API Platform plays a key role inside the Telecom Italia, by
increasing abstraction through functional decomposition while ensuring
security, performances and differentiated SLA to fulfill heterogeneous
(internal and external) third party needs and business models
• The API approach is somehow stabilized and the Network API Platform
has allowed to explore new business relationships and promise to
enable more and more smart usage of the network resources.
• It is time to consolidate our experience, and make it more fruitful
Keep it easy
Telecom Italia’s update on Network API Platform
Francesco Vadalà, Vincenzo Amorino, Smart Pipe and NetAPI
Telecom Italia has been on a long journey with APIs, but they now feel confident to use APIs
across all aspects of their business to drive new revenues. Not API platform is am approach
to design and service integration – significant organization learning.

17. BIHAPI
Business Intelligence
Hackathon API
II edytion (2014-215)

18. BIHAPI shows the importance of taking a local focus and mashing-up APIs
BIHAP
I
Business Intelligence
Hackathon API
Open Data,
Telco&Web APIs,
WebRTC
OpenMiddleware Community
For whom: Developers, SME, SOHO, Startups, Geeks, Students…..

19. 3 cities
Warszawa
Poznań,
Gdańsk
3
finalistów
wizyta.pl
PublishSoSimply
Sesame+
20
partners
16
members of
jury
22+
warsztaty
konsultacje
dostęp do
infrastruktury Ministerstw
o
Administra
cji i
Cyfryzacji
patronage
33,5k
PLN
awards
3
finalistów
wizyta.pl
PublishSoSimply
Sesame+
81 APIs
36: Orange PL
30: Warszawa
11: Poznań
4: Gdańsk
101 ideas
28 PoC
BIHAP
I
Business Intelligence
Hackathon API
Ecosystem based approach

20. Multi-technology – real world is not just one vendor’s APIs
BIHAP
I
Business Intelligence
Hackathon API
OCSG
api.orange.pl
SMS
ZTE SDP
USSD
Payment AccMgmt
IKEA
Call Services
OpenCloud JSLEE
Terminal Status
Warsaw WMS
Historical Maps
MySQL Database
Public Transport
Location MMS Adaptation
Telco
Domain
City Data
Domain
Main
Platform
Security SLA
Warsaw WFS
Veturilo P&R
Gdańsk WMS
Hypsometric Maps
Poznań Web
Services
Busstops Events
Warsaw Web
Services
Queue
NGW Mobicents
Cell ID Status HLR
Open Data GW
WFS WMS

21. Michał Ajduk
michal.ajduk@play.pl

22. Play showed a solid grasp of how APIs apply across their business
11Play API
Proof of
concept
Internal
Service
Partner
service
70% API use is internal and 30% is with
partners, with no long tail use - nothing
new!
PoC
3rd party
Internal & MVNO
Net API –
100mln requests / month

23. They are also taking an open approach – Poland is going to be a hot-bed of innovation.
16Play API
Service Delivery… Framework
Trusted 3rd parties with ready services,
not mythical long tail developers
Trusted, FLEXIBLE, technology partner
Enriching working services
70% API use is internal and 30% is with
partners
Billing, Auth & User Profile API is a Key!
Messaging and Voice services are nice to
have’s
APIs between departaments (eg. IT <->
Billing <-> Core Network) – Amazon
approach

24. API Management
Pa,erns
with
Service
Delivery
Broker
antonio.j.cruz@telecom.pt
António
Cruz
Next
Genera1on
Service
Pla7orms
2015
This
is
an
important
presenta<on
as
it
consolidated
much
learning
from
SAPO
on
API
Management.
They’ve
built
up
a
plaGorm
using
open
source,
its
an
important
model
for
other
telcos
that
wish
to
take
control
of
their
future.

25. The API Management Momentum

26. API Management Solu6ons Today
• The
capabili<es
found
in
many
of
API
Management
solu<ons
today
go
way
beyond
the
Web
services
Catalog
commonly
found
in
classic
corporate
SOA
solu<ons,
aka
“ESBs”:
• Not
only
XML,
SOAP
and
WS-­‐*,
but
especially
REST
and
JSON,
and
performs
transforma<ons
between
any
of
those.
• Authen<ca<on
and
authoriza<on,
using
OAuth
and
OpenID
Connect
Web
standards.
• Support
to
most
of
IT
management
processes
that
are
relevant
to
the
API
lifecycle.
• Portals
for
community/product
ini<a<ve/program.
• Real-­‐<me
sta<s<cs/no<fica<ons
on
APIs
usage,
health,
performance
and
SLAs.
• APIs
mone<za<on,
stores
and
open
business
models.
• Scale
efficiently
as
a
mul<tenant
cloud
service.
• Perform
a
strategic
role
in
Enterprise
Business
Architecture.

27. API Management Context
• Agile
reu<liza<on
and
integra<on
of
business
capabili<es
in
both
internal
and
external
par<es
projects.
• Processes
and
culture
change,
resources
standardiza<on,
infrastructure
consolida<on,
costs
reduc<on.
• Strategic
posi<oning,
innova<ve
P&S,
new
business
models,
data
assets,
improved
customer
experience.
TM
Forum
Digital
Services
Reference
Architecture
IoT
Reference
Architecture
(example)
Analysis
Mason
SDN/NFV
Reference
Architecture

28. Portugal Telecom Service Delivery
Broker

29. SDB Ecosystem Today
SDB delivers APIs to a broad
portfolio of apps developed by
PT and its partners.
23
%
GRO
WTH
YoY
40
M
API
CALLS
DAILY
75
0
APIs
1.2B
API
calls
per
month
(mostly
web-­‐based
not
network
based),
on
a
per
subscriber
basis
is
twice
that
of
Telecom
Italia.
With
strong
growth
of
23%

30. About API Management Pa,erns
• Design
paderns
are
(only)
“proven
solu+ons
to
commonly
occurring
problems”.
• They
are
not
“silver
bullets”
nor
“magical
recipes”.
• Generally,
paderns
are
discovered/recognized
by
real-­‐world
experience
of
solving
the
problems,
not
“invented”
or
“created”.
• Paderns
are
valuable
essen<ally
because
they
enable
a
common
language
to
debate,
approach
and
eventually
solve
problems.
• API
Management
paderns
help
to
understand
the
current
Enterprise
Architecture
state
in
an
organiza<on,
and
what
can
be
done
about
it.

31. Service Design

32. Con6nuous Delivery
• PROBLEM:
The
end-­‐to-­‐end
process
of
developing
and
releasing
soeware
is
oeen
long
and
cumbersome,
it
involves
many
people,
departments
and
obstacles
which
can
make
the
effort
needed
to
implement
Con<nuous
Delivery
to
seem
overwhelming.
• SOLUTION:
Iden<fy
the
goals,
establish
the
processes
and
a
plaGorm
that
will
enable
evolving
in
the
right
direc<on.
This
plaGorm
includes
adop<ng
specific
principles,
tools,
methods
and
prac<ces.
A
maturity
model
helps
to
understand
the
actual
state
and
iden<fy
paths
to
progress.
BUI
LD
DEPL
OY
TE
ST
REPO
RT

33. External by Design
• PROBLEM:
Any
business
capability
only
used
internally
in
the
organiza<on
today
may
be
required
to
be
externally
exposed
in
the
future,
e.g.
in
order
to
enable
new
business
models.
However,
tradi<onally
in
the
organiza<on,
architectures,
standards
and
tools
used
to
implement
solu<ons
for
internal
consump<on,
are
different
from
the
ones
applied
when
the
solu<on
is
targeted
to
external
par<es
or
customers,
e.g.
outside
the
corpora<on
firewall.
This
differen<a<on
creates
a
burden
in
maintenance,
makes
more
complex
to
access
internal
resources
from
external
applica<ons,
and
difficults
the
reposi<oning
of
internal
solu<ons
in
an
external
context.
• SOLUTION:
All
services
and
applica<ons
must
be
designed
with
built-­‐in
ability
to
be
externalized
at
any
moment.
Using
the
same
architecture
and
technologies
for
developing
both
internal
and
external
APIs
and
applica<ons,
the
reu<liza<on
poten<al
of
internal
assets
is
greatly
simplified,
e.g.
only
requiring
to
provision
a
new
configura<on.
Enterprise
API
Catalog
Service
Delivery
Broker
IT
Resource
s
DataPhysical
Resource
s
Domain
APIs
Custo
mer
Emplo
yee
Partne
r

34. Real-­‐Time
• PROBLEM:
Users
will
not
wait
long
for
anything,
par<cularly
mobile
users
expecta<on
is
to
have
what
they
want
immediately,
or
in
a
few
seconds.
• SOLUTION:
Every
service
must
be
designed
with
user
experience
in
mind,
and
that
means
designing
and
developing
service
APIs
able
to
fulfill
the
real-­‐<me
expecta<ons
of
users.
Real-­‐<me
is
a
transversal
quality
required
in
Enterprise
Architecture,
and
is
not
restricted
to
a
specific
type
of
services
or
data.
When
interac<ng
with
a
Real-­‐Time
Enterprise,
the
user
will
get
any
of
his
Products
and
Services
immediately
provisioned
and
configured
aeer
subscribing,
immediate
understanding
and
feedback
upon
his
problems,
and
proac<ve
offerings
that
make
sense
to
his
lifestyle
and
needs.

35. Mul6tenancy
• PROBLEM:
Both
for
business
and
opera<onal
reasons,
it
is
desired
to
enable
resources
sharing,
such
as
an
applica<on
and
its
database,
and
being
able
to
deliver
both
to
a
group
of
tenants
(customers)
in
a
way
that
each
tenant’s
data
is
isolated
and
remains
invisible
to
other
tenants.
• SOLUTION:
The
applica<on
logic
must
decide
how
to
iden<fy
and
flow
tenant
iden<fica<on
on
every
request,
and
most
database
tables
must
include
a
tenant
ID
column.

36. Standard Management API
• PROBLEM:
APIs
and
applica<ons
usually
do
not
explicitly
expose
management
capabili<es
such
as
their
own
health
status,
neither
no<fy
their
dependencies
failures,
nor
follow
a
standardized
approach
when
implemen<ng
those
capabili<es.
Monitoring
systems
are
thus
generally
coupled
with
APIs
func<onal
interfaces,
use
them
to
assert
health
of
both
APIs
and
applica<ons,
and
generally
only
respond
reac<vely
to
incidents.
• SOLUTION:
Beyond
their
func<onal
interfaces,
APIs
and
applica<ons
may
offer
a
standardized
management
API
interface
that
will
enable
monitoring
systems
to
act
proac<vely
upon
problem
no<fica<ons
and
predict
poten<al
incidents.
User
Applica1ons
Monitoring
Systems
APIs
(e.g.
News)
Networ
k
&
Devices
(e.g.
SMS
Gateway)
Physical
Resourc
es
(e.g.
Database)
API
Manage
ment
Interface
Func<on
al
Interface
(e.g.
GetManagementReport)
(e.g.
GetNews
or
SendSMS)

37. PlaEorm & Infrastructure

38. Collabora6on Lifecycle
• PROBLEM:
Service
lifecycle
management
is
a
complex
process
that
impacts
provisioning,
assurance
and
opera<onal
readiness.
When
not
done
efficiently,
nega<vely
impacts
the
customer
experience
and
the
<me-­‐to-­‐market
of
new
products
and
services.
• SOLUTION:
Successfully
managing
the
lifecycle
of
every
service
API
requires
that
several
persons/teams
collaborate
efficiently.
Segment
user
experiences
based
on
simple
and
well-­‐
defined
tasks,
according
to
their
responsible
roles,
and
whenever
needed
to
advance
the
process
flow,
inform
ac<ons
and
decision
required
through
event-­‐driven
no<fica<ons
and
status
reports.

39. Process Automa6on
• PROBLEM:
When
performed
manually,
tasks
tend
to
be
repe<<ve
and
tedious,
introducing
undesired
latency
into
processes,
drama<cally
raising
the
risk
of
errors,
unsa<sfac<on,
and
cost.
• SOLUTION:
By
exposing
APIs,
automate
as
much
as
possible
all
the
manual
ac<vi<es
that
are
cri<cal
to
the
business.
Automa<on
is
a
game
changing
road,
leading
to
many
organiza<onal,
process
and
cultural
challenges.
Poten<al
candidates
for
process
automa<on
generally
include,
but
are
not
restricted
to:
1)
IT
development
ac<vi<es;
2)
BSS/OSS
provisioning
and
configura<on
of
all
physical
and
logical
resources;
3)
Enablement
of
self-­‐service
experiences
to
customers,
internal
IT
requests,
and
partners
on-­‐boarding.

40. Mul6channel
• PROBLEM:
Users
aden<on
is
disperse
over
different
channels
and
they
prefer
experiences
that
are
cross-­‐channel,
e.g.
mobile,
Web,
TV,
etc.
• SOLUTION:
Products
and
services
should
be
designed
to
support
mul<channel
experiences
from
the
start,
so
that
instead
of
compe<ng,
channels
can
become
complementary,
e.g.
using
a
tablet
to
control
a
Video-­‐On-­‐
Demand
service,
or
the
Web
to
create
TV
playlists.
This
can
be
done
semng
up
small
mul<disciplinary
teams
that
are
specially
assembled/consulted
for
the
dura<on
of
each
specific
project.

41. Cloud Service
• PROBLEM:
Adding
more
resources
(e.g.
CPU
and/or
memory)
to
a
physical
server
in
order
to
increase
a
service
performance
(ver<cal
scalability,
or
scale-­‐up)
is
limited
by
the
capacity
of
that
server,
and
in
many
cases
this
will
not
be
cheap
and/or
possible.
• SOLUTION:
Services
must
be
designed
to
allow
the
addi<on
of
redundant
servers
in
a
Virtualized
environment,
with
the
same
func<on,
so
that
they
can
scale
work
without
exponen<ally
increasing
costs,
as
a
single
logic
en<ty,
thus
enabling
to
increase
service
performance
whenever
needed
(horizontal
scalability,
or
scale-­‐out).
Adding
on
that,
elas<city
is
also
an
important
capability,
so
that
only
the
resources
effec<vely
needed
are
allocated
and
will
be
charged.

42. Mul6tenant Load Balancing
• PROBLEM:
A
service
implementa<on
on
a
single
server
has
a
finite
capacity.
To
address
this
problem,
redundant
deployments
of
the
service
are
created
and
a
load
balancing
system
over
a
servers
farm
is
added
to
dynamically
distribute
workloads
across
service
implementa<ons.
However,
the
customers
of
a
mul<tenant
service
will
have
different
performance
requirements,
but
there
is
no
way
to
dynamically
configure
and
balance
their
requests
accordingly.
• SOLUTION:
The
load
balancing
system
must
be
able
to
iden<fy
which
servers
must
answer
to
each
of
the
tenants
requests,
so
that
it
can
efficiently
distribute
the
requests
load
through
the
servers
farm.
To
enable
that,
we
can
dynamically
configure
on
each
server
a
set
of
load
balancer
probe
endpoints
per
tenant,
so
that
only
the
configured
servers
for
each
tenant
will
be
visible
to
the
load
balancer.
S1
S2
S3
S4
S5
Tenant
A
Tenant
B
Tenant
C
Shared
Databa
ses

43. End-­‐To-­‐End Tracing
Applica
<ons
APIs
Resourc
es
Users
“john@gmail.com”
“VOD
App
on
iOS”
“SubscriberManagement
API”
“Server
A
on
Farm
X”
IDENTITY
PROVIDER
AUTHORIZATION
SERVER
API
CATALOG
CMDB/INVENTORY
UNIFIED
TRACE
COMPONENTS
ACTORS
• PROBLEM:
Several
layers
of
Products,
Services
and
Resources
make
understanding
of
problem
root
causes
difficult,
and
significantly
increases
the
<me
and
effort
required
for
incidents
detec<on
and
resolu<on.
• SOLUTION:
When
using
APIs
in
the
integra<ons
between
layers,
it
is
possible
to
consolidate
all
segments
of
each
message
flow
in
an
unified
trace
view,
that
iden<fies
the
user,
applica<on,
service
APIs
and
physical
resources
involved
on
every
message
flow,
which
will
increase
support
teams
efficiency,
avoid
undue
incident
escalona<ons
and
reduce
cost.

44. Security

45. Iden6ty Gateway
• PROBLEM:
Applica<ons
need
to
authen<cate
users
using
different
providers,
such
as
social,
corporate
and
applica<onal
iden<ty
providers.
Integra<ng
applica<ons
with
different
protocols
requires
significant
effort
and
couples
them
to
the
providers
specific
protocols,
thus
lowering
applica<ons
portability,
maintainability
and
extensibility.
• SOLUTION:
An
Iden<ty
Gateway
abstracts
the
specific
details
of
any
iden<ty
provider,
thus
allowing
applica<ons
to
integrate
with
them
using
a
single
protocol,
enabled
by
the
Iden<ty
Gateway
service
component.
Use
r
Facebook,
Google,
Twi^er,
LinkedIn,
etc.
Service Delivery
Broker
Corporate
Iden1ty
WS-­‐Federa<on
Adapter
Social
Iden<ty
Adapters
SDB
Connect
Iden<
ty
Gate
way
Applica<on
OpenID
Connect
Frontend

46. Integrated Authen6ca6on &
Authoriza6on
• PROBLEM:
Applica<ons
requiring
users
iden<ty
generally
also
need
to
access
(through
APIs)
protected
resources
on
behalf
of
those
users.
Instead
of
implemen<ng
two
disconnected
flows,
store
and
use
separate
creden<als
on
each
flow
(users
authen<ca<on
and
resources
access
authoriza<on),
applica<ons
should
be
able
to
authen<cate
and
authorize
their
users
relying
on
an
integrated
protocol.
• SOLUTION:
When
used
together,
OpenID
Connect
and
OAuth
2.0
specifica<ons
enable
support
to
users
federated
authen<ca<on
and
delega<on
of
access
authoriza<on
to
APIs.
An
applica<on
can
use
OpenID
Connect
to
sign-­‐in
a
user
and
then
request
an
OAuth
2.0
access
token
to
invoke
APIs
on
behalf
of
that
user.
APIs
SDB
Run1me
Use
r
Facebook,
Google,
Twi^er,
LinkedIn,
etc.
Service Delivery
Broker
Corporate
Iden1ty
Toke
n
Man
ager
WS-­‐Federa<on
Adapter
Social
Iden<ty
Adapters
SDB
Connect
Iden<
ty
Gate
way
Applica<on
OAuth
2.0
Frontend Backend
OpenID
Connect