The J2EE implementation in SAP NetWeaver offers several more enhanced authentication mechanisms beyond those available to the ABAP environment. Among these include the Security Assertion Markup Language (SAML).
SAML is an industry standard XML method for exchanging authentication and authorization data between security domains. If we use the example of SAP NetWeaver, the J2EE represents one security domain and an external authentication tool (3rd party VPN, LDAP, AD, etc.) represents another. SAML bridges the security and authentication gap between these disparate system landscapes.
Consider the scenario where a company might use a Virtual Private Network (VPN) solution to enable external access to the corporate network in order to provide enterprise applications to employees. The credentials on this particular VPN are likely authenticated against a dedicated user store completely unrelated to the SAP application security environment. It may even authenticate against a token or biometric method for additional security.
If this VPN mechanism supports the SAML standard, then it may be used to provide seamless authentication to the SAP J2EE which, in turn, can provide single-sign-on to all the backend SAP applications.
SAP NetWeaver 2004 and 2004s fully support SAML 1.0 and 1.1. While SAML 2.0 provides many more enhancements, it is not currently supported by SAP, although it should be in future support packs and releases of NetWeaver.
There are two methods of implementing SAML:
1.) Web Browser Artifact profile
A SAML Artifact is sent in a query from the identity provider (AD, for example) to the service provider (SAP J2EE in this case). Included in that query is a string with an HTTP redirect that the service provider responds to with a pre-defined authentication to the identity provider. This response authentication can be a basic login/password or client certificate, each of which would be configured by the administrator of the identity provider and service provider. Once this handshake is achieved between the two environments, the service provider will send a SOAP/HTTP request with the artifact. The identity provider responds with SAML assertion. This assertion is the key that the SAP J2EE uses to authenticate the user.
SAP only supports the Web Browser Artifact Profile method.
2.) Web Browser POST Profile
A second method sends the SAML assertion in the intitial request from the identity provider to the service provider. No handshake is returned as it is in the Web Browser Artifact Profile. As this method is not currently supported by SAP’s implementation of SAML, we will not discuss it further in this blog.
It is important to distinguish that the actual authentication to any SAML process is handled by the external service (identity provider). SAML is not a substitute for managing user authentication. It only passes authenticated users to the SAP J2EE.
Below is a diagram on how the SAML process works in a sample environment using an external authentication tool (the SAML identity provider) and an SAP J2EE running the NetWeaver Portal (SAML service provider)
User authenticates via external authentication tool such as a VPN, AD or an LDAP.
The authentication tool will provide a user with a link or immediate redirect to the Portal. The Portal is configured to accept SAML authentication via the logon modules in the J2EE Admin Tool. By attempting to access this resource, a SAML artifact with an HTTP redirect is sent to the service provider from the identity provider. NOTE: The HTTP redirect is provided by the administrator of the identity provider/authentication mechanism.
After the Portal receives the SAML artifact in step 2, it responds to the redirect URL with a SOAP message. The identity provider hosting that URL will be expecting the handshake authentication which may be a hard coded system user/password, or it can be a client certificate from the service provider that is trusted by the identity provider.
The identity provider verifies that the SOAP message sent in step 3 is a valid response to the artifact, and then sends back a SAML assertion to the service provider (SAP J2EE/Portal). The SAP J2EE receives the assertion and authenticates the user via the SAML Login module.
If the SAP J2EE/Portal is configured to issue logon tickets, all subsequent access to SAP backend applications, such as MySAP ERP, accepting Portal logon tickets will provide seamless single sign on.
Let’s now look at how to configure a basic SAML authentication in a NW04s Enterprise Portal environment. We will only discuss the successful authentication from an identity provider into the SAP Portal using SAML. This requires that you have already configured your SAP J2EE for SSL, because SAML information needs to be exchanged securely. You may, however, test and prototype in non SSL if you choose. Also, in this blog we will not cover the subsequent access of backend applications using logon tickets.
Before you begin to configure the SAP J2EE side, you must have the information from your identity provider available. In this example, we have an identity provider from Juniper Networks called Neoteris. This is one kind of VPN solution that enables external employee access via the internet through the DMZ. The required information from this security domain that we will need to configure the SAP J2EE is as follows:
SAML Assertion Service URL:
http://myvpn.abccompany.com/data-ws/saml.ws (the format of this URL may differ from one vendor to the next)
Web Service Authentication user:
Web service password:
NOTE: some SAML identity providers will allow client certificate authentication for the service.
With the above information, you may now go to configure the SAP J2EE SAML service. In this example, the user ID that is passed in the SAML assertion MUST be the same as the SAP user ID in the J2EE. There are options for mapping user IDs from one security domain to different user IDs in the SAP J2EE UME, but this requires creating your own mapping module and maintaining a mapping table. For more information on mapping, see the SAP Online Help topic Example SAML Mapping Module Used by the SAML Test Application
There are 4 main steps to configure SAML:
1.) Log into the J2EE Admin Tool and drill down to the SERVER
1a.) Expand the configurations folder to cluster data
1b.) Switch to edit mode and then scroll down to the Propertysheet: tcsecsaml~service-runtime
1c.) edit this property to allow startup-mode to be always
1d.) Restart the J2EE Server for this to take effect
2.) After restart, log back into the J2EE Admin tool and drill down to the SERVER
>SERVICES>CONFIGURATION ADAPTOR converts to hex 61626376706e31. But the SAML service requires a 20 byte hex string, so you must fill in the remaining 13 characters with zeros as double bytes(00).
3.) In the J2EE Admin tool, scroll down to SERVER
3a.) Expand the HTTP folder and then click the NEW button
3b.) Name your Destination after your Issuer (e.g. myvpn1.abccompany.com)
3c.) Change the Logon Data to “BASIC” and enter the Web Service Authentication Username and password configured on the identity provider
3d.) Click the “SAVE & TEST” button to insure a connection is made and the credentials are valid.
Often, due to network policies, ports may not be open between the SAP J2EE and the external identity provider, so this is the time you will be able to test connectivity and resolve any issues.
4.) In the J2EE Admin tool, scroll down to SERVER
4a.) Choose the BASIC template and click ADD NEW. Select the SAMLLoginModule
4b.) Give it a SUFFICIENT flag and the options:
We have configured the SAP J2EE with the necessary SAML configuration to enable authentication to the system from a 3rd party identity provider. Any J2EE application that utilizes the BASIC logon module template will first check for a SAML Assertion. Absent of this, it will then prompt the user for login/password (basic authentication).
You can test the successful configuration of SAML in a two steps:
1.) Login and authenticate to the external identity provider
2.) Configure the identity provider to either redirect to the SAP J2EE application URL (i.e. portal) or provide a link to that URL.
When you access that link(or are redirected), you should be passed directly into the SAP Portal! If you receive the logon page, check the security and default trace logs for specific errors.
741157 Accessing a Web resource with SAML
794794 Support of SAML 1.1 in the Browser/Artifact Profile
938808 SAML authentication fails if target URL has parameter
The details on SAML specifications are available from: http://www.oasis-open.org/committees/security