Solutions d accès sécurisées pour opérer une Market Place Saas multitenante
Plan de la présentation Le Saas et les enjeux économiques des services en ligne La notion de shops multi-tenantes dans une market place La gestion d'identité dans une market place à l ère du business en ligne Les objectifs à atteindre pour élaborer une solution technique Les contraintes et les exigences à prendre en compte La sécurisation des web services Une architecture décentralisée permettant aux opérateurs de gérer leur propre parc client La distribution des autorités d'enregistrement et des référentiels de gestion des habilitations Le routage dynamique LDAP Tirer profit de la solution proposée dans un écosystème orienté cloud computing
Le Saas Le SaaS Software as a service est un modèle de diffusion d'applications en ligne L éditeur fournit des API en général sous forme de Web services où simplement d'une application Stand alone. Le service est proposé généralement dans le cadre d'un abonnement récurrent, ou un payement à l usage avec des fonctionnalités intégrées Les clients ne paient plus des licences logicielles mais simplement des tickets d usage ou encore un forfait limité dans le temps Toutefois dans la plupart des cas, les API fournies (réalisées grâce aux WebServices ou à l'aide de l architecture REST (Representational State Transfer), nécessitent une intégration lorsque le client consommateur dispose d'un système d information.
Les enjeux du Saas dans l économie numérique A l origine, les premières applications Saas adressaient le segment du marché des entreprises en réseau intranet. L essor des modèles sécurisés on line ont permis de répondre plus efficacement aux attentes des clients désirant consommer (quand la sécurité le permet) des services sur le web. Aujourd hui le marché est en pleine croissance avec l arrivée de ces grands acteurs dont l approche sécurité est au cœur de leur préoccupations. Il s agit d une rupture technologique qui remet en cause la notion de système d'information propriétaire. Réduire leur CAPEX pour le transformer en OPEX passant ainsi à un modèle économique privilégiant des dépenses fixes pour des coûts d infrastructure, de maintenance et de licence maitrisés.
Market Place de quoi s agit-il! Il s agit d un portail permettant de louer des shops (magasins) destinés à la vente du Saas en ligne Les fournisseurs peuvent donc publier leur services ou applications en bénéficiant de fonctionnalités permettant de monétiser leur produits en toute sécurité. Les clients du saas peuvent à leur tour bénéficier de l infrastructure mais aussi des assets de sécurité y compris les moyens d accès et de connectivité avancée Le SSO permet au utilisateur finaux d'éviter de rejouer des authentifications L'Authentification fournie par un tiers Souscription, billing et payements en ligne etc En location les shops peuvent donc bénéficier d un catalogue en ligne Une instance magasin en ligne ou shop est donc proposé pour un éditeur de saas
Le business modèle de la Marketplace (modèle décentralisé) Le but d une marketplace consiste à se doter des processus et outils permettant d identifier, permettre de trouver ses applications pour les consommer à la demande puis faire payer et assurer le SAV. Les fonctionnalités et les acteurs d une market place : Fournisseurs Clients Shop1 Shop 2 Shop 3 Marketplace Billing Acces mgt Payement Support Etc
Les contraintes et exigences d une market place B to B to C «Nazim» est un client d une Shop A et serait également client d une Shop B Identité unique pour la Marketplace : il doit donc porter la même identité utilisateur quelque soit la Shop. Mais «Nazim souhaite également limiter ses manipulations et disposer du confort d usage, donc ne souhaite pas décliner sont identité systématiquement. Il exige également à son fournisseur la garantie de l étanchéité des données qu il confie à son fournisseur De même, le fournisseur exige que son parc client soit invisible donc non accessible par d autres fournisseurs saas ou vendeurs.
Les fonctions exigées Identification des client avec des mécanismes digne de confiance Exiger une authentification sur la totalité des ressources protégées Ne pas imposer des authentifications récurrentes nécessitant parfois de retenir maladroitement des secrets (ce qui pourrait compromettre les données et les ressources protégées) Permettre aux shops d opérer leur référentiel client et de l héberger (responsabilité non partagée) dans un environnement sous contrôle. Pour chaque shop, mutualiser les contrôles d accès et la gestion des secrets (mais pas forcément de confier l ensemble des processus de à un tiers). Des référentiels utilisateurs étanches et sous la responsabilité exclusive des shops. Garantir un usage sécurisé des web services
Les processus généraux de la gestion d identité Processus d authentification Traçabilité enregistre enregistre Client à authentifier Protocole authentification Service authentification redirection Gestion des droits Autorise l accès Service Porteur de secret active les secrets distribue distribue Coffre à secrets Infrastructure de gestion des secrets Référentiel authentification publie Module d admin Référentiel des habilitations Provisonning Gestion etcc administration Administrateur
Le Single Signe On (SSO) 1. Le consommateur veut accéder à un service qui demande une authentification. 2. L application redirige le consommateur vers le fournisseur d'identité. 3. Le consommateur s'authentifie auprès du fournisseur d'identité. 4. Le fournisseur d'identité redirige le consommateur vers l application et lui confie un artefact d'authentification. 1 2 8 5 3 4 5. Le consommateur présente l'artefact à l application (jeton de session). 6. L application demande au fournisseur d'identité de valider l'artefact. 7. Le fournisseur d'identité valide l'artefact, ce qui authentifie le consommateur. 8. L application identifie le consommateur Appli 1 Appli 2 6 7 Appli 3 IAM
Les web services Il s agit de programmes informatiques exécutables en ligne donc à distance La forme des web services est souvent assimilée à des API ou interfaces d exécution. Le protocole SOAP introduit lui la notion de WSP (web service provider) et WSC (Web service client) pour distinguer le client et le fournisseur de service. Au niveau pratique les web services permettent finalement de mettre à disposition des clients un ensemble d applications accessibles à une large communauté dans le but de satisfaire ses besoins informatiques. L'intégration de ces web services avec un système d'information propre reste à la discrétion du client. J2EE compliant, ce principe d échange et d exécution procure une facilité d intégration et une large diffusion grâce au protocole HTTP d une part et grâce à ses supports d intégration largement accessibles
Résumé des besoins de l architecture Un protocole d échange web service sécurisé Une infrastructure de gestion d identité avec : Un mécanisme d authentification forte supportant le protocole SSL V3 (Authentification forte) Un Mécanisme de SSO Un mécanisme de provisionning des utilisateurs décentralisé Un infrastructure de production, de publication et de distribution de certificats X509 Un mécanisme de routage des requêtes utilisateurs vers les référentiels adéquats (tant pour la vérification d identité que pour les accréditations et habilitations).
Besoins techniques pour réaliser l architecture cible Application cliente WSC SOAP sur HTTP Portails market place Filtres de servlets Application SaaS HTTP Application SaaS Gateway OSDP Security Filters Provsionning utilisateur Module D'authentification Et d'identification Référentiel Référentiel
Terminologie des composants techniques 1. Une Gateway web services permettant de filtrer les accès web services et contrôler la cohérence des formats WSDL lors de l invocation du service. 2. Un serveur unique d authentification et d identification avec SSO. 3. Un ensemble de filtres permettant de contrôler les enveloppes SOAP représentant les requêtes clientes Web Services (contrôle du contenu SOAP) 4. Un mécanisme de provisionning utilisateur : son rôle est de produire, distribuer et gérer le cycle de vie des credentials fournis à l utilisateur. 5. Un mécanisme de fédération d identité permettant l échange avec l Identity Provider CAS mais également intégré dans les filtres SOAP régulant les accès Web Services. 6. Des référentiels utilisateurs sous le contrôle de chaque Shop, technique cela se décline en annuaire LDAP où seront stockés les credentials et données profile des utilisateurs. 7. Une PKI couvrant l ensemble du cercle de confiance de la Market Place signant les certificats produits par les autorités d enregistrement de chaque Shop pour certifier l origine.
Le rôle de la gateway web services Les principaux besoins en matière de sécurité dans un contexte d usage exclusif de Web Services saas : De gérer les identités consommateurs des WSP De contrôler l accès à ces WSP. Cela nécessite d'identifier et d'authentifier les WSC et de vérifier la conformité des requêtes SOAP au travers des mécanismes SAML (signature des enveloppes SOAP à l aide de certificats X509 détenus par les utilisateurs). D identifier les WSC consommateurs à l aide de mécanismes compatibles avec les protocoles (SSL V3, VPN supportant les mécanismes de cryptage compatibles avec la norme des certificats X509). De contrôler les accréditations et les autorisations des services souscrits, en particulier, sur certains services payants (facturés à l'acte par exemple). Au travers d un mécanisme unique mais s appuyant sur des référentiels différents. De conserver des traces des transactions afin de détecter d'éventuelles attaques et de disposer de preuves en cas de litige avec des partenaires. De mutualiser les accès à l ensemble des services au travers un guichet de contrôle unique fondé sur la déclaration de l identité du consommateur.
La solution open source CAS (IAM + SSO) Central Access Service ou CAS serveur est identity provider fournissant une solution Single Sign On pour les accès aux services et applications web. Autorité de confiance dans les mécanisme d authentification. Portabilité : le CAS serveur et client sont élaborés dans un contexte JAVA Les filtres sont à la fois web services compliant et servlets compliant (les applications client léger peuvent à leur tour figurer dans le cercle de confiance du CAS)
Fonctionnement du CAS Une solution CAS est composée comme la plupart des solutions IAM d un serveur d authentification et de filtres divers (appelés clients CAS) comme la plupart des centrales IAM. Le serveur CAS Le serveur CAS a pour rôle d authentifier et de fournir les jetons d identification pour le compte des utilisateurs connus. Il a également pour rôle de valider ses propres tokens fournis à ces derniers quand ses propres filtres le lui demandent. Le client CAS Le filtre CAS est un module intégré à toute application protégée par le CAS et dont le principe consiste à intercepter toute requête vers cette application en vérifiant dans la foulée la nature de la requête, la validité des empreintes fourni par le serveur CAS et la conformité de la requête vis-à-vis de la politique de sécurité adopté de la centrale IAM CAS.
Fonctionnement du CAS (suite) Les clients CAS sollicitent le service, ce dernier redirige le client vers le serveur CAS afin que ce dernier valide la tentative de connexion. Une fois que le CAS a vérifié que vous êtes connecté, il renvoie vers l'url spécifiée avec cependant un changement : CAS ajoute un ticket de service (Token) à l'url. Le client CAS exploite que le paramètre «jeton CAS» et reconnaît que l'utilisateur vient de réaliser son authentification auprès du serveur CAS. Et pour valider, le client CAS interroge silencieusement le serveur CAS sur la validité du Token délivré. Le serveur CAS répond à cette requête via un document XML qui décrit le Token de service. Certaines des valeurs retournées contiennent notamment la validité du Token, le nom d'utilisateur associé. Le Token fourni par le serveur est toutefois limité (cycle de vie valable uniquement pour l accès à la ressource), mais permet le SSO.
Le SAML Le SAML est un protocole d identification et d authentification, il permet aux fournisseurs d identité d adopter une démarche unique voire des composants standardisés pour faciliter les échanges entre les cercles de confiance les domaines internet divers. A ce titre le SSO est l une de ses principales attraction (pour le monde des développeurs J2EE). Les enveloppes SOAP supportent ainsi les assertions SAML, ce qui le rend particulièrement adapté au SSO appliqué dans le monde des web services. Le SAML se décompose en deux filtres pour sécuriser les échanges : Le SP (Service Provider), fournisseur de service, contrôle les accès aux web services. Il empêche tout accès sans authentification préalable aux web services et redirige l'utilisateur non authentifié vers son fournisseur d'identité. L'IdP (Identity Provider), fournisseur d'identité, a pour rôle d'authentifier l'utilisateur ainsi que de récupérer des informations additionnelles associées à son identité. Cette authentification est réalisée au travers d un jeton fourni par l IDP.
Les principes de fonctionnement du SAML Les jetons SAML sont apposés dans ke contenu des enveloppes SOAP, sur les couches XML Encryption et XML Signature. SOAP étant le protocole d'encapsulation standard des messages XML, utilisé principalement par les Web services. Il se traduit par la constitution d enveloppes XML standardisés et normalisés par le protocole lesquels dressent la sémantique des assertions transportées. XML Encryption est le protocole standard de chiffrement des messages XML. XML Signature est le protocole standard de signature des messages XML. Tout comme le XML Encryption il permet de cibler le contenu à signer. Cela permet à plusieurs intervenants de signer chacun une partie différente du document XML. Le SP et L'IdP sont deux entités qui ont connaissance chacune l'une de l'autre en termes d'identifiant et de certificat. Les messages XML qui transitent sur le réseau sont donc chiffrés par la clé publique du destinataire, seul capable de déchiffrer le message avec sa clé privée. L'émetteur signe ses assertions avec sa clé privée permettant au destinataire de vérifier sa provenance.
Pincipes (suite) Les 2 implémentations possibles des mécanismes de filtres HTTP Header SOAP enveloppe SOAP Header WS Security SAML Token DIGITAL Signature Les mécanismes de Ws Security réalisent les authentifications HTTP Header (SAML Token) SOAP enveloppe SOAP Header DIGITAL Signature Le jeton SAML est transporté dans les Headers HTTP(S) via un protocole SSL V3
Scénario d une market place monotenant L instance de la market place est opérée par un seul vendeur dans un environnement privé, un second vendeur aura alors sa propre instance. Application cliente WSC SOAP sur HTTP Portails Market Place Filtres de servlets Application SaaS HTTP Application SaaS Gateway Market Place Security Filters Requête Autorité d'enregistrementc Autorité de certification Distribution des secrets Certification du secret Référentiel user de la Shop (LDAP) CRL Provisionning Des utilisateurs PKI Shop
Scénario d une market place multitenants L instance de la market place est opérée par plusieurs vendeurs à la fois. l instance est multi-locataires ou multi-tenante. Application cliente WSC SOAP sur HTTP Portails Market Place HTTP Gateway market place Filtres d'authentification et d'identification Application SaaS Application SaaS Spring Security Filters Apache Directory Server Autorité de certification Certification du secret LDAP 1 LDAP 2 LDAP 3 AE 1 AE 2 AE 3 Requêtes CRL PKI market place Distribution des secrets
Scénario d une market place multitenants (suite) Déléguer les opérations d enregistrement et de provisionning aux seules shops. Déléguer la gestion des référentiels pour chaque shop : l étanchéité des supports physiques avec des annuaires LDAP V3 isolés physiquement. Les mécanismes d enregistrement, de production et de validation de certificats seront donc répartis entre la shop et la Market Place. Une requête de certificat est prise en charge par l autorité d enregistrement de la shop, la demande est ensuite transmise à l'autorité de certification centrale qui signe et émet le certificat vers le demandeur Seule la Shop est responsable de l identité du demandeur, la Market Place ne fera que confirmer et attester de cette identité auprès des autres ressources.
Le SSO n est plus garanti dans une telle architecture! Une telle architecture introduit une complexité supplémentaire : Dans la forme actuelle le SSO n est plus garanti sur la totalité du cercle de confiance couvert par l IdP de la market place (les référentiels d'authentification étant sous le contrôle des shops). Pour résorber cet écueil, la market place doit disposer du minimum d informations pour pouvoir fournir ou vérifier la validité des jetons ensuite d'être capable de rediriger l'utilisateur vers le bon référentiel. L'IdP doit pouvoir être le seul à interroger les référentiels de chaque shop Chaque mécanisme d autorisation et de gestion des habilitation de chaque doit être capable de disposer de l identité non pas à l issue d une authentification, mais par simple interrogation des l IDP (identity provider). Un routage LDAP est donc prévu pour rediriger l utilisateur vers le référentiel de la shop dont il désire consommer les services
Routage dynamique LDAP Il s agit en réalité d un mécanisme permettant la sélection dynamique du contexte de sécurité LDAP au moment du challenge SSL V3 par exemple. Il repose sur une clé de recherche ou un Id unique attribué lors de l opération de certification intervenue lorsque son certificat (clé publique) a été signé par l autorité de la shop. Dont les avantages se déclinent comme suit : Id unique (identité de l'idp) permettant une fédération d identité sur la totalité du cercle de confiance de la Market Place. Donc de disposer d un identifiant permettant à chaque référentiel cible de pouvoir attester de son identité auprès de l IDP. Le couple (token, Id) connus par l IDP De garantir l unicité de l identité (les phénomènes de doublons peuvent induire des dysfonctionnements désagréables) De pouvoir bénéficier d un mécanisme de SSO tout a fait opérationnel. De pouvoir gérer d une manière centralisée ou décentralisée toute opération de révocation des credentials distribués. De pouvoir gérer un cycle de vie unique des certificats diffusés sans impacts majeurs sur la totalité des référentiels. Les données de profils seront confinées aux seuls référentiels et ne seront donc pas accessibles aux tiers
Modèle de déploiement de la solution Principal Filtres Spring Security + IdP Routage Dynamique LDAP LDAP 1 LDAP 2 -Service LDAP : Apache Diectrory studio -Filtres : framework Spring sécurity (la génération des Id uniques doit être implémentée) LDAP 3 -Protocoles d authentification supportés : kerberos, NTP. -Autres implémentation JAAS (Java Authentification and Authorzation service).
Les avantages attendus par ce modèle d'utilisation de l'applicatif Des Plateformes possibilité pour un utilisateur de se voir allouer plusieurs ressources possibilité pour une ressource d'être accessible par plusieurs utilisateurs prise en charge de plateformes plus ou moins évoluées De la facturation identification du client identification du service commercial identification de l'utilisateur De l'utilisateur Single Sign-On, gestion des identités possibilité pour un utilisateur d'avoir des services attachés à plusieurs clients différents nécessité de mise en œuvre d'un portail unifié pour agréger les services et permettre leur commercialisation à partir d'un seul point de vente muni des fonctionnalités et processus métiers verticaux.
Architecture d'un écosystème Cloud Computing (annexe) Saas ISM PaaS BSS Cloud OSS Cloud Hardware VPC Virtual Infra Hardware Gamma OS Hyperviseur Datacenter A Datacenter B
Quelques exemples de Saas (annexe) Le Web SMS Messagerie API de stockage Portlets (météo, géolocalisation etc). Certaines applications comme le CRM, outils de datamining (qui nécessitent en général des application de type base de données, des espaces de stockage importants) Etc