Sourcing UME and Network configuration

[Former Member]

Hi,

We are implementating a system landscape comprised of ERP 6, SRM 7, internal facing Portal 7.3, external facing Portal 7.4, SLC 1.0 and Sourcing v9.0. There are several other applications in the landscape which aren't relevant for this discussion.

1. In terms of landscape, we are considering splitting network into DMZ and internal network zones. There are a couple of options for distribution of Sourcing application.

• Supplier Portal, SLC-Sell side, and Sourcing + DB in DMZ
• Supplier Portal, SLC-Sell side, and external facing Sourcing application server in DMZ. Internal facing Sourcing application server + DB, along with Optimiser and AV Scan Engine in Internal network.

One question is that if option 2 is used which is preferred from security view point, what is the impact on network communication across the firewall? Since DB sits in internal network, will all authentication and authorisation requests go across the firewall?

2. One key objective is to securely allow Suppliers to log on to the Sourcing application. We intend to set up a Supplier Portal in the DMZ for this. The Portal will be used by Suppliers to register in SLC. Once approved, Suppliers will be created in Sourcing and SRM systems through transfer of business partner/contact person data.

There is a limitation in how we can configure our Supplier Portal UME. It must point to SLC-Sell side as the UME data source. As Supplier portal will be the point of entry for all Suppliers, we intend to use SLC-Sell side as the UME for Sourcing application as well. This way, Suppliers relevant for Sourcing can authenticate against SLC-Sell side through the Supplier Portal. We'll set up SSO between Portal, SLC, and Sourcing applications.

Once the business partner/contact person data is replicated from SLC to Sourcing, we need to carry out authorisation management on Sourcing system, unless there is a mechanim of using ABAP system for that purpose. Can ABAP system be used to manage authorisations of Sourcing application if Sourcing uses it as the UME data source?

3. I understand from SAP documentation that Sourcing UME can be configured such that it can use different UME configurations for external suppliers and internal buyers. In our case, our internal Portal connects with LDAP and local DB to authenticate users. Users are also maintained in CUA system and replicated across the landscape. There is no integration between CUA and LDAP at the moment so users are maintained twice. However, CUA has all internal users but LDAP has a subset. Users which are not in LDAP but are required on Portal are set up locally in the Portal DB.

For Internal buyer access to Sourcing, we intend to use URL iView for integrating Sourcing into Internal Portal. Once internal users have authenticated against LDAP/DB, they can then access the Sourcing application through the URL. However, for SSO, we have a challenge as these users don't exist in SLC UME, neither in Sourcing DB.

One of the solutions we are considering is to replicate internal users from CUA into SLC. This way, all user master will exist in SLC, which Sourcing can use for SSO.

My question is: is there any other way to achieve SSO between internal Portal and Sourcing application given the complexity of our scenario?

We have considered IdM but that will be a significant impact on the project. So that is not an option at the moment.

Any suggestions?

Regards,

Shehryar

[former_member89217]

Your second option is more typical.  The DB and buyside infrastructure on internal network whereas the sell side infrastructure in a DMZ.  There really isn't any DB consideration here in terms of authentication since that is done purely between the app and the authentication product used whether that be UME or a physical LDAP.  The database connects to the appserver(s) via JDBC and this is a simple network configuration to allow access across the firewall the DB sits behind.  Even in cases where no DMZ is used for the application, it is still common to have the DB behind a seperate firewall. In fact that is how we implement our hosted solution.  I am not familiar with SLC so can't comment much on using it in the landscape.

Regards,

Gary