au gré des projets informatiques, le besoin du SSO a toujours été présent et le scénario peut devenir complexe pour s’intégrer dans les annuaires de l’entreprise et l’architecture technique présente.

En particulier sur SAP ABAP, à partir des versions Netweaver 7.3, le SAML 2 est proposé en standard. Il peut s’intégrer avec des solutions tierces AFDS, Open AM, Anywhere, CAS, … avec plus ou moins de facilité selon le standard proposé par les partenaires et plus précisément sur la capacité à échanger les metadonnées et certificats. Manuellement, le renseignent des options peu vite devenir déconcertant pour un sujet simple à la base.

Une alternative rapide et simple lorsque l’architecture du client n’impose pas de solutions tierces est le produit SAP Netweaver SSO. il repose sur des librairies sapcrypto côté serveur et SLC côté client. L’accès au SAPGUI et aux contenus web en SSO sera rapide et simple à mettre en place. Néanmoins, il faudra s’acquitter d’une redevance supplémentaire pour chaque licence utilisateur.

Avant l’apparition de cette librairie payante, l’accès au SAPGUI en SSO pouvait être mis à disposition gratuitement avec les anciennes (maintenant) librairies kerberos pour unix et windows : sncgss32.dll. cette solution est maintenant plus supporté par l’éditeur.

Une autre alternative consiste à installer une instance SAP Java pour bénéficier du socle d’authentification interopérable avec de nombreuses possibilités ; AD via Spnego, CAS (cas client), SAML v1, Ldap, …

mon expérience sur chaque projet est différente et chaque architecture est unique. il a fallu trouver des solutions pour chaque défi.

Récemment, j’ai eu l’opportunité de construire un Reverse proxy sous Apache avec la possibilité de générer des tickets MYSAPSSO pour les utilisateurs désirant se connecter à une instance ABAP. Cet élément de sécurité est souvent présent dans les architectures web pour protéger le backend SAP. Une présentation est disponible sur ce site.