From legacy to cloud native

In this blog I’ll show how to bring a legacy solution to the cloud. As an example, I’ll use a user management solution based on a 3-tier application: backend, middleware, frontend. Through a series of blogs, I will bring this solution from a legacy, on premise setup to the cloud. During the migration, the solution will go through various migration steps:

  • First, the components will be Dockerized
  • A solution in form of a Docker compose setup will be created
  • In a next step, it will be transformed to a Kubernetes (minikube) application
  • Then deployed to the Azure K8s service and
  • Finally transformed to an Azure cloud native application

The solution is very simple: it’s an app for user management. The backend part is a traditional SQL database: PostgreSQL. The middleware is following the API first principle. API is defined using OpenAPI and developed using Swagger. The implementation is done by Node.js and Express. The frontend is – of course – developed using the most advanced and developer friendly JavaScript framework available: OpenUI5.

So far, this blog is a placeholder for the individual blogs that will show how the solution goes through these migration phases. In the next months, this blog will be updated until the final application is running in the cloud.

Let the world know

SAML 2.0 Configuration with SAP Gateway as SP and Keycloak as IdP

This is the introduction blog on how to activate SAML 2.0 based logon on SAP NetWeaver ABAP systems. The example configuration shown here is using SAP Gateway. It is the same procedure for any SAP NetWeaver ABAP system that allows SAML 2.0 logons. The system used while writing the blog content was the Gateway Developer Edition that can be downloaded for free from SAP. It is also known as NPL. You can reproduce the configuration by using the Gateway System and Keycloak.

On a high level architecture, Keycloak is the SAML 2.0 Identity Provier (IdP), and SAP Gateway is the SAML 2.0 Service Provider (SP). Gateway provides the service a user wants to access, like WebGui, and Keycloak provides the user information. The user needs to authenticate against Keycloak to be able to log on to Gateway.

The configuration steps needed are:

SAP Gateway

  1. Activate SAML 2.0 Service Provider (SP)

Keycloak

  1. Installation of Keycloak via Docker
  2. Create a SAML 2.0 Client in Keycloak
  3. Download SAML 2.0 IdP Metadata from Keycloak

SAP Gateway

  1. Create Trust between IdP and SP
  2. Configure IdP NameID and activate IdP
  3. Activate SAML Logon for SAP WebGui

In Keycloak you can configure realms. Each realm is independent and has its own configuration. I recommend creating a realm named SAML for the above tasks. Later you can add a new realm and add there a new configuration for SAP Gateway and Keycloak like OAuth 2.0 or a different SAML 2.0 configuration, without having to reconfigure your existing realm.

Additional Links

Let the world know

Die SAP Fiori Story auf den DSAG Technologietagen 2020

Die DSAG Technologietage 2020 in Mannheim sind jetzt schon – leider – seit ein paar Tagen beendet. Genug Zeit die Menge an Informationen etwas im Rückblick und Abstand betrachten zu können. Mein Fokus in diesem Blog ist die SAP Fiori Story und wie sie an den zwei Tagen erzählt wurde.

Fiori 3 wurde schon direkt auf der Keynote von Jürgen Müller aufgegriffen: als die Lösung um die unterschiedlichen UI Konzepte der verschiedenen SAP Anwendungen zu vereinheitlichen.

Bild 1: Fiori 3 in der Keynote.

Eine der Kernfunktionen von Fiori 3 war damit schon auf der Keynote prominent platziert: die verschiedenen SAP Produkte und die Fiori Launchpads aufeinander abzustimmen. Hier ist Fiori 3 das übergreifende Thema, das die Produkte ohne Sollbruchstelle dem Benutzer präsentiert. Dieser Aspekt wurde auch in anderen Vorträgen hervorgehoben.

Wer sich schon etwas länger mit Fiori beschäftigt, dem dürfte diese Vereinheitlichung als Visual Harmonization in Erinnerung geblieben sein: ein Design (damals Belize) das man über die WebGui Transaktionen stülpte um dann eine fiorisierte Anwendung zu bekommen. Kleine Erinnerungshilfe: es kam nicht sehr gut an. Zumindest das sollte sich nicht wiederholen. Die Apps sollen mehr als nur ein Design verwenden um eine einheitliche UI zu liefern. Die UI Controls werden aufeinander angepasst oder verwenden die gleiche UI5 control.

Bild 2: Fiori 3 Roadmap

Die Folie in Bild zeigt auch wie die unterschiedlichen Launchpads unter einem Design auftreten werden. Der Vorteil von Fiori 3 ist hier gleichzeitig auch das Hauptproblem: Fiori 3 ist die Lösung zu einem Problem, das die SAP selbst geschaffen hat. Wer keine unterschiedlichen SAP Produkte mit unterschiedlichen Launchpads im Einsatz hat, was für Nutzen bringt Fiori 3 dann? Was ist mit Fiori 3 auf Smartphones? (es gab eine fast absolute Abwesenheit von SAP Mobile Themen) Wie kann man nicht-SAP Anwendungen integrieren?

Das wäre jetzt ein roter Faden, an dem sich die Fiori Story an den 2 Tagen entlang hätte entwickeln können. Diese Frage nach dem generellen Nutzen von Fiori 3 wurde auf den DSAG TT vage bis nicht beantwortet. Es sieht so aus als würde Fiori 3 auf zu vielen Hochzeiten tanzen.

Aus einer Veranstaltung konnte man mitnehmen, das Fiori 3 erst in Q3 2020 in S/4HANA Cloud kommt, dann ist Fiori 3 schon teilweise in S/4HANA heute verfügbar, dann ist Fiori 3 nur der Quartz Theme den man heute schon benutzen kann. Zu Spaces und Pages gab es Folien markiert mit Lab Previews, obwohl diese eine schmerzlich vermisste SAP Portal Funktion bieten könnte. Zur Fiori Entwicklung mit SAPUI5 oder Fiori Elements war eigentlich nichts in Erfahrung zu bringen, hier ist Fiori 3 wohl nur das Quartz Theme. Gleichzeitig bei den Kundenvorträgen: hier ist Fiori (einfach Fiori, ohne 3) die Lösung um Mehrwert für das Business zu liefern.

Das kann interessant werden, denn während SAP mit Fiori 3 sich selbst beschäftigt, liefern parallel Kunden und Partner Mehrwert für die Anwender. Und während SAP sich für ein neues Fiori Launchpad auf die Schultern klopft, kämpfen die Anwender mit dem Einsatz von Fiori vor Ort. Hier fängt an etwas auseinander zu driften.

Für die Entwickler und Early-Adopters des Fiori Frontend Servers wurde FES 6.0 vorgestellt, gleichzeitig aber sein Ende verkündigt da der Nachfolger Ende 2020 kommt und FES 6.0 nicht migriert werden kann. Dafür mit Support bis 2027. Aber mit der Möglichkeit des Extended Supports bis 2030? Als Alternative wird das SCP Central Fiori Launchpad vorgestellt, dass aber beim Funktionsumfang noch etwas Zeit braucht. Davon abgesehen, dass auch hier wieder ein SAP eigenes Problem gelöst wird.

Als eines der Ziele von Fiori 3 wurde von Jahr(en) eine vereinfachte und einheitliche Integration der Fiori Apps angekündigt. Die Idee, das Apps aus anderen FLPs nahtlos integriert werden können ist noch da.

Ab wann dies gelebte Realität wird? Ob es mehr ist als dynamische Kacheln oder Links? In früheren Lab Previews wurde schon die Idee gezeigt direkt mit den Anwendungen interagieren zu können: Freigabe von Workflow, weitere Information zu einer Bestellung, etc. Bleibt die transparente Integration von Fiori Apps nur ein Teaser? In anderen Vorträgen herrschte hier mehr Realismus, als dort die Spaces und Pages als Lösung für die Integration angepriesen wurde. Aber wie soll die Integration jetzt am besten erfolgen? Integration der App oder Absprung auf ein FLP? Jetzt wird wieder eine zentrale Inbox als Heilsbringer angepriesen. Beispiele wie Time Sheet Extension App mit Microsoft zeigen hier besser eine durchdachte Integration auf.

Es wurden mehrere neue Tools für die Aktivierung und Verwaltung von Fiori Apps vorgestellt. An sich sind dies gute Neuigkeiten, da der Aufwand eine App zu aktivieren und bereitzustellen doch immer noch recht hoch ist. Die Reaktionen des Publikums bei der Vorführung der neuen Verwaltungstools machte jedoch auch eines deutlich: am Bedarf vorbeigeplant. Die App, die alle wollen erlaubt es von der Fiori Apps Library heraus eine App zu selektieren und per Klick zu installieren, aktivieren und einer Rolle hinzuzufügen. In der Realität wird man sich weiter um Intents, Targets, Gruppen und Kataloge sowie der Rollenzuordnung kümmern dürfen. Dafür hat man aber jetzt mehrere Apps / Transaktionen zur Verfügung.

Damit bleibt am Ende von 2 Tagen neben vielen Präsentation und dem Wissen das Fiori 3 aktiv entwickelt wird einige folgende Fragen

  • Wann kommt Fiori 3 in welchen Umfang in welchem Produkt? Oder: wenn ich S4/HANA 20xx einsetze, was bekomme ich?
  • Welche Probleme der Anwender löst Fiori 3 die die SAP nicht selbst verursacht hat?
  • Was ist der konkrete Mehrwert der neuen Fiori Landschaft und dem Central Fiori Launchpad in der Cloud?
  • Wann kommt die 1-klick Aktivierung von Fiori Apps?
  • Was bedeutet Fiori 3 als Entwickler? Ist es nur das Design? Die SAPUI5 Bibliothek?
  • Ist Fiori 3 nur für SAP Apps?
  • Was wurde aus SAP Mobile – SCPms und den Fiori for iOS / Android? Spielen die keine Rolle für Fiori 3?
  • Ready-to-run Fiori Apps. So in etwas was es mal in Form der Sybase Apps gab. Auswahl einer Fiori App, und kann direkt auf dem Desktop und Smartphone verwendet werden (inkl. push, offline). Diese Idee gab es mal, damals als SMP3 und Fiori noch neu war, wurde leider still und heimlich begraben.

Nach etlichen Gesprächen mit Teilnehmern kommt man zur Meinung das die SAP bei Fiori 3 noch in einer Selbstfindungsphase ist. Grundsätzlich nichts Falsches von der SAP. Doch dabei bleibt der Eindruck bestehen, dass selbst die Denker und Entscheider nicht wissen was Fiori 3 irgendwann mal bedeuten soll. Man meinte das man so manchmal die SAP sich selbst vorstellen muss: linke Hand, sag Hallo zur rechten Hand, rechte Hand, sag Hallo zur linken Hand. Auch in lockerer Runde kam mehrmals die Frage auf ob der Anwender im Zentrum steht oder doch nicht die einzelnen SAP Abteilungen in Konkurrenz untereinander. Man hatte zwischen den Vorträgen den Eindruck das SAP hier selbst zum ersten Mal miteinander kommuniziert. Als würden die Entwicklung und Design sich nicht 100% unterstützen.

Vielleicht würde ein öffentlich zugängliches SAP System auf dem die Fiori 3 Story live erlebt werden kann helfen? Ein System in dem man 360° die einzelnen Aspekte einzeln beleuchten kann. Für Endanwender, Entwickler, Architekten, Administratoren, etc. Wo man über Tutorials den Tag im Leben eines Anwenders durchspielt. Problem, Analyse, Auswahl und Aktivierung einer Fiori App, Erweiterung, Anbindung und dann den Inhalt über Conversational AI, Inbox oder mobilen App verarbeiten.

Let the world know

SAP Gateway – Activate and test SAML 2.0 Logon with SAP WebGui for HTML

After establishing the trust between the SAML 2.0 IdP and SP and activating the IdP in SAP Gateway, the ABAP system is configured for SAML 2.0 logons. An easy way to test if SAML 2.0 is working is to log on to SAP WebGui for HTML. This is a standard service delivered always. Therefore, it is also available for NPL.

The default logon procedure for ICF is to check if SAML 2.0 is enabled and then use SAML 2.0. Remember that this means that after activating the trusted SAML 2.0 IdP in transaction SAML2, the default logon method changed: your users are now seeing the SAML 2.0 logon screen.

More information on logon procedures:

SAP Help: Maintaining Logon Procedures

Activate WebGui

In case WebGui is not already activated, activate it.

Tx: SICF
Service: /sap/bc/gui/sap/its/webgui

Activate service

Call service: http://vhcalnplci:8000/sap/bc/gui/sap/its/webgui?sap-client=001&sap-language=EN

You should see the NetWeaver logon screen and the option to select the SAML 2.0 IdP.

Click on Continue will start the SAML 2.0 authentication flow.

http://localhost:8080/auth/realms/SAML/protocol/saml?SAMLRequest=fZHNasMwEIRfxeiuSHJC7C6xITQUDGkITemhN2FviECWXK3cn7ev7NDSHtrrsPPNjLQh3dsBtmO8uAd8GZFi1uwqdpKllHlRFFyuijVX2GleLsuOF2vsuqXOV2uVs%2BwJAxnvKpYvJMsaohEbR1G7mCSpbrhSPFePagXLHFTxzLJdSjBOx9l1iXEAIaxvtb14ilCmWKFTGRFQ257EaXu%2FF0Pw0bfeiqksy%2B58aHFuXLGztoRT8lETmVf8Vt576wjmdRUbgwOvyRA43SNBbGECQ2oNX3BWb6ZrmEeEH%2F7%2F7SkWw7SG1YfjXkq1ET8wV%2BYAh%2BRrdkdvTfsx9e91%2FBurFmpWTMfP8ymMjgZszdlgx7Kttf7tNr1PTGtjGJGJ%2Bhr6%2Bx%2FrTw%3D%3D&RelayState=oucqyqqsxxxoquxworedaoytydoxweddtasuwrs&SigAlg=http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23rsa-sha1&Signature=Qt%2BXguQo9LJzBBM%2BjsE%2F7Dut7%2FPk38AEqzmHHTlGfy2s9uOXni%2BhZU7cEFENgSQ1NXCvoJy3kTXQTO0%2BhPNQ%2FKy%2Bo8Ht%2BIxDXgKHgeaq2mvTwPVDuJ0lOQnaOKCYam0N0sMCBKkjZQk7686lCw0bYdmdX5lvkYXUXpKM1C941stioA8mk5kvYlR8xQwHw%2B1E138GRxmJIW1qUvR2Nu42%2FY%2BnVvrSmAlHn9faXEk9fdXYdLdf4%2Fy6G1A5qmY89il0VatEZzjBJ3mYlLtmuTln86QVnTy33ejjGGbHT05aWIz4NrXzpVBjDUgzdvD3mP3PgjOayDv78Wsed3iYmgQIKA%3D%3D

Keycloak is called. Note the realm SAML: auth/realms/SAML/protocol/saml

A SAMLRequest is added to the URL, as the IdP is configured for HTTP Redirect.

SAMLRequest=fZHNasMwEIRfxeiuSHJC7C6xITQUDGkITemhN2FviECWXK3cn7ev7NDSHtrrsPPNjLQh3dsBtmO8uAd8GZFi1uwqdpKllHlRFFyuijVX2GleLsuOF2vsuqXOV2uVs%2BwJAxnvKpYvJMsaohEbR1G7mCSpbrhSPFePagXLHFTxzLJdSjBOx9l1iXEAIaxvtb14ilCmWKFTGRFQ257EaXu%2FF0Pw0bfeiqksy%2B58aHFuXLGztoRT8lETmVf8Vt576wjmdRUbgwOvyRA43SNBbGECQ2oNX3BWb6ZrmEeEH%2F7%2F7SkWw7SG1YfjXkq1ET8wV%2BYAh%2BRrdkdvTfsx9e91%2FBurFmpWTMfP8ymMjgZszdlgx7Kttf7tNr1PTGtjGJGJ%2Bhr6%2Bx%2FrTw%3D%3D

The Redirect payload can be decoded.

<samlp:AuthnRequest ID="S08002777-0476-1eda-838d-76edd3a24612" Version="2.0" IssueInstant="2019-11-21T14:32:17Z" Destination="http://localhost:8080/auth/realms/SAML/protocol/saml" ForceAuthn="false" IsPassive="false" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">NPL001</saml:Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true"/></samlp:AuthnRequest>

The Keycloak logon page is shown.

Log in to Keycloak with your Keycloak username and password. The username must exist in the SAP system, as this is how the NameID property was configured.

Login.

Result

SAP WebGui for HTML opens.

Logon via SAML 2.0 works!

Let the world know

SAP Gateway – Configure NameID and activate trusted SAML 2.0 IdP

Current state is that a trust between Gateway as SP and Keycloak as IdP is established. While the previous step established the trust, the IdP is not enabled in SAP Gateway. Meaning that SAML2.0  logons are not possible. For this to work, the IdP must be enabled. Currently, enabling is not possible and will fail, as the NameID configuration is missing. NameID is needed to enable the mapping of the SAML 2.0 user ID to the SAP user ID (simplified).

Configure NameID

Tx: SAML2

Open the tab Trusted Providers. Click on Edit, then on tab Identity Federation. The list of configured supported nameID formats is empty.

Click Add.

Select unspecified. This maps the NameID property transmitted by SAML 2.0 IdP to the Logon ID of the SAP System. So, if the user has an account with ID tobias in Keycloak, this will be set as NameID. The user needs to have the user ID tobias in Gateway to be able to log on.

Save.

Activate IdP

Now you can activate the trusted IdP. Select the IdP entry in the list.

Click on Enable

Result

IdP is active.

Now users can use the IdP as their identity provider and log on in SAP Gateway.

Let the world know

Keycloak – Download SAML 2.0 IdP Metadata

As SAML 2.0 depends on trust, it is necessary to establish this trust by exchanging the metadata of the IdP and SP. When the SAML 2.0 client for Gateway (NPL001) was created, the metadata of the Gateway SP was important to Keycloak. In this step, the metadata of the IdP is exported from Keycloak to be able to import it to Gateway. This concludes the task of establishing a trust between SAP Gateway and Keycloak.

Download Keycloak IdP Metadata

Log on to Keycloak, select the realm and go to Realm Settings.

The SAML 2.0 IdP metadata download link can be found at Endpoints. Click on SAML 2.0 Identity Provider Metadata.

Alternatively, the IdP metadata can be downloaded directly from the descriptor URL.

<keylcoak server>/auth/realms/<REALM>/protocol/saml/descriptor

In my case, the URL to download the metadata is:

http://localhost:8080/auth/realms/SAML/protocol/saml/descriptor

Here you can see a sample metadata file. It is also available on my repo on GitLab.

<?xml version="1.0" encoding="UTF-8"?>
<!--
~ Copyright 2016 Red Hat, Inc. and/or its affiliates
~ and other contributors as indicated by the @author tags.
~
~ Licensed under the Apache License, Version 2.0 (the "License");
~ you may not use this file except in compliance with the License.
~ You may obtain a copy of the License at
~
~ http://www.apache.org/licenses/LICENSE-2.0
~
~ Unless required by applicable law or agreed to in writing, software
~ distributed under the License is distributed on an "AS IS" BASIS,
~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
~ See the License for the specific language governing permissions and
~ limitations under the License.
-->
<EntitiesDescriptor Name="urn:keycloak" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<EntityDescriptor entityID="http://localhost:8080/auth/realms/SAML">
<IDPSSODescriptor WantAuthnRequestsSigned="true"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<KeyDescriptor use="signing">
<dsig:KeyInfo>
<dsig:KeyName>_ui1xjX1skc3nEBmTVyQAsdHTNcuU_JOu5SS2Ifd8XQ</dsig:KeyName>
<dsig:X509Data>
<dsig:X509Certificate>MIIClzCCAX8CBgFub4ueGzANBgkqhkiG9w0BAQsFADAPMQ0wCwYDVQQDDARTQU1MMB4XDTE5MTExNTE0NDkxMVoXDTI5MTExNTE0NTA1MVowDzENMAsGA1UEAwwEU0FNTDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOYhrefNGcAqMFDEG06GxSpc/cwRUkKrN/D4/i83w6AlWz0hBqBLoGCHP30b5jX9674B7b9OaP/9dLi7p+V61Mb7lDRrIAtXo7FHRflcMVBWTBF6X3ztYliIY2liDv2GAZudbGTwTNdq+gZmdFyoJ/gvDaCW527ltbRSYhGXFZgBPNqrFxiP4FMKGtQ8tbzv0Rxt4Ez7pqAK+Kh7f3zKGwk/7fvENKrrfzHY4XoHmNBpErUeoaE6wcW5EX/fJe37VS7AyKd6jHaDa3nvvrFREUOBceqtmIIHnv/SZExzIXz/jQWQx9lGaqiuUCQ4G4dtGSTCo+izqRvOxm1pcwMh+T8CAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAyGnbodezduakIMI/SoxUX8W4PnIzPrBcirMYAnZOKql/Mp8pyDdWNun3Fjsd8A7X9R83mx3msgXGN0RPbgI5dEgWWWLZ4x+yYWURMk3W1zE/UaTRjf/hXNW5vbS4RE/MaPTHOaFRZjXoS2t3FNS4hRvncMrTL5JAWBabhqY+zwai/qXDaG9IyZIirJJp+PwX+u58phR1tbPSG+tHUIPJPICEyoczViVMbIJAJ0M5jTy2/W3+CPkO1BxCOeXvZAmeK9lwn3qbL+nHbiHYgUULAw4lcysDgT0ogZKj12cCxH4UsMo1hSb8ATy+5mjYUlKSzQTNBGcbY/glKM1SQa3YyA==</dsig:X509Certificate>
</dsig:X509Data>
</dsig:KeyInfo>
</KeyDescriptor>
<SingleLogoutService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="http://localhost:8080/auth/realms/SAML/protocol/saml" />
<SingleLogoutService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="http://localhost:8080/auth/realms/SAML/protocol/saml" />
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="http://localhost:8080/auth/realms/SAML/protocol/saml" />
<SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="http://localhost:8080/auth/realms/SAML/protocol/saml" />
<SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
Location="http://localhost:8080/auth/realms/SAML/protocol/saml" />
</IDPSSODescriptor>
</EntityDescriptor>
</EntitiesDescriptor>
Let the world know

Keycloak – Create a SAML 2.0 Client

In this step a new SAML 2.0 client is created in Keycloak by importing the Gateway SP metadata. After activating and configuring SAML 2.0 in Gateway, a Service Provider (SP) was created. A metadata file for that SP is available at the saml2 Web Dynpro ABAP application. This metadata file needs to be exported and imported in Keycloak.

SAML 2.0 is based on trust between the IdP and SP. The trust is established by importing the metadata of the other endpoint. To establish the trust, you import the Keycloak IdP metadata in Gateway and the Gateway SP metadata in Keycloak.

Export Gateway SAML 2.0 Service Provider metadata

Tx: SAML2

Click on Metadata.

Select what to include in the metadata file. You can keep all options selected.

This will start the download of the SAP Gateway SAML 2.0 Service Provider metadata file. A sample metadata file for Gateway as SAML 2.0 SP can be found in my GitLab repository.

Add SAML 2.0 SP Client in Keycloak

Log in to Keycloak admin console and create a new client.

Client Protocol: saml
Import: import SP Metadata xml file

After uploading the previous obtained SAP Gateway SAML 2.0 SP metadata, the client information is automatically filled out.

Save

The SAML 2.0 client is created and the configuration screen is shown. Here you can configure the client to meet your specific requirements. Normally keeping most values at default should work. Some options you have to configure:

Name ID Format: username
Valid Redirect URIs: /*


Note

To be able to read the Assertions, do not encrypt them. That is: you as a person. In a secured environment, these should be encrypted.

Let the world know

Keycloak – Installation via Docker

Keycloak is an identity and access management solution. Among its list of supported authentication mechanisms are SAML 2.0 and OpenID Connect. It is open source and can be installed via Docker. This simplifies the installation and makes it easy to start with Keycloak. You only have to ensure pass a few configuration options to the Docker run command like port and user/password.

Run Keycloak

To run the latest version of Keycloak in Docker on port 8080 and to log on as a user defined user / password, run the following command. Replace <USERNAME> and <PASSWORD>.

docker run -p 8080:8080 -e KEYCLOAK_USER=<USERNAME> -e KEYCLOAK_PASSWORD=<PASSWORD> jboss/keycloak

With the above command, the port (local) Keycloak port 8080 is exposed on the localhost (laptop) at port 8080.

Login

Open Keycloak: http://localhost:8080 and access the Administration Console.

Log in to the admin console using the credentials provided at the docker run command.

Add test user

I am adding a test user for my scenario. My service provider is an SAP NetWeaver ABAP System (the developer edition, SID: NPL). Therefore, the name and id make it clear that it’s an ABAP system and user.

User id: abap
Name: ABAP NetWeaver

Let the world know

NGINX with RTMP on Raspberry Pi as a streaming server for OBS

Some time passed since I last wrote about OBS. In 2014, I started using OBS as a streaming solution for an event in Sao Paulo. I had quite some time to convince the co-organizers that streaming to an app and YouTube at the same time is a good idea, and that OBS is a good software for achieving this. In the end, my idea was accepted and SITSP video was captured with OBS and streamed through NGINX to YouTube. I even managed to provide live streaming to iPhone devices via an event app I wrote! OBS was not a very well-known software in 2014, and today it is like the de-facto standard for YouTubers when it comes to streaming game videos. 5+ years later and my architecture is still valid and an example of good solution architecture (and another proof of my visionary skills).

End of 2019 I decided to record videos: capture content of a computer with OBS and stream it to NGINX and recapture it with OBS or watch it with VLC. As my 2014 architecture is still valid, I decided to use my old solution architecture, review it and update it where necessary.

NGINX installation

Debian has a package for NGINX and RTMP. My Raspberry Pi is using the armv7l architecture (uname -m), and for that architecture, the RTMP module is available for Debian buster. If you are not on buster, consider upgrading Raspbian. It’s easier to install software via apt than having to compile it manually.

sudo apt-get update
sudo apt-get install libnginx-mod-rtmp

NGINX configuration

During the installation, NGINX will be started. This fails in my case, as I already have a web server (Apache) running. The port 80 is already used and NGINX startup fails. This is OK, as I do not want NGINX as a web server, just for RTMP and OBS.

To solve this “problem”, I’ll change NGINX configuration and deactivate the HTTP server listening on port 80. The NGINX configuration is located in directory /etc/nginx/.

  • The master configuration file is nginx.conf, where the http connector is configured.
  • The actual server is located in /etc/nginx/sites-enabled/default. Here the local server is configured to listen on port 80.

Deleting this symlink in sites-enabled will deactivate the localhost server and NGINX will start, as it now no longer tries to start a server on port 80 (that is already in use by Apache).

sudo rm sites-enabled/default
sudo systemctl start nginx.service
sudo systemctl status nginx.service

Status so far: NGINX is installed and running. Next task is to enable RTMP.

Enable RTMP

Create file rtmp.conf in /etc/nginx/. In this file will contain the RTMP server configuration. The configuration will make RTMP listen on port 1935 and expose a RTMP URL named live. This is the URL RTMP clients will connect to.

sudo vim rtmp.conf

Add content.

rtmp {
  server {
    listen 1935;
    chunk_size 4096;
    application live {
      live on;
      record off;
    }
  }
}

Enable RTMP configuration in NGINX. Change nginx.conf to load the above created rtmp.conf file. Add the following line at the top of the file to load the above created rtmp.conf file.

include /etc/nginx/rtmp.conf;

Start NGINX with RTMP

sudo systemctl stop nginx.service
sudo systemctl start nginx.service
sudo systemctl status nginx.service

This should restart NGINX and show no errors. To see if NGINX is now listening on port 1935 for RTMP, you can use netstat.

netstat -an | grep 1935

OBS configuration

After performing all the above tasks, NGINX with RTMP is up and running. Now you can connect OBS to it.

Server: rtmp://192.168.0.164:1935/live
Key: test

Start streaming in OBS. To see if it works, start VLC and connect to rtmp://192.168.0.164:1935/live/test The content OBS captures and streams should now be shown in VLC. There is a lag of a few seconds. This is normal, as the content is buffered.

Let the world know