LIVRE BLANC

L’architecture mobile moderne

de Paul Madsen
Nombreuses sont les entreprises qui mettent actuellement en place des projets liés à la mobilité.
Ceux-ci sont largement encouragés par le BYOD, dont le potentiel, en termes de productivité et de
satisfaction des utilisateurs, est considérable.

Pour les équipes informatiques, la mise en place du BYOD représente beaucoup de travail : il leur
faut sécuriser les accès aux données sensibles de l’entreprise stockées sur les périphériques, tout en
permettant aux utilisateurs de faire leur travail le plus efficacement possible. Parallèlement, ces services
informatiques doivent également préserver la confidentialité des employés. Dans certains pays, le
respect de la vie privée est une obligation légale. Une architecture mobile moderne compatible avec le
BYOD doit donc trouver le juste équilibre entre :

■■ La sécurité des données et des applications — protéger les accès aux informations
sensibles de l’entreprise stockées sur des appareils mobiles.
■■ L’indépendance des utilisateurs — permettre aux employés de faire leur travail quand
ils le souhaitent et à partir de n’importe quel endroit, les aidant ainsi à mener à bien leurs
missions.
■■ La confidentialité des utilisateurs — donner le droit aux utilisateurs à la « tranquillité »,
afin que l’entreprise ne puisse pas avoir une visibilité totale sur leurs applications personnelles
et sur les données présentes sur le périphérique, en particulier dans un contexte BYOD.

La sécurité a toujours été synonyme de ralentissement de la productivité des utilisateurs. Cependant,

il a également toujours été admis que c’était le prix à payer pour protéger les données. Malgré tout,
les employés aujourd’hui, habitués à la facilité d’utilisation et à l’aspect très pratique des applications
grand public, sont désormais moins susceptibles de tolérer ces contraintes. S’ils constatent que
le département informatique les empêche de faire leur travail, ils ont plusieurs choix. Pour chaque
système verrouillé, il existe probablement une application tierce de contournement à laquelle
l’employé pourra souscrire via une carte de crédit (ce qui occasionnera des frais). De la même façon,
les premières solutions de protection des mobiles ne prenaient pas suffisamment en compte le droit
(ou du moins les attentes) des employés en termes de confidentialité quant à l’usage personnel du
périphérique.

Trouver un équilibre entre la sécurité des données et des applications, l’indépendance et la

confidentialité des utilisateurs n’est pas une chose facile. Cela reste malgré tout possible, en
s’appuyant notamment sur les quatre technologies suivantes.

■■ L’authentification mobile — exploiter les fonctionnalités des smartphones pour apporter

une authentification simple et sécurisée

■■ Le SSO sur le web et les applications natives — proposer aux utilisateurs une expérience
fluide, à la fois sur les applications mobiles web et natives

■■ Les API — permettre les accès aux données professionnelles uniquement aux applications et
utilisateurs autorisés.
1
 LIVRE BLANC

■■ Segmentation du profil professionnel/personnel — séparer les applications et

les données professionnelles des applications que les employés installent à des fins
personnelles

Ces quatre éléments permettront à une entreprise de trouver le bon équilibre entre la sécurité,
l’indépendance des utilisateurs et la confidentialité.

1.1 L’authentification mobile

CE QUE JE SUIS
CE QUE JE SUIS
CE QUE J’AI

CE QUE J’AI

CE QUE JE SAIS

CE QUE JE SAIS

AVANT ACTUELLEMENT

Le vieux principe du « quelque chose que l’on sait, quelque chose que l’on possède et quelque
chose que l’on est » a été très utile pour différencier les mécanismes d’authentification. De plus
en plus, la tendance s’éloigne de «ce que l’on sait » (mots de passe) pour s’intéresser à « ce
que l’on a », les téléphones portables. Cette tendance est non seulement encouragée par les
problèmes et les limites apparentes des mots de passe, mais également par les possibilités que
représente l’authentification mobile. Celle-ci permet notamment d’améliorer la sécurité et le
confort d’utilisation (on a toujours pensé que l’un empêchait l’autre).

Les téléphones mobiles actuels intègrent le facteur d’authentification « ce que je possède », qui
est très utile. Soit celui-ci joue le rôle de deuxième facteur, intervenant ainsi en complément du
modèle classique basé sur des mots de passe, soit il remplace totalement les mots de passe.

Dans les faits, un smartphone n’est rien d’autre qu’un ordinateur portable extrêmement puissant,
équipé des fonctionnalités suivantes, utiles à l’authentification :

■■ La connectivité. Par définition, les équipements mobiles sont connectés, et capables

de gérer les mécanismes d’authentification dans lesquels un « challenge » est envoyé au
périphérique via le réseau, par sms par exemple, ou via les infrastructures de notification
du système d’exploitation (OS) de l’appareil.

■■ La puissance de traitement. Celle-ci permet les calculs embarqués afin de supporter le

chiffrement etc.

■■ L’interface utilisateur. Cette interface apparait lorsque l’utilisateur est invité à entrer
ses identifiants, ou pour les identifiants à usage unique.

■■ Le stockage sécurisé. Il permet de stocker les identificateurs, les questions secrètes et

les identifiants utilisés pour l’authentification.

2
 LIVRE BLANC

■■ La biométrie. De plus en plus, les équipements mobiles sont équipés de matériel qui
permet la validation de certains éléments biométriques de l’utilisateur, comme une
empreinte ou une capture de la rétine.

■■ L’utilisateur unique. Un équipement est habituellement associé à un seul utilisateur. Ainsi,

l’authentification de l’équipement joue le rôle de proxy pour l’utilisateur dudit équipement.

Les différents types d’authentification mobile s’appuient sur les fonctionnalités de plusieurs
combinaisons. PingID™ repose, par exemple, sur un modèle d’authentification mobile qui
autorise l’utilisateur en envoyant un « challenge » à une application installée sur son équipement,
préalablement enregistré, via Google Cloud Messaging pour Android ou les services de
notification Apple Push. A la réception, l’utilisateur n’a qu’à déverrouiller son écran pour répondre
au challenge.

La FIDO™ Alliance (Fast Identity Online) est en phase de définition d’une méthode d’authentification
mobile alternative, exploitant les nouvelles fonctionnalités biométriques des appareils. Dans le modèle
de FIDO, l’utilisateur s’authentifie à l’appareil via une validation biométrique. Celle-ci permet de
déverrouiller une clé cryptographique, utilisée pour l’authentification au serveur.

Les mécanismes d’authentification mobile actuels sont périodiques (l’authentification de

l’utilisateur a lieu de manière peu fréquente et peu explicite [dans le sens où l’utilisateur doit
réaliser une action]).

Cependant, le téléphone (et d’autres capteurs locaux) peut ouvrir la voie à un type
d’authentification plus passif et plus continu, dans lequel les actions des utilisateurs et le

FACTEURS
IMPLICITES

FACTEURS
IMPLICITES

FACTEURS
EXPLICITES

FACTEURS
EXPLICITES

AVANT ACTUELLEMENT

3
 LIVRE BLANC

contexte sont sous surveillance permanente, puis comparés aux habitudes passées et connues.
Les chercheurs explorent, par exemple, la thématique de la biométrie passive, comme
l’écartement des mains sur le clavier ou l’amplitude des pas, pour améliorer la fiabilité globale
de l’authentification utilisateur. L’authentification en continu promet de rendre l’authentification
utilisateur plus passive, réservant ainsi les authentifications actives ou explicites à des
circonstances spécifiques (acheter une action par rapport à simplement visualiser son cours).

1.2 Le Single Sign-On

Le Single Sign-On (SSO, authentification unique) est un mécanisme qui permet aux utilisateurs
d’accéder aux applications de façon fluide et transparente. L’authentification de l’utilisateur
aux applications doit être aussi invisible que possible (« aussi invisible que possible » dépend
de la nature et de la sensibilité des différentes applications, ainsi que de leurs données.)
Réduire le nombre d’authentifications ouvertes et explicites permet aux utilisateurs de gagner
considérablement en autonomie. Rien n’empêche jamais plus un employé de faire son travail que
l’impossibilité de se connecter à des applications nécessaires à ses missions.

Alors que les méthodes d’authentification mobiles mentionnées ci-dessus permettent d’améliorer
de façon considérable le confort des utilisateurs, conserver des méthodes si explicites pour
chaque application est loin d’être une solution idéale. Il est donc intéressant de combiner
l’authentification mobile à des mécanismes de SSO. En effet, une seule authentification mobile
utilisateur peut couvrir plusieurs applications.

Les mécanismes standards qui permettent le SSO aux applications des navigateurs mobiles
sont bien établis. Grâce au protocole SAML, (security assertions markup language) le SSO au
navigateur mobile est possible, de la même façon qu’au navigateur d’un poste de travail. D’autres
protocoles de SSO aux navigateurs web existent comme OpenID® et WS-Federation. Plus
récemment OpenID Connect (Connect) s’est imposé comme un protocole qui, comme il repose
sur OAuth, couvre à la fois les navigateurs web et les applications natives.

OAuth et Connect peuvent être tous deux utilisés pour sécuriser les applications mobiles natives
(à l’inverse de SAML et d’autres protocoles SSO Web). Cependant, ni OAuth, ni Connect ne
peuvent, en l’état, permettre le SSO à travers les applications natives, les deux partant du principe
que l’utilisateur doit d’abord s’authentifier puis autoriser chaque application native, une à une.

SSO SAML
NAPPS

ACCES AUX
APPLICATIONS OPENID
CONNECT

Individuel OAUTH

Web TYPE D’APPLICATION Native

4
 LIVRE BLANC

Le groupe de travail (WG, Working Group) de Native Applications (NAPPS) à la fondation OpenID
est en cours de définition d’un profil d’OpenID Connect qui permettrait le SSO entre et à travers
les applications mobiles web et natives, via la méthode suivante :

■■ SAML permet le SSO aux applications mobiles web.

■■ OAuth active individuellement les applications mobiles natives.

■■ OpenID Connect active les applications mobiles natives individuelles ainsi que le SSO
pour les applications mobiles web.

■■ NAPPS permet le SSO sur les applications mobiles web et natives.

1.3 Les API (interfaces de programmation)

Les API sont essentielles dans les architectures mobiles modernes. Celles-ci permettent de séparer
les données applicatives des applications de l’interface utilisateur, ou canal de disponibilité.
Elles apportent ainsi une importante couche d’abstraction matérielle. De plus en plus, les API
sont intégrées à un modèle appelé « RESTful », un rejet des architectures SOAP, qui pèsent
relativement lourd.

Application Serveur
mobile Navigateur d’authentification API
L’application appelle les objets
du navigateur

Page d’autorisation de passage du serveur d’authentification

Page d’autorisation de chargement
du serveur d’authentification

Envoi des identifiants d’authentification

Redirection 302 avec codes d’autorisation

vers mobileapp://code=7456794

Appel à MobileApp et envoi de l’URL (avec code d’autorisation)

Echange du code d’autorisation pour le jeton d’accès

Jeton d’accès
Intégration du jeton d’accès à l’appel API

Validation du jeton

Retour des données applicatives

Application Serveur
mobile Navigateur d’authentification API

Un grand nombre d’API REST sont des applications mobiles natives. La meilleure méthode pour
authentifier des applications natives à leur endpoint REST correspondant est d’attacher un jeton
d’accès OAuth aux appels API.

Ci-dessous un schéma montrant le flux OAuth standardisé, par lequel une application native
obtient un jeton d’un serveur d’autorisation (AS), puis qui utilise ce jeton pour appeler l’API. C’est
grâce à la validation de ce jeton que l’API peut déterminer au nom de quel utilisateur l’application
native est en train de fonctionner, pour ainsi prendre la décision d’autorisation adaptée.

L’utilisateur étant directement impliqué dans l’émission du jeton (via le navigateur mobile)
vers l’application native, le flux ci-dessus permet (mais ne rend pas obligatoire) une étape
d’autorisation, qui est une fonctionnalité importante aidant à la préservation de la confidentialité.
De plus, l’utilisateur étant authentifié dans le navigateur, il est alors possible de le diriger vers
5
 LIVRE BLANC

un autre endroit pour l’étape d’authentification,

puis de le rediriger à nouveau vers le serveur
d’autorisation, via un flux SSO fédéré.

La difficulté que représente la validation du

jeton d’accès OAuth intégré à l’appel REST est
supprimée de l’API elle-même, puis reportée vers
une passerelle d’API située au-devant les API.
La passerelle cartographie alors le jeton OAuth
entrant en modifiant son format (ticket Kerberos,
X509 etc) lorsqu’elle envoie la requête originale à
l’application.

1.4 Segmentation du profil

professionnel/personnel
Les applications mobiles natives vont chercher les
données dans les API REST et stockent ces données
sur l’équipement. Ces équipements sur lesquels
sont stockées des données professionnelles permettent d’y accéder hors-ligne. C’est l’exemple
le plus parlant du « Directeur Général qui voyage en avion ». Cependant, ce phénomène a
également donné naissance à une nouvelle menace touchant les applications du navigateur, qui
généralement, ne laissent aucune donnée sur l’appareil. Il est donc devenu essentiel de protéger
ces données contre les attaques actives, ou tout simplement en cas de perte.

Le BYOD vient contrarier le désir des entreprises de contrôler les appareils pour les protéger
contre la perte des données sensibles, notamment car les employés ont des attentes et veulent
être autonomes quant à l’utilisation personnelle de leurs équipements.

Les mécanismes de segmentation et la forme qu’ils prennent pour les employés sont différents.
La gestion des applications mobiles (MAM, Mobile Application Management) modifie chaque
application professionnelle (via le « wrapping » ou un SKD) pour effectuer les contrôles suffisants,
tout en ne modifiant aucune application personnelle de l’employé. Du point de vue de l’employé,
une application compatible avec le MAM permet aux applications personnelles et professionnelles
de coexister.

Le concept de double personne est, pour l’utilisateur, une expérience différente, à savoir celle
au cours de laquelle l’employée passe explicitement d’un environnement personnel à un
environnement professionnel (une expérience, pour certains, négative). Pour accéder au profil
professionnel du téléphone, l’employé devra s’authentifier, habituellement au moyen d’un
code PIN ou d’un identifiant validé localement. Les capteurs d’empreintes digitales des tout
derniers téléphones iOS et Samsung (et la disponibilité croissante de leurs fonctionnalité pour
les applications tierces) rendent crédible le scénario dans lequel l’employé pourrait utiliser son
empreinte digitale pour accéder au profil professionnel de son smartphone.

Plusieurs technologies, dont la virtualisation et les conteneurs, permettent la mise en place du

concept de double personne. Dans le modèle de gestion par conteneur, l’employé télécharge et
installe une application mobile qui créé et isole un environnement spécifiquement professionnel.
En toute logique, les applications professionnelles sont exécutées à l’intérieur du conteneur et ne
peuvent, par conséquent, que fonctionner dans le respect des politiques de sécurité décidées par
6
 LIVRE BLANC

l’administrateur de l’entreprise, pour ce container en particulier.

Au-delà d’appliquer les politiques de sécurité aux applications professionnelles, l’agent de

conteneurisation participe également à améliorer la productivité des employés qui les utilisent, en
activant un modèle de type SSO pour y accéder. Dans le modèle NAPPS évoqué ci-dessus, l’agent
du conteneur peut jouer le rôle de l’agent du jeton (celui par lequel les jetons d’accès OAuth
sont obtenus et utilisés pour les appels API).Une fois l’employé authentifié dans le conteneur, ce
même conteneur peut utiliser les protocoles NAPPS pour obtenir les jetons OAuth nécessaires
aux applications professionnelles. Du point de vue de l’employé, les applications professionnelles
fonctionnent tout simplement, et ne nécessitent aucune étape d’authentification explicite.

Ce cas de figure est schématisé ci-dessous :

Dans le schéma ci-dessous, notez que l’application native S1 n’interagit pas directement avec
l’utilisateur pour l’authentification. C’est le conteneur qui interagit, en tout logique, au nom de
l’application professionnelle.

Serveur Application
d’authentification Conteneur native S1 API S1
Ouverture du navigateur à la page d’authentification

Authentification de l’utilisateur
via le SSO à l’entreprise (invisible)

Code d’authentification (via le navigateur)

Echange du code pour le jeton
AT1 + RT1
L’utilisateur
clique sur
l’icône S1n
RT1 + portée de s1
AT2
Passage AT2
Appel API (AT2)
Validation (AT2)
Attributs
Données de l’API

Serveur Application
d’authentification
Conteneur native S1 API S1

7
 LIVRE BLANC

1.5 Résumé
Une architecture mobile moderne doit représenter le juste équilibre entre exigences de sécurité,
indépendance des utilisateurs et confidentialité. Pour répondre à ces exigences, ce document
préconise quatre éléments essentiels :

■■ L’authentification mobile

■■ Le SSO

■■ Les API

■■ La segmentation du profil professionnel/personnel

ACTIVATION CONFIDENTIALITE

SECURITE

AUTHENTIFICATION SEGMENTATION PROFIL

SSO APIs
MOBILE PROFESSIONNEL/PERSONNEL

Ces quatre éléments répondent aux exigences de sécurité, sont compatibles avec
l’authentification mobile et le SSO. De plus, la possibilité de segmenter les profils personnels et
professionnels est un facteur favorisant la confidentialité.

Cet équilibre est essentiel pour exploiter pleinement le potentiel de projets mobiles initiés par
les entreprises. La valeur ajoutée des appareils mobiles pour les entreprises est chaque jour
plus importante, avec au cœur de cette problématique, la productivité et la satisfaction des
utilisateurs.

Connectez-vous à pingidentity.com pour découvrir comment les solutions Ping Identity aident à la
mise en place de projets BYOD.

© 2014 Ping Identity Corporation. Tous

A propos de Ping Identity | Leader de la sécurité d’identification
droits réservés. Ping Identity, PingFederate,
Ping Identity est convaincue que la sécurisation des identités personnelles et professionnelles est la
PingOne, PingEnable, le logo de Ping Identity
base du progrès dans un monde connecté. Notre plate-forme de gestion des accès et des identités
et le Cloud Identity Summit sont des marques
permet à nos clients et à leurs employés d’accéder en un clic à n’importe quelle application depuis
déposées, ou des marques de services
n’importe quel appareil. Plus de 2000 entreprises, dont la moitié dans le classement Fortune 100,
appartenant à Ping Identity Corporation. Tous
font confiance à nos solutions primées pour apporter une meilleure expérience du monde numérique
les autres produits ou services mentionnés
à des centaines de millions de personnes. Rendez-vous sur www.pingidentity.com pour plus
appartiennent à leur propriétaire respectif.
d’informations.
8
10/14.1