Les soucis de la SSI face au SaaS Jerome Saiz le 1 février 2011 à 18h56, dans la rubrique Produits & Technologies Commentaires (5) gestion des identitésidentity access managementidentity managersaas Que devient votre ambitieux projet de SSO ou de passerelle d’authentification applicative maintenant que vos utilisateurs accèdent directement à Salesforce.com, qu’ils partagent leurs documents via Dropbox ou qu’ils créent des agendas partagés avec Google Calendars ? Le fait est que l’arrivée du Software as a Service (SaaS) vient bousculer le schéma traditionnel de la gestion des identités pour les applications métier. Là où la SSI pouvait encore espérer (dé)provisionner les accès de manière automatisée grâce à une solution d’IAM, nombre de celles déployées à ce jour ne s’étendent pas encore jusqu’aux applications en mode SaaS. Résultat : le tableur Excel fait un retour en force ! Et encore, le tableur apparaitrait parfois presque comme une solution enviable ! Trop souvent les identifiants de l’application SaaS sont envoyés par email aux utilisateurs qui en font la demande auprès de leur responsable métier direct, ou bien chacun ouvre son compte Google Apps pour créer des petits groupes de travail ad-hoc (c’est plus rapide que de demander à la DSI, non ?). Dans tous les cas il sera difficile de garder la trace de ces utilisateurs, et plus encore si le budget de l’application SaaS vient des métiers, rendant quasiment impossible un suivi centralisé des licences par la DSI. Mais les soucis de la SSI face au SaaS (répétez ça rapidement sans vous tromper !) ne s’arrêtent pas au seul provisionning des comptes. Il lui faut aussi prendre en compte la ré-initialisation des mots de passe perdus et la génération d’éventuels rapports de conformité (qui s’est connecté à l’application à telle date, par exemple). A ce stade la solution passe par une intégration de l’authentification locale aux applications SaaS. Fort heureusement la plupart des applications dans le Cloud proposent une authentification par API grâce au protocole SAML sur des messages SOAP. Il devient alors envisageable de lier le référentiel maison (LDAP ou ActiveDirectory probablement) aux applications SaaS via une passerelle d’authentification locale capable de dialoguer avec les différentes applications en mode Cloud (et au passage de faire respecter des limites de connexions et autres points de détail de la politique de sécurité). Il n’y aucune difficulté technique majeure à cela et il n’est pas exclu d’en faire un développement maison si l’échelle est réduite (voir l’exemple d’une intégration SSO avec Salesforce.com). La difficulté sera cependant dans la maintenance : il sera nécessaire d’ajouter de nouvelles applications en mode SaaS au fur et à mesure des besoins des utilisateurs tout en pratiquant une veille technique efficace afin de répercuter tout changement du côté des fournisseurs de service (passage de SAML 1.1 à 2.0, par exemple !). Le marché, jamais en reste, propose bien entendu des solutions spécifiques destinées à centraliser les accès aux applications du Cloud. Dernier arrivé, et à notre sens le plus complet, Okta gère la plupart des applications métier en mode SaaS (ADP, Cisco, Citrix, Concur, Google, Microsoft, Oracle, Salesforce, QualysGuard…) mais aussi l’accès à des plate-formes grand public (LinkedIn, Facebook, Paypal, Twitter…) ainsi que des services en ligne populaires (Dropbox par exemple). La solution supporte SAML 1.1 et 2.0 et permet des intégrations personnalisées. Mais Okta n’est pas seul sur ce marché : SecureAuth centralise par exemple les accès VPN de l’entreprise et l’accès aux applications SaaS. La solution supporte notamment Salesforce, Google Apps et ADP ainsi que potentiellement toute application SaaS à condition qu’elle parle SAML dans le texte. Apere propose également une solution complète en mode SaaS, appliance ou VM et capable de prendre en charge notamment la génération des rapports de conformité réglementaire. L’éditeur affirme en outre s’intégrer aux solutions d’IAM traditionnelles d’Oracle, HP, RSA, IBM, CA, BMC, Novell ou Microsoft. A noter enfin également Ping Identity, qui semble avoir une solution solide, mettant notamment en oeuvre WS-Trust afin de standardiser les jetons d’authentification des diverses applications SaaS, et qui supporte 80 références dans le domaine. L’on trouve aussi des fournisseurs de solution d’authentification forte traditionnelle qui déclinent leurs produits afin de renforcer le contrôle d’accès aux applications SaaS. C’est par exemple le cas de Vasco IDENTIKEY (capable dans sa version Enterprise de « wébifier » une authentification locale RADIUS via un message SOAP) ou de Safenet, qui avec son Authentication Manager permet de lier l’authentification locale OTP ou à base de certificats à des messages SAML sur SOAP. L’histoire a cependant montré que lorsque de petits éditeurs spécialistes répondent avec succès à un « trou » fonctionnel chez les poids lourds d’un marché bien installé, ils sont généralement rachetés ou entrent à terme en compétition avec ces derniers et disparaissent. Et il semble inconcevable que les grands de l’IAM ne prennent pas en compte les applications SaaS. Novell a d’ailleurs ouvert le bal l’été dernier avec Novell Cloud Security Service (NCSS). La solution offre une capacité de provisioning et deprovisioning des utilisateurs locaux dans le Cloud, un SSO entre applications locales et SaaS, et surtout le maintient de journaux locaux (connexions et utilisation). Et bien entendu NCSS s’intègre à la solution d’IAM de Novell. Les acquisitions de PassLogix par Oracle ou Encentuate par IBM, par exemple, vont également dans ce sens. Pour les entreprises qui ont déjà mené un projet d’IAM il semble dans ces conditions plus sage de questionner leur fournisseur quant à la prise en compte des applications en mode SaaS, et le cas échéant d’attendre l’intégration de cette fonctionnalité. Pour les autres le choix est plus cornélien. Elles peuvent déployer immédiatement une solution dédiée – dont la pérennité n’est toutefois pas assurée tant ces fournisseurs ont de grandes chances d’etre rachetés par un acteur majeur de l’IAM à court terme, ou se lancer dans un projet d’IAM traditionnel en optant pour un fournisseur offrant une roadmap claire quant aux applications SaaS. Authentification déléguée ou fédérée ? Si l’on fait le choix d’une solution de gestion des identités pour les applications SaaS c’est surtout pour ré-utiliser les identités de l’entreprise. Se pose alors la question de l’intégration des référentiels : comment la solution va-t-elle fournir les identités de vos utilisateurs à l’application SaaS distante ? Deux options s’offrent alors, l’une largement plus sûre que l’autre. Authentification déléguée. La solution de SSO transmet à l’application SaaS le login et le mot de passe sur un lien sécurisé (SSL) et lui demande de les vérifier auprès d’un service web indiqué au préalable (le plus souvent géré par l’entreprise et lié a son annuaire). Le service web renvoie alors un « feu vert / feu rouge » à l’application SaaS. Cette solution est la plus simple à mettre en oeuvre, mais aussi la moins sûre car les identifiants quittent l’entreprise, ce qui peut être contraire à la politique de sécurité en vigueur. Authentification fédérée. Les identifiants ne quittent ici jamais les murs de l’entreprise. Celle-ci valide en interne l’identité de ses utilisateurs par la méthode de son choix et génère un ticket SAML qui sera présenté au fournisseur du service SaaS. Si la relation de confiance entre les deux entités est valable et si le ticket SAML est acceptable (non-rejoué, valide, signé), l’accès sera autorisé. C’est l’approche la plus fiable mais aussi la plus complexe à mettre en oeuvre. Elle exige que l’entreprise devienne fournisseur d’identités (ce qui n’est de toute manière pas une mauvaise idée à terme !) et qu’un lien de confiance soit établi avec chaque fournisseur de service SaaS (exit donc ceux qui en sont incapables). Vous avez aimé cet article? Cliquez sur le bouton J'AIME ou partagez le avec vos amis! Notez L'article Participez ou lancez la discussion!