Lors des demandes d’étude de scénarios SSO dans un contexte SAP, j’ai souvent été confronté aux contraintes de compatibilité entre une instance ABAP et des plateformes tierces utilisant un protocole récent et trop souvent impossible à intégrer (ex : OpenID, CAS, SAML, Kerberos)
lorsque la demande devient insistante, il faut se creuser la tête et trouver des solutions innovantes.

Des solutions existes :

• Depuis la version 7.3 du socle Netweaver, le standard SAML2 est géré en standard pour les écrans web (Fiori, webdynpro, webgui)
• Les instances Java de SAP peuvent embarquer des composants de sécurité « spécifiques » (CAS Module par exemple)
• Le composant Netweaver SSO (et son coût supplémentaire par utilisateur) permettra d’utiliser les tickets Kerberos pour les écrans Web et le client lourd SAPGUI
• Malgré tout, il y a encore des challenges à relever pour certaines architectures hétérogènes où le ticket Kerberos n’est pas le jeton principal

Récemment, j’ai eu l’opportunité de répondre à un nouveau challenge nécessitant de déporter la gestion de la sécurité hors du socle SAP Netweaver, comme le SAP Portal peut le faire, mais sans ce dernier composant. Et avec une routine permettant de répondre à des besoins d’authentification de manière déportée sur un équipement non SAP.

Le challenge a été relevé et finalement m’a permis d’entrevoir encore quelques possibilités.

Voici le résultat obtenu après quelques efforts pour réaliser une maquette sous forme de toolbox :
– utilisation de la brique Apache HTTPD et des modules Kerberos ; SAP NWRFC SDK ; SAP CryptoLib ; PHP ( une alternative tomcat / java est possible )
=> au stade de conception on utilise Apache, mais le but final était le produit Axway API Management. et le portage a été très simple à faire, une fois que le mécanisme était opérationnel et reproductible.

– la brique Apache/PHP permet de manipuler les requêtes et les tickets reçus, et ceux à générer – génération des « SAP Logon Ticket » au format MYSAPSSO2 pour les utilisateurs
– mapping entre les utilisateurs externes (AD, OpenID, … provenant du jeton) et internes (SAP)
– et au final permettra d’accéder au webgui, personas, fiori, bex, web services, bo, …
– mais aussi d’ouvir le SAPGui (le client lourd) à l’aide de génration d’un SSF (SAP Shortcut File) en SSO

un petit schéma d’architecture :

Quid du SSO vers SAP HANA :

• plusieurs scénarios sont possibles : SPNEGO, SAML, SAP Logon ticket

Dans notre configuration, nous avons déjà le SAP Logon ticket, un simple trust de certificat entre ECC (STRUSTSSO2) et HANA (TRUST Manager) suffira à activer le SSO sur HANA.

—

FAQ :
A SAP Logon Ticket contains the following data

• Ticket Version
• Ticket Codepage
• User name
• Issuing System ID
• Issuing System Client
• Creation Time of the ticket
• Validity Period of the ticket
• Digital Signature using the private key of the issuing system
• Authentication scheme

A SAP Logon Ticket does not contain any passwords.

The SAP Logon Ticket has a lifetime that is configured in the system that creates the ticket