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.

  • l'alternative est d'installer un portail SAP Java pouvant embarquer des composants de sécurité "spécifiques" (CAS Module par exemple), néanmoins avec beaucoup de difficultés; et pour l'équipe d'admin / infogérant SAP; la gestion d'une nouvelle instance souvent dédiée à ce rôle ; sans parler de l'impact coût réccurent sur l’hébergement dans le datacenter.
  • Malgré l'arrivée du composant Netweaver SSO (et son coût supplémentaire par utilisateur), l'interopérabilité hors Active Directory peut être compliqué si on sort des standards SAML et peut finalement représenter un long marathon avant d'arriver à une solution opérationnelle.

que faire

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 de SAP ABAP, comme le SAP Portal sait le faire, mais sans ce dernier composant.

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 le mécanisme opérationnel.

- 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 :

SSO-schema-archi-0.1

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

--
contactez moi pour relever un nouveau défi !