Quel intérêt à utiliser Ping Identity avec Azure AD Premium ?

 

Il y a quelques mois, Microsoft annonçait son partenariat avec Ping Identity pour renforcer son offre Azure AD Premium:

Mais cette annonce coïncidait avec l’annonce quelques semaines auparavant de la mise en preview d’une fonction de App Gateway au niveau d’Azure AD Connect (fonctionnel mais toujours en preview à ce jour). Ainsi, beaucoup de mes clients et contacts me demandaient au fil des semaines quel pouvait être l’intérêt pour eux d’utiliser Ping Identity alors que Microsoft fournissait maintenant une App Gateway permettant non seulement de publier des applications on-prem au niveau du portail Azure AD Premium sans l’obligation d’ouvrir des ports au niveau des firewall mais également de jouer des authentification sur l’annuaire Active Directory local sans déployer ADFS. Nous allons essayer de répondre à cette question dans cette article.

Déjà, revenons quelques instant sur l’offre Ping Identity. Ping Identity est l’entreprise leader dans le domaine des solutions de fédération d’identité pour les entreprises. Cette entreprise américaine a vraiment été un des pionniers en la matière, principalement pour les organisations avec des besoins complexes ne pouvant pas être couverts avec ADFS et Shibboleth. Mais depuis environ 18 mois, les offres Ping Identity ont été progressivement dépassées par les solutions de IDentity as a Service, qui rappelons le, propose notamment un système de fédération multi-tiers en mode SaaS. Ping Identity a essayé de réagir sur le segment IDaaS, mais leur architecture produit n’a pas convaincu, laissant le champs libre à Microsot, Centrify et Okta sur le marché IDaaS. Il fallait donc régir pour ce leader établi  de la fédération d’identité.

En septembre dernier, Microsoft annonçait donc son partenariat avec Ping Identity:

En parallèle, Microsoft proposa en private preview puis en public review la fonction App Gateway intégrée à Azure AD Connect avec notamment les possibilités suivantes:

  • Fournir un accès aux applications internes sans modification des firewall, des routeurs ou des reverse proxy
  • Sécurisation de l’accès aux applications internes via un mécanisme de « reverse VPN » basé sur la fonction bus d’Azure
  • Publication d’applications web internes utilisant IWA (Integrated Windows Authentication)
  • Publication d’applications Web utilisant « form-based access »
  • Publication d’applications publliées via la fonction Remote Desktop Gateway

Ces avancées notoires permettant nottamment à Microsoft de rattraper son retard sur la fonction Cloud Gateway proposé par Centrify via son offre IDaaS.

Que peut donc me fournir Ping Identity en plus de ces fonctions déjà très intéressantes ?

La raison principale de ce partenariat est de pouvoir traiter des applications web internes utilisant l’authentification de type headers HTTP.

Pour ce, il sera nécessaire d’installer un composant supplémentaire PingAccess au niveau du réseau local, ce composant communiquant avec Azure AD Premium et le connecteur Azure AD Connect:

Pour ce, il est possible directement au niveau de la console Azure AD Premium de publier de telles applications en indiquant quelles seront accédées en passant par le composant PingAccess:

Un des intérêts de cette combinaison est de « contourner » les options de sécurité assez faibles d’une authentification par headers Http en utilisant des APIs Azure spécifiquement développées pour faire communiquer Azure AD Premium et PingAccess: ainsi, il sera possible de définir des règles d’accès et de rôles qui seront transposées et traduites par le composant PingAccess depuis le RBAC Azure:

Quel avenir pour ce partenariat ?

Euhm… bonne question ! Pour ma part je ne suis pas convaincu par le fait que cette fonction sera suffisante a faire décoller le partenariat technologique et commercial, surtout que pour l’instant le modèle de pricing de PingAccess pour Azure AD est assez obscure, Ping Identity n’étant pas spécialement connu pour le côté bon marché de ses produits… (bon, après ce sont de très bons produits, tout se paye). De plus, au travers de mes différentes missions de consulting sur la partie IDaaS, ce type d’authentification (Headers Http) n’étaient pas la priorité des clients…

Un point stratégique important est de comprendre que les offres de IDaaS vont petit à petit éliminer le besoin de solution de fédération d’identité installées localement (ADFS, Shibboleth, Ping, ForgeRock, etc.) et vont remplacer sous forme de service SaaS l’ensemble des composants de fédération. Bien sur, pour des besoins très spécifiques, notamment en ce qui concerne des scénarios complexes dans des grandes entreprises, les passerelles de fédération d’identité installées localement ont encore de beaux jours devant elles, mais dans 5 ou 6 ans ? Pas certain !

Bon, à la fin, cela serait peut-être plus simple si Microsoft rachetait Ping Identity, non ? 😉

40 minutes pour tout comprendre de Microsoft EMS

Microsoft Cloud Platform vient de poster une vidéo de présentation de Microsoft EMS (Enterprise Mobility & Security) extrêmement bien réalisée. La vidéo mêle la présentation globale de chaque module EMS et les enjeux rattachés en termes de productivité ou de sécurité ainsi que des démonstrations techniques extrêmement bien ciblées.

En 40 minutes, cette vidéo permet à chacun de comprendre le positionnement d’EMS et les fonctionnalités principales des différents modules. cette vidéo est tellement simple qu’elle peut même être envoyée à un manager, c’est dire !  😉

L’ensemble des modules est passé en revue, Azure AD Premium, AIP, Conditional Access, etc.

La vidéo est accessible ici:

 

 

Azure AD Pass-Through Authentication et Seamless SSO par Maxime Rastello

Maxime Rastello est consultant & MVP, il s’est fait une spécialité de la partie Azure et notamment des processus et des fonctions liées à l’IAM ou à la sécurité dans Azure. Depuis peu, il a commencé une série de vidéos, dites « Deep-Dive ». C’est vraiment très bien fait et didactique, le format entre 15 et 30 minutes est parfait pour approfondir le sujet mais sans que cela devienne assommant. La dernière vidéo en date porte sur deux nouvelles fonctions en preview, qui de mon point de vue, vont révolutionner l’usage d’Azure Active Directory dans le monde des entreprises et notamment dans les PME ou ETI: Azure AD Pass-Through Authentication et Seamless SSO.

Pour suivre sa chaîne YouTube: https://www.youtube.com/channel/UCL9JIy1auTKjwESwa3XCJ7g/videos

Pour le suivre sur Twitter: @MaximeRastello

Pour retrouver sa dernière vidéo sur Azure AD Pass-Through Authentication et Seamless SSO:

 

MIM 2016 & SAP

mim_sapTravaillant actuellement sur un projet implémentant la gestion du cycle de vie des utilisateurs SAP et des rôles SAP depuis MIM, il me semblait intéressant de créer un article court pour rappeler les possibilités de gestion des objets SAP via MIM.

Pour appel, SAP possède sa propre base de compte utilisateurs, lorsque un utilisateur final utilise l’interface web ou le GUI lourd SAP pour se connecter à l’instance SAP, il doit utiliser un compte étant dans cette base. Cette base permet aussi de gérer la partie SoD et la partie RBAC au niveau de SAP lui-même.

Même si cela ne rentre pas dans le cadre de cet article, rappelons que MIM ne permet pas de faire du SSO, mais éventuellement du CSO au niveau de l’authentification SAP, et à minima de gérer le cycle de vie des comptes, voir de créer les « triggers » qui vont bien au niveau de la base SAP pour assurer les mécanismes SoD & RBAC propres à SAP. En effet, le « connecteur » MIM pour SAP intègre maintenant la gestion des rôles au sens SAP du terme.

Si vous recherchez à faire du SSO sur SAP, je ne saurais que trop vous conseiller de réaliser cela en utilisant le protocole Kerberos, de cette façon vous aurez un système fiable, intégré à Active Directory et générique à l’échelle de votre SI. Juste une information importante, utiliser Kerberos pour gérer l’authentification sur la base SAP ne vous épargne pas de devoir créer les comptes utilisateurs dans la base propriétaire SAP, donc SSO ou pas SSO, MIM vous sera utile.

Si vous utilisez SAP sur un serveur Windows et que vous désirez faire du SSO, je vous conseille cette vidéo:

Si vous utilisez SAP sur un serveur Unix/Linux et que vous désirez faire du SSO, je vous conseille cette vidéo:

Mais revenons à nos moutons, le gestion de cycle de vie des utilisateurs dans la base SAP.

Depuis FIM 2010, et donc pour MIM 2016, le connecteur pour SAP est un connecteur générique utilisant des Web Service. Le connecteur SAP pour MIM 2016 est compatible avec les versions SAP ECC 5 & ECC 6.

Tout d’abord il faut télécharger le connecteur web services pour MIM 2016, il est accessible [ ICI ]

La documentation pour le connecteur Web Service est accessible [ ICI ] – A vérifier, mais il ne me semble pas avoir vu une documentation mise à jour spécifiquement pour MIM 2016

De plus, dans le package des connecteurs web services, Microsoft fournit un outil supplémentaire, le « Web Service Configuration Tool » permettant de créer un projet .wsconfig qui pourra être publié directement dans le répertoire \Synchronization Service\Extensions\

Exemple de configuration d’un projet sur un web service intégrant un WorkFLow via le Web Service Configuration Tool:

mim_web_service_configuration_tool

La documentation décrit les différents templates utilisables au travers des web services, pour SAP, il s’agit notamment des objet User SAP, Group SAP et Role SAP. La documentation Microsoft aborde les aspects FIM/MIM mais très peu les prérequis ou la configuration côté SAP, quand on est pas un spécialiste SAP, et je suis très loin d’être un spécialiste SAP, la documentation est un peu juste sur ce point – mieux vaut être accompagné par un « vrai » architecte SAP sur le projet afin de bien comprendre le modèle de données et les particularités des services web sur cette plateforme.

Pour compléter la documentation Microsoft, je vous conseille fortement de lire les articles suivants:

Integrate SAP HR and Active Directory using Forefront Identity Manager (FIM) SAP Connector for WS – article écrit par Salvatore Pellitteri, MVP Microsoft lui aussi, et qui a l’avantage de réaliser un step by step très complet.

#  Integrating SAP Web Services with MIM – (part 1) – article écrit par Ingólfur Arnar Stangeland, consultant travaillant sur les technologies de sécurité proposées par Microsoft, cet article est le premier d’une série et possède l’avantage d’être récent et focus sur la version MIM 2016.

How to Create a Web Service Connector for SAP in FIM/MIM – (part 1) – et How to Create a Web Service Connector for SAP in FIM/MIM – (part 2)  – série de deux articles écrite par Tracy Yu, employé de Microsoft – ces articles font le focus sur la version MIM 2016.

Il ne me souhaite plus qu’à vous souhaiter bonne lecture – je devrais poster dans les mois qui viennent un complément à cet article avec un step by step en Fr sur la partie MIM/SAP.

 

 

Azure AD Application Gallery

Azure AD Application Gallery
Azure AD Application Gallery

Comme vous le savez déjà si vous travaillez avec les concepts de fédération d’identité et d’IDentity as a Service (IDaaS), notamment via Azure AD Premium, il est parfois difficile de connaître la liste des applications supportées ainsi que le mode de fédération ou de SSO que ces applications SaaS acceptent. Microsoft publie un site web « Azure AD Application Gallery » permettant de consulter la liste des applications supportées et de déterminer quel type de SSO elles sont capables de « comprendre ».

Pour faire simple, il existe 4 types d’applications SaaS selon la terminologie utilisée par Microsoft – notons toutefois, que les protocoles acceptés par l’application ne dépendent pas directement de Microsoft mais de l’application elle même, il y a toutes les chances pour que les « capacités » de l’application en termes de SSO ou de Fédération soient exactement les même quelques soit la solution d’IDaaS employée:

# Application de type « federated SSO only »: ces applications supportent la fédération et le SSO via la fédération de façon basique, généralement elles requièrent de mettre en œuvre un système de provisioning des comptes coté applicatif,  rappelez vous que la fédération d’identité ne vous élimine pas le fait de devoir créer les comptes côté applicatif de façon à lister les personnes acceptées et pouvoir définir le profiling applicatif (en gros qui a droit à quoi dans l’application)

# Application de type « federated SSO and provisioning »: ces applications supportent la fédération et le SSO via la fédération, et permettent aussi de gérer le provisioning des comptes via la solution d’IDaaS elle-même. Ici, on définie des règles, et la création des comptes, voir l’appartenance aux bons groupes côté applicatif, se fait via la solution IDaaS, plus besoin de penser un système de provisioning en parallèle.

# Application de type « federated SSO and consent »: ces applications supportent la fédération et le SSO via la fédération, et supportent la fonction « consent » – pour faire simple, cela permet à un utilisateur lorsqu’il utilise la passerelle de fédération d’accepter que ces identités soient utilisées et passées à l’applications SaaS pour valider son identité. Ce mécanisme est assez peu utilisé, permet sous certaines législation de demander la permission à l’utilisateur de transmettre son identité à l’application demandée. Qq explications sur le « consent » dans cet article: https://identitynetworks.wordpress.com/2009/03/09/ready-able-and-willing-federated-consent/

# Application de type « password SSO only »: ces applications ne supportent pas la fédération, et ne sont capable de faire du SSO que sur la transmission d’un couple username+password. Il y a un effet de bord principal à ce type d’authentification, c’est lorsque l’on veut utiliser le service d’IDaaS depuis un périphérique de type smartphone ou tablette, mais ceci est un autre débat, je ferais un article prochainement sur ce sujet. Ici, il faudra alors mémoriser le couple username+password ou éventuellement se baser sur l’authentification AD, mais il faudra alors aligner ce couple avec le compte dans l’application SaaS.

Sur l’interface « Azure AD Application Gallery », il suffit de choisir le type d’applications que l’on veut lister, et le site vous propose la liste des applications supportées par Azure AD Premium dans ce cadre. Par exemple:

consent_federation_applications

 

 

European AFS & Kerberos Conference 2014

afs-kerb-2014

 

 

 

 

 

 

Les inscriptions pour la « European AFS & Kerberos Conference 2014 » sont ouvertes – Vous pouvez vous rendre [ ici ] pour plus de détails.

Cette année, les conférences feront un focus sur l’intégration Web, la correspondance avec les PKI ou encore les différentes méthodes de SSO héritées du protocole Kerberos.

 

Un SSO pour les applications Cloud relié à Active Directory

Planet  Centrify débarque dans le monde du SSO Cloud et de la Fédération d’Identité avec une solution assez révolutionnaire en terme d’approche: Centrify DirectControl for SaaS.

En effet, l’idée est de réaliser ici depuis votre PC sous Windows, depuis votre Mac, depuis votre station Linux, depuis votre téléphone iOS ou Android ou depuis votre tablette iOS ou Android un SSO vers les applications Cloud de l’entreprise. Ce SSO est possiblement basé sur différentes technologies (dans le backoffice), fédération d’identité, OpenID, Login/Mot de Passe, etc… Le tour de force réside dans différents aspects:

  • Le paramétrage se fait depuis Active Directory: Des GPOs et une MMC vont permettre de paramétrer les différentes options, les paramétrages peuvent aussi se réalisés coté du service Cloud et sont synchronisés entre le service Cloud et Active Directory: la désactivation d’un compte dans Active Directory désactivera l’ensemble des comptes utilisateurs dans les applications Cloud pour cette entreprise, bien utile en terme de sécurité !
  • La solution est extrêmement simple à installer: pas de serveur de fédération, pas de paramétrage complexe, pas de synchronisation d’utilisateur: il suffit d’installer un serveur Proxy dont le rôle est de synchroniser les information Active Directory vers un service Cloud Centrify basé sur Azure, le service Cloud Centrify fait le lien avec les applications SaaS – pas d’infrastructure complexe
  • Le service Cloud Centrify basé sur Azure permet de maintenir à jour les paramètres et le niveau de sécurité sur l’ensemble des devices, même si ils sont en dehors de l’entreprise, dès que ceux-ci se connectent à Internet et donc à Azure

Centrify_for_SaaS

Coté Tablette ou Téléphone, une simple application téléchargée depuis le store ou un navigateur, permettent à l’utilisateur de réaliser toutes les opérations: accès aux applications en SSO, mise à jour des informations utilisateurs, réinitialisation de mot de mot de passe, blocage d’un device perdu ou volé, etc…

Centrify propose une version gratuite de sa solution, la version DirectControl for SaaS, pleinement fonctionnelle, sans limitation dans le temps ou dans le nombre de devices gérés: certaines fonctions pour les grandes entreprise seront uniquement présentes dans la version payante qui sortira en Q2 2013.

Mes premiers tests sur la version express de la solution sont plus que concluants: ce produit est génial – De plus, il fonctionne parfaitement avec Office365, que l’instance Office365 soit paramétrée en mode Login/Password ou en mode Fédération, sauf qu’il n’y pas besoin d’ADFS ou de DirSync V2 !

Enfin, je vous conseille vivement de regarder cette vidéo de démonstration de 5 minutes qui vous donnera une meilleure idée de la solution depuis un PC ou une Tablette:

 

 

 

Sortie de Oracle Identity Management 11g Release 2

  La version Oracle Identity Management 11g Release 2 vient de sortir sur le marché. cette nouvelle version apporte principalement des avancées dans les quatre domaines suivants:

  • Gestion des privilèges multi-plateformes: sur cette partie, Oracle tente de rattraper son retard sur les solutions connues et reconnues du marché chez Quest, Centrify ou Avecto
  • Sécurisation de l’authentification sur les plateformes mobiles: A nouveau, Oracle me semble bien en retard par rapport aux produits présents sur le marché depuis plus d’un an chez Airwatch, MobileIron ou Centrify
  • Nouveautés sur la partie Fédération, et notamment dans les scénarios de SSO vers les applications en Cloud public telles que SalesForce, GoogleApps, etc…
  • Des nouveautés sur la virtualisation d’attributs dans Oracle Directory Services

Plus d’informations sur le site d’Oracle

Oracle fait la promotion du SSO via une vidéo

Oracle a réalisé un film promotionnel sur le thème du SSO visant via le biais de l’humour à présenter Oracle Enterprise Single Sign On Suite. Pour rappel il s’agit ici des solutions développées par Oracle et de l’intégration des solutions PassLogix rachetées par Oracle en Février 2011. Malheureusement les solutions de SUN, et notamment les solutions Open Source telle que OpenSSO ayant été mise de côté.

 

Vidéo: comprendre le modèle de sécurité des « claims » et de la fédération avec Microsoft SharePoint 2010

Ayant travaillé dernièrement sur des spécifications fonctionnelles liées aux différentes méthodes de publication et d’authentification sur SharePoint 2010,  je me suis rendu compte à quel point les notions de Fédération et de publications web fédérées étaient encore réellement obscures pour la majorité de mes interlocuteurs. J’ai donc décidé de prochainement réaliser quelques articles un peu plus techniques et moins stratégiques sur le sujet de la Fédération, notamment dans le cadre de l’utilisation des produits Microsoft: SharePoint, Lync, Office365, UAG, etc…

En attendant, je vous invite à visualiser une vidéo postée hier sur Channel19, la chaine vidéo MSDN généraliste. Cette courte vidéo reprend les éléments de base et vous présente en moins de 20 minutes ce que vous devez savoir pour bien comprendre le principe de l’utilisation des claims avec SharePoint 2010: