Position du problème
La plupart des système SaaS intègrent l’application et le système de vente dans un même logiciel.
Si différentes applications web doivent être diffusées en mode SaaS par une même entité, le premier problème à résoudre consiste à assurer le service de connexion unique (SSO) entre le système de vente et les différentes applications, sans oublier les sites support tels que la plateforme CRM et les sites de communauté. Pas de problème, c’est le rôle d’un serveur OIDC, OAuthSD fait cela très bien.
Le deuxième problème, plus intéressant, consiste à transmettre des informations du système de vente vers les applications.
S’agissant de la validité de l’abonnement et des options (payantes), il faut sécuriser ces données, c’est à dire permettre à l’application destinataire de contrôler :
l’intégrité (les données n’ont pas été falsifiées),
l’authenticité de leur origine (elles ont bien été délivrées par le système SaaS),
l’actualité (ce sont bien des données valides à l’instant considéré),
la destination (ce sont bien des données relatives à cette application),
et bien sûr l’identité de l’utilisateur final (ce n’est pas un intrus qui utilise l’application).
La solution : OAuthSD
OAuthSD permet d’intégrer les données SaaS sous forme de déclarations supplémentaires dans la charge utile du jeton JWT. Il suffira à l’application destinataire (cliente du serveur OIDC) de valider le jeton d’identité par introspection (et non localement afin d’assurer l’actualité) pour réaliser en une seule opération les contrôles décrits ci-dessus.
Le système i-Tego SaaS et l’une de ses applications NSS Lite illustrent parfaitement cette technique.
Pour réaliser cela, nous avons :
intégré dans une même application le serveur OIDC et le système de vente,
développé des plugin d’extension OIDC-SaaS notamment pour des applications fondées sur SPIP ou Wordpress .
Le flux des échanges est le suivant :
1 : l’utilisateur s’inscrit sur le système SaaS et souscrit un abonnement.
2 : Il se connecte depuis une application cliente du système SaaS.
3 : Le serveur d’authentification adresse à l’application cliente un jeton JWT signé dont la charge utile a été complétée avec :
les données relatives à l’abonnement, en particulier sa date de fin,
les droits de l’utilisateur sur l’application,
les options souscrites.
Rappelons que, selon le protocole OpenID Connect :
le jeton adresse également les portées de l’autorisation (claims) donnant les droits de l’application sur les données de l’utilisateur.
le serveur d’authentification agit comme un service d’inscription et de connection unique (Single Sign On, SSO) . Ainsi, l’utilisateur connecté à une application cliente SaaS est également connecté aux autres applications pour lesquelles il a souscrit un abonnement
Notre offre de services
Nous serions heureux de pouvoir assister les PME pour leur permettre de développer leur propre système de SaaS et d’adapter leurs applications web.
Notre positionnement de conseil et d’assistance permettrait un développement indépendant de prestataires extérieurs coûteux. Et de systèmes tiers hasardeux en termes de sécurité : pourquoi nourrir le big-data au profit de vos concurrents ?
RSS 2.0