Provision UserID/Password from SAP Ssyetm to Non-SAP System

[Former Member]

Hi,

I have a requirement to be able to provision UserID & Password from a SAP ECC6 system to a non-SAP thick client application. All interactions between ECC6 & the non-SAP Application will be via SAP PI. (SAP EEC6 <-> SAP PI <-> Non-SAP App)

Our landscape includes:

SAP ECC6

SAP BI

SAP PI

SAP SOLMAN

SAP Portal

non-SAP App

SAP IdM has been ruled out due to budget constraints, Active Directory is not suitable due to the requirement that the non-SAP application must be able to authenticate users if the WAN/LAN is down.

Yes, we could simply maintain the users in both systems, but for the time being that has been deemed not appropriate.

I have thought about using CUA on SOLMAN to provision to the SAP Systems & then use SAP PI somehow to provision to the non-SAP App, but I have no idea how to pass the raw user password through SAP PI.

If anyone has any ideas or can point me to links where I can do further research would be much appreciated.

Thanks in advance,

Stephen Hall

[Former Member]

The search term "password AND synchronize" will help you further to find "flamewars" from the past.

You cannot send "raw" passwords from CUA, as the password is represented by a "one way" hash which is not decryptable by mortals, but rather the "raw" password is encrypted and the hashes are compared locally. Non-SAP systems cannot do this... (bar trial-and-error).

A better option would be to use a SSO mechanism. This is very easy within SAP.

For bi-directional authentication with non-SAP you will face some challanges...

The easiest option is to re-use a PKI certificate based authentication or re-use the native Kerberos authentication available for Windows bases PCs.

In the SAP --> non-SAP direction you can consider using a verification library to extract the user name - but that is not "state of the art" and if such a UID should be encrypted then have fun...

In the non-SAP --> SAP direction you are best off forgeting about the infrastructure trust or worste-case-scenario is a password sync. Rather re-authenticate the caller using a realm which already exist.

Active Directory is not suitable due to the requirement that the non-SAP application must be able to authenticate users if the WAN/LAN is down.

I would consider an application specific password self-service as a failover only and go for the AD or an "identity provider" which your applications trust as a service.

If your AD or entire network goes down you will probably be in bigger trouble than passwords... so you should not expose "raw" passwords during normal operations for this eventuality...

Cheers,

Julius

[Former Member]

Thanks Julius,

I would love to use SSO but the non-SAP application is an Retail Point of Sale application with a requirement to be able to authenticate users if the WAN or LAN is down, hence the desire to provision the same UserID & Password to both SAP & non-SAP which is what I believe SAP IdM can do. The application has user authentication built into it.

Just thinking wildly, is there anyway of getting the checksum of the raw password so that could be used to check authentication in the non-SAP system?

Regards,

Stephen

[mvoros]

Hi,

if you really want to have a homebrand IdM then since particular release BAPI BAPI_USER_CHANGE allows to set productive password. This feature was required by SAP IdM. So you could create a custom transaction where you would be able to create new user with password. Here you would have access to password in clear text so you could pass it to another system (probably SSL is a good idea ). But you might get into troubles with unsynced passwords between system as you were warned by Julius.

Cheers

[Former Member]

Hi Stephen,

In addition to above two comments, I would like to add something to user provisioning and password maintainence and replicating them between SAP and non SAP system.

This method would rely on your coders and how flexible are you with your process changes.

1. When a new user enters your landscape, SAP User provisinong and password mantainance will not be an issue.

2. For maintianing the non-SAP system in sync you need to write a ABAP program which connects to the database where user information are stored. I would say user name,user id, user roles, user valid to and valid from dates and password tables are basic information. Once the user information is fetched have the program create the user ID in non SAP environment by passing the parameters needed.

We followed such kind of approach for one of the SAP / MDM application to sync up the valid from and valid to dates for the users and get the report.

Again I would say.. it depends on how flexible your process is.

Rakesh