How can I authenticate users against a WAS system from third-party app?

[former_member211904]

We are looking at developing a third-party standalone web application e.g. in Rails (but it could be on any framework for that matter).

How would we go about authenticating users against a SAP WAS backend? Are there some standard web services for this? What other means are there for authentication?

Kind Regards,

Martin

[mvoros]

Hi,

basically, you can use all standard methods available in Netweaver. Check documentation for Netweaver for more details. You can use simple username/password, certificates, SAP logon tickets or SAML (this depends on your version). I am not sure what exactly you want to do but if you don't want to have one integration user for all calls but you want to use logged user for call (every user of your app will have also account on SAP box) then SSO logon tickets or SAML is way to go.

Cheers

[former_member211904]

Thanks Martin. We want to be sure we are using a valid user on the WAS so that calls to web services on the WAS are done with that user (so we are not storing users in our database). So the application, and not the browser, will be acting as the client to the WAS.

I suppose one could do basic authentication using a user and password supplied by the user in the browser. How then do you deal with password expiration and resets? Can you maybe give me some links for reading up on this topic? Can the WAS act as a SAML authority/provider?

[mvoros]

Hi,

I am not sure what you mean by dealing with password expirations and resets but there is standard functionality available so you could try to reuse it.

It should be OK just to use SAP logon tickets. When a user enters username and password on your custom application you can call a custom service over http which requires basic username/password authentication. If the user enters valid password then this service will return a logon ticket which can be reused for the following service calls. WAS needs to be set up that it can create logon tickets. The ticket needs to be stored in a user session (this depends on technology used for custom applicaiton). When user ends her session you just need to invalidate session. Simple as that.

As far as I know WAS can be only SAML consumer. So you would have to use another product as a provider.

Cheers

[former_member211904]

Hi Martin,

Thanks again for the reply. Based on what you have said, I resurrected (which is very fitting because we are about celebrate Easter ) an old blog post of mine which I never published.

It follows the train of thought of using a custom service. I never really put this to practice, but I might do so now. If you are interested in reading it, I would be interested in hearing your thoughts (because perhaps you have some better ideas). The link is: http://ceronio.net/2011/04/change-password-web-service-in-sap/

Kind Regards,

Martin

[mvoros]

Hi,

unfortunately, the long weekend is over. Anyway, I read your blog and basically that's what I mean. One question. Why don't you propose to create a service user which will be used for that first RFC call to verify if user is locked. From the comment in SUSR_LOGIN_CHECK_RFC you just need to pass user name and it will return if user can still log on. Only your system will know credentials for this user so an attacker won't be able to use this service for cracking passwords.

Cheers

[Former Member]

From the comment in SUSR_LOGIN_CHECK_RFC you just need to pass user name and it will return if user can still log on. Only your system will know credentials for this user so an attacker won't be able to use this service for cracking passwords.

This FM is in the same function group as:

CREATE_RFC_REENTRANCE_TICKET
SUSR_CHECK_LOGON_DATA
SUSR_DELETE_OWN_PASSWORD
SUSR_GENERATE_PASSWORD
SUSR_GET_ADMIN_USER_LOGIN_INFO
SUSR_GET_X509CERT_MAPPING_LIST
SUSR_LOGIN_CHECK_RFC
SUSR_USER_CHANGE_PASSWORD_RFC
SUSR_USER_EXTID_DEL
SUSR_USER_EXTID_GET
SUSR_USER_EXTID_GET_ALL
SUSR_USER_EXTID_LOOKUP
SUSR_USER_EXTID_RENAME
SUSR_USER_EXTID_SET
SUSR_USER_EXTID_SET_ALL
SUSR_USER_FROM_CERTIFICATE_RFC
SUSR_USER_SETEXTID

You would need to ensure that only the service exposing the "login check" can be called, and not the FM's in the group.

BTW: SAP Java WAS can provide SAML 2.0 assersions (technically a component shipped with IdM, but you don't have to use the rst of the IdM if you don't want to..). If your applications are all web enabled ones (WDA?) then that is an option to consider, which is also strategically supported.

SSO2 Logon tickets are not really a strategy anymore... and installing a double-stack system on all ECC sytems just to have SAML is not strategic either..

I have heard several wishes for SAML authentication for SAPGui, but not seen anything official yet in that direction.

Cheers,

Julius