SMP 3 Security – SAML2 Authentication

SMP 3 Security – Configuration of SAML2 Authentication

Topics

• SAML Process Flow with SMP
• SMP SAML2 Configuration
• Testing SAML Authentication with SMP3
  • Testing SAML Authentication in Browser REST Client
• Backend Connection

Introduction

SAML support in SMP3 got already introduced in SMP 3 SP05 as a new feature. In the last months I was involved in several customer projects were we implemented SAML authentication.

By using SAML you have a great flexibility, because you can use any authentication method (as long as your IDP is supporting it) independent of SMP’s predefined security modules.

Let’s start with a small introduction to SAML. The Security Assertion Markup Language is a defined standard way for authenticating clients. The authentication is performed by a system called “Identity Provider” (IdP). This system is creating “assertion tickets” for the concrete resources the client is requesting. These resource servers are named “Service Providers” (SP). One assertion ticket is always valid for one service provider.

When we now request some resources from a Service Provider we have to authenticate against the IdP first. Because the Service Provider is not authenticating the user (it is “only” validating the assertion ticket coming from IdP), the authentication method is not limited to security mechanism provided by this Service Provider.

SAML Process Flow with SMP

The SAP Mobile Platform is your Service Provider and is forwarding the user to the IdP for authentication. All communication is performed always between client and SP and between client and IdP, thus there is no direct connection between your SMP and your IdP required. But the client (e.g. the mobile app) needs to have access to the SMP server as well as to the Identity Provider.

Following picture should give a basic idea of the client/server communication which is performed if SAML is used as authentication provider.

Description of Steps

1) Connecting to SMP

The mobile device is connecting to SMP. It does not matter if this is a AppCID registration (first time app execution) or a request to get (or update) data from backend.

2) Redirecting to IdP

SMP checks the incoming request and searches for a valid session. (A SMP session is identified by cookies X-SMP-SESSID and X-SMP-SESSIDSSO). Because no session is identified, SMP is calling the associated Security Profile. The security profile contains the SAML2 Authentication Provider. SMP is now sending a Redirect (to specified IdP address) to the mobile app. Beside this Redirect the response contains the SAMLRequest object (base64 encoded)

3) Asking IdP for Authentication

The mobile app is following the redirect and thus contacting the IdP and providing the SAMLRequest.

4) Responding to AuthRequest

The IdP checks if there is already a valid security (IdP) session. If yes then there would be no need for the client to authenticate again. If no, IdP will ask the user for identifying and authenticating himself.

5) Identifying and Authenticating the user

This step depends on the security setup on the IdP. Oftne the IdP is displaying a webpage where the user has to authenticate, e.g. by supplying user and password, or a certificate. This step can also be repeated, e.g. if the IdP requests multi factor authentication. So in a first step user has to provide user and password and in a next step a One Time Password (OTP) that got send to the user by using another communication channel (e.g. SMS).

6) Responding with SAMLResponse

The final response from IdP contains the SAMLResponse object. One part of this SAMLResponse contains the SAML Assertion Ticket and also the destination service provider address is mentioned here.

7) Posting SAMLReponse to SMP

The mobile app is using the received destination url to send a POST request to sMP (to address =”https://<smp3server : https port>/SAML2/SSO/POST”). SMP’s Assertion Consumer Service is listening on this address for the SAML response.

8) Redireting to originally requested resource

The Assertion Consumer Service is validating the SAMLResponse (check if siganture of IdP is trusted), will then create a new SMP session and send a last redirect to the mobile app. This redirect is pointing to the originally requested resource (from step 1)

9) Calling the originally requested resource

Same request than in step 1 gets sent again, but this time the session information (SMP session cookies) are attached.

10) SMP is returning the requested data

SMP Session check is successful and thus SMP will return the requested resource

SMP SAML2 Configuration

• Generate a Security Provider key pair in Management Cockpit.
• Use „Generate Key Pair“ functionality in Cockpit
• Choose a unique Local Provider Name for your SMP (Name of Service Provider)
• The base url is the hostname and port of the SMP3 load balancer or SMP server

Your SMP server is serving as Local Service Provider.

Click on Get Metadata to receive the metadata document which has to be imported into the IdP…

NOTE: This local SP metadata will need to be imported and configured to the IDP. This will have to be done for each unique SMP installation.

In tab Trusted Identity Provider click on „New“ and import your IdP metadata document. This is an XML file that you can receive from your IdP.

Create a new security profile and add SAML2 as Authentication Provider

Note: The Identity Provider Name must match the Trusted Identity Provider name (configured in last step)

Testing SAML Authentication with SMP3

SSOCircle is providing a free IDP that can be used to test SMP’s SAML flow..

1. Go to https://idp.ssocircle.com/sso/UI/Login?gx_charset=UTF-8 and register
2. Login or Register
3. Choose Manage Metadata > SSOCircle Public IDP Metadata.
4. Save IDP metadata as xml file
5. Import IDP metadata into Management Cockpit > Settings > SAML > Trusted IDP
6. Export SMP Service Provider metadata (Settings > SAML > Local Service Provider > Get Metadata)
7. In SSOcircle Metadata webpage click on „Add new Service Provider“

8. Create new app in Management Cockpit and assign (new) SAML security provider

(where Authentication Provider set to SAML2 with IDP Name: http://idp.ssocircle.com

See: http://scn.sap.com/docs/DOC-62329 for more information

Testing SAML Authentication in Browser REST Client

SAML can be tested inside the browser, because the browser understand the redirects and can keep cookies in his session…

We want to create a new registration on SMP server and want to use SAML (as described in the previous sections) for authentication.

Open registration URL in Chrome:

https://<smp3 server>:<https port>/odata/applications/latest/<appid>/Connections

Concrete sample url could look like this:
https://dewdfwssp2888.dhcp.wdf.sap.corp:8081/odata/applications/latest/com.sap.mit.samltest/Connections

This will redirect you to IdP Login Page.

After login, IDP will redirect back to SMP (you should see HTTP 501)

Now we got a SMP session already, because we did not send a POST Request to SMP, SMP responds here with an HTTP501. So let us send a concrete POST request from a REST client. Because we now have a SMP3 session we should be able to create a new registration.

Open a REST client (e.g. POSTMAN) and send the POST registration request (because we have now a security context/session there is no need to provide any credentials and SMP server should response with HTTP 201)

POST: https://<smp3 server>:<https port>/odata/applications/latest/<app id>/Connections

Header:

Content-Type: application/json

Body:

{“DeviceType”:”Android”}

You are now successful onboarded with SMP by using SAML…

Backend Connection

When choosing SAML for authentication you might also have to think about a single sign on solution for connecting to the backend. Because of the large diversity of backend systems there is no solution available that is working for every backend.

Possible SSO scenarios (especially in connection with SAML) are:

• Kerberos / SPNEGO
• Principal Propagation
  (introduced in SP05)
  Described e.g. in this blog post:
  SMP 3 Security – Principal Propagation
• SAPSSO2
  (introduced in SP08)
  Described e.g. in this blog post:
  SMP 3 Security – SAPSSO2