Identity Management and WebRTC

Transcription

1 Identity Management and WebRTC 10/30/2014 Title Version No: 0.1/ Status: DRAFT 1

2 Acision at-a-glance Heritage & history 20 year history 270 customers globally 2 trillion messages/ year Global presence & reach 35+ offices across 6 continents 850+ employees 100+ support team Innovation 1 st to launch commercial SMSC Cloud & virtualized services Multi-Channel messaging + WebRTC Acision 2014 Operational Excellence Data and insights Carrier grade security 24/7 Support

3 Evolution on the Web Sir Tim Berners-Lee creates HTML. Web -pages are static WebSocket and WebRTC implementations become available W3C produces the DOM1 specification Microsoft and Netscape introduce different mechanisms for DHTML Google uses Ajax in Gmail (W3C releases 1st draft in 2006) the dawn of web-apps 10/30/2014 Title Version No: 0.1/ Status: DRAFT 3

4 Claude Chappe invented the optical telegraph Alexander Graham Bell patents the telephone From the 1960s onwards digital exchanges start to appear Revolution in Telecoms The revolution Before today the operators (big and small) had full control over real-time communications because it was hard to do and substantial infrastructure investment was required. From the 1990s onwards voice started to be carried on technologies developed for data networks such as ATM and IP s > 1990s > 2011 WebSocket and First commercial electrical telegraph created by Cooke and Wheatstone Rotary dial enters service 1963: DTMF enters service WebRTC implementations become available 10/30/2014 Title Version No: 0.1/ Status: DRAFT 4

5 The identity problem Identity security on telephone networks relies on the fact that it is a closed system Telephone identities belong to devices not people Even on mobile networks it s the device just a personal device The Internet is an open platform Identities are tied to people not devices Existing web-sites already have identities (usernames, passwords, etc) but usually not in a form that works for real-time communications 10/30/2014 Title Version No: 0.1/ Status: DRAFT 5

6 RTCWeb There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' webbrowsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. Real-Time Communication in WEB- Browsers (rtcweb) charter 10/30/2014 Title Version No: 0.1/ Status: DRAFT 6

7 WebRTC The mission of the Web Real-Time Communications Working Group, part of the Ubiquitous Web Applications Activity, is to define client-side APIs to enable Real-Time Communications in Web browsers. These APIs should enable building applications that can be run inside a browser, requiring no extra downloads or plugins, that allow communication between parties using audio, video and supplementary real-time communication, without having to use intervening servers (unless needed for firewall traversal, or for providing intermediary services). Web Real-Time Communications Working Group Charter 10/30/2014 Title Version No: 0.1/ Status: DRAFT 7

8 RTCWeb and WebRTC: not the same thing RTCWeb is the on-the-wire protocol as defined by the IETF and may be used in many applications and systems Within VoIP phones On network servers Includes MTI codecs for audio and video WebRTC is the browser API as defined by the IETF 10/30/2014 Acision

9 Signalling not included The IETF made a controversial (but very wise) decision not to specify how the signalling should work Signalling is required To discover who to communicate with To exchange information on what the communication should be (audio, data, video, and codecs) Even the simplest, proprietary, RESTful exchange is signalling Identity management relates to signalling 10/30/2014 Acision

10 The signalling trapezoid Server Signalling Server UA Media UA 10/30/2014 Title Version No: 0.1/ Status: DRAFT 10

11 What do we need? A way to use credentials held outside of the signalling servers to authenticate, authorise, and identify signalling traffic 10/30/2014 Title Version No: 0.1/ Status: DRAFT 11

12 Authentication Code Access Token Request Identity Identity Authentication with OAuth2 1 OAuth2 Provider Authentication Code 8 3 Identity Web Service 10/30/2014 Title Version No: 0.1/ Status: DRAFT 12

13 Authenticating signalling using a web-service No communication required between the authentication server and the signalling server No accounts required on the signalling server Credentials expire (the expiry time is chosen by the authentication server) Place credentials in the GET used for signalling WebSocket handshake Use ephemeral authentication based on: draft-uberti-rtcweb-turn-rest, or draft-ietf-oauth-json-web-token 10/30/2014 Acision

14 Ephemeral Authentication with OAuth2 Web Service 5: Shared secret UA Communication link not required You don t have to create or manage accounts on the Signalling Server Signalling Server 10/30/2014 Acision

15 This is supported in Kamailio 10/30/2014 Title Version No: 0.1/ Status: DRAFT 15

16 Acision SDK Contact Centre Demo 10/30/2014 Title Version No: 0.1/ Status: DRAFT 16

17 Thank you 10/30/2014 Title Version No: 0.1/ Status: DRAFT 17