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

Create an oData service from CDS

This blog is about how to create an oData service from a CDS View. The code and example follow closely SAP Help documentation and the included example on this topic:

I only cut the documentation overhead and make the information available in a single blog. As you can see in the above two links, the task consists of 2 steps:

  1. Create CDS View
  2. Expose OData service

For the example, I used NW ABAP 7.52 Developer Edition and ABAP in Eclipse (ADT) tools. If you have a “real” SAP NW ABAP System available, you may also implement the sample service there.

Create CDS Data Source

In ADT, create a new CDS Data Definition.

Name: ZDEMO_CDS_SalesOrderItem
Description: List Reporting for Sales Order Item

Click on next to go throught the wizard.

Paste the following code in the new created file: https://github.com/tobiashofmann/cds_sample_service/blob/master/ZDEMO_CDS_SalesOrderItem

@AbapCatalog.sqlViewName: 'ZDEMO_SOI_001'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'List Reporting for Sales Order Item'
@OData.publish: true

define view ZDEMO_CDS_SalesOrderItem as select from SEPM_I_SalesOrderItem_E as Item {
  key Item.SalesOrder as SalesOrderID,
  key Item.SalesOrderItem as ItemPosition,
  Item._SalesOrder._Customer.CompanyName as CompanyName,
  Item.Product as Product,
  @Semantics.currencyCode: true
  Item.TransactionCurrency as CurrencyCode,
  @Semantics.amount.currencyCode: 'CurrencyCode'
  Item.GrossAmountInTransacCurrency as GrossAmount,
  @Semantics.amount.currencyCode: 'CurrencyCode'
  Item.NetAmountInTransactionCurrency as NetAmount,
  @Semantics.amount.currencyCode: 'CurrencyCode'
  Item.TaxAmountInTransactionCurrency as TaxAmount,
  Item.ProductAvailabilityStatus as ProductAvailabilityStatus
}

Save and activate the CDS View.

Activate OData Service

The above created a CDS Data Definition and when activating, some magic happened. What is missing is to activate the OData service. ADT won’t do this for you, this needs to be done manually in the Gateway System.

Tx: /n/IWFND/MAINT_SERVICE

Click on Add Service

Search for services in the local system.

System Alias: LOCAL
Technical Service Name: ZDEMO_CDS_SALESORDERITEM_CDS

Click on Get Services

The CDS Service is shown.

Select the service and click on Add selected Services

Add service dialog.

Package Assignment: $TMP (click on Local Object)

Test service

After performing the above steps, the CDS View is implemented and the OData service exposing the data is activate and can be used. You may now test the service to see if everything is working as expected.

Tx: /n/IWFND/MAINT_SERVICE
Select the service: ZDEMO_CDS_SALESORDERITEM_CDS

Click on SAP Gateway Client. To test the service, use the URL:

/sap/opu/odata/sap/ZDEMO_CDS_SALESORDERITEM_CDS/$metadata

Available entity sets can be seen by clicking on EntitySets.

Available options by clicking on Add URI Option

The see the top 2 results in json, the URL is:

/sap/opu/odata/sap/ZDEMO_CDS_SALESORDERITEM_CDS/ZDEMO_CDS_SalesOrderItem?$top=2&$format=json

Let the world know

Gateway: Set Profile Parameters

Profile parameter to be set in the Gateway and BEP (backend) system. SAP Help. These parameters are set in the DEFAULT profile SAP Help

  • login/accept_sso2_ticket = 1
  • login/create_sso2_ticket = 1

Transaction: RZ10

If the transaction is called for the 1st time, a profile must be generated first. We want to adjust the default profile, therefore a default profile must be cerated. Enter the profile meta data

  • Profile: DEFAULT
  • Version: 1

Select Create

Select Copy

Back on RZ10 main screen, select Import

Select the base profile to be imported.

Profile: DEFAULT.2.PFL

Select Copy

Click OK. New profile is now saved and activated.

Select Extended Maintenance and then Change.

A list of parameters is shown.

Create a new parameter: . Search for

  • Parameter name: login/accept_sso2_ticket
  • Parameter value: 1

Select copy If it worked, status message indicates:

Do the same for parameter login/create_sso2_ticket

  • Parameter name: login/create_sso2_ticket
  • Parameter value: 2

Result

Two new parameters are added to the profile:

Let the world know

Activate RMTSAMPLEFLIGHT service

After installing a SAP NetWeaver Gateway system, you’ll want to play around with a OData service. One option is to create everything from scratch; another option is to use a sample service that serves as a basis for learning. SAP NetWeaver ABAP comes with the flight sample, and to no surprise, SAP Gateway comes with a sample OData service based on the flight sample. To maintain a service, transaction /IWFND/MAINT_SERVICE is used. It shows a list of available services:

Adding the service

After a fresh SAP Gateway installation, the flight sample service won’t be listed. The service is already installed, but is not visible in the service catalog. To add it, select the Add Service option: This brings up the Add Selected Services screen.

The get a list of services, first inform the system alias. In my case, I created before in SPRO an alias named GWD for my Gateway system.

Then, click on Get Services: . The brings up the list of services available in the system

The OData service for the flight data is RMTSAMPLEFLIGHT or RMTSAMPLEFLIGHT_2. Select the services you want to add and click on Add Selected Services.

Confirm the following dialog

This will load the service. After everything was done successfully, you’ll hopefully see the following information:

Back at the Activate and Maintain Services transaction shows that the RMTSAMPLEFLIGHT service is added.

Test the service

Click on the service name. This will change the lower section of the screen.

To test the service, click on Gateway Client: . This will open the SAP NetWeaver Gateway Client.

Note that in the Request URI field the service URI is already inserted: /sap/opu/odata/IWFND/RMTSAMPLEFLIGHT/?$format=xml

To see of the service works, just execute a GET request. This should bring back the service description.

Service document

Metadata document

Collection

To retrieve data from a specific collection, click on Entity Sets: . Select an Entity Set (Collection)

This will set the URI parameter accordingly.

Specific flight

The information returned by the entity set can be used to retrieve the information of a specific flight. Part of the returned XML is an entity, that contains an URL like this:

/sap/opu/odata/IWFND/RMTSAMPLEFLIGHT/FlightCollection(carrid=’AA’,connid=’0017′,fldate=datetime’2014-10-29T00%3A00%3A00′)

Copy & paste this URL in the URI field.

Let the world know