Deny Access from SAP-Logon and allow access from Webservice

[Former Member]

Hello,

I've a question regarding different logins.

We're using a portal (non SAP) where SAP-Reports were integrated. Therefore the user has to login on the SAP Webservice to see the report results. This works. As the users don't need to access the SAP directly is it possible to deny the access with SAP-Logon/SAP-GUI.

I think it is not possible to handle it with the usertype because it has to be a dialog user.

Can SAP differentiate from where a user is logging in and handle the access?

Thx for you help.

[sreekanth_sunkara]

Becksen,

i think you need to deactivate (click on deactivate in logon data tab) the password on ABAP side then user wont be able to login directly from SAP and can use the webservice.

Thanks,

SS

Edited by: sun on Aug 5, 2010 3:34 PM

[Former Member]

Thanks for your answer,

I tried it but I wasn't successful. When it's deactivated you can't login with password but that's also valid for Webservice. So you can't

SSO logon not possible; logon tickets not activated on the server 
 Choose "Logon" to continue A dialog box appears in which you can enter your user and password 
 No switch to HTTPS occurred, so it is not secure to send a password 
 Client, name, or password is not correct; log on again 

[Former Member]

Not installing SAP gui to these user might do the trick .

[Former Member]

Of course,

this is true. But SAP-Login is part of our standard installation routine. So every computer or laptop have it installed

[Former Member]

An intended solution to these type of issues is to use network topology (routers, firewalls, webdispatchers) between the client side and the server side.

Another approach is the user type if the person should not have any access which is interactive --> change them to type "system" and it will fail because they cannot change their own passwords. Note that a SYSTEM type user cannot issue an SAP Logon Ticket if that is the SSO provider module used and there might be license measurement implications.

Cheers,

Julius

[Former Member]

Hi,

Apart from the SSO issue , I have faced a situation where BP( business partner in CRM ) could not be configured if the user type is service/System.

webshop will also fail if the user type is not a dialogue user.

[Former Member]

Hope this parameter helps

login/disable_password_logon

if you are using SSO or other methods to logon.

Regards

[martin_voros]

Hi,

one dirty solution could be to implement user exit SUSR0001 and kick out unwanted users right after logon. If you have proper roles assigned to those users then they should not be able to execute anything. Right? As far as I know users if there is nothing for them then they won't bother to logon.

To do not install SAP Gui does not sound as a secure solution to me.

Cheers

[Former Member]

Martin,

Could you tell me whether it is possible to implement the user exit in the following way?

Backend ABAP system only accepts the "SYSTEM TYPE" user thru web service (HTTP) request and reject the same user if some one uses the user id from external NON-SAP client program (VB script or perl program).

The reason is, there is a threat from internal staff could sniff this webservice traffic for userid and password, and will use it for non-sap client program. The sniffing is possible becos the HTTP communication is not over SSL.

Can we restrict this non-sap client program accessing SAP ABAP system thru secinfo and reginfo table????

Thanks,

Himadama

[martin_voros]

Hi,

no it's not possible because that user exit is called only for dialog users.

The easiest solution to mitigate a risk of stolen password is to introduce SSL. Why can't you user SSL?

I also  guess that it's impossible to differentiate between non-sap and sap program. You can try to restrict access to web service from selected IP addresses using web dispatcher but if an attacker can gain IP address from this range then it won't help you too much.

Cheers

[Former Member]

> no it's not possible because that user exit is called only for dialog users.

Not possible, but the reason is different --> the exit is triggered by the SAPGui logon program for DIAG protocol negotiations for sessions. Independently of the user type the logons via RFC or http(s) protocols do not trigger this exit.

If a naughty person does not have direct line-of-sight to your SAP ABAP system, cannot access your firewall and proxy / router config and cannot physically access the data center, then 2 options remain:

1) Authenticate via the webserver consuming the webservice.

2) Transcendental meditation to a medium on the other side of the firewall ...

Cheers,

Julius

[Former Member]

Thanks Martin for your details.

Our architect team has made a decision not to use SSL for http requests (web services) because of the performance issues. So SSL is not an option for us.

The risk of using the stolen logon credentials to execute a web service thru a CHANNEL(end point)(portal - one of the channels) is not a considerable one in our environment. Since the request process thru middleware and load balancer and the target system only accept the requests from load balancer (based on ip filtering).

The only risk is using the stolen userid/password for a non-sap program.

As I have noticed, the web services execution (thru ws navigator and SOAP UI from development team) is not looking for S_RFC authorization object and the WS request is only looking for S_SERVICE and application specific authorizations.

As we have a vb script program, which reads the table data thru a function module. (Not tried deleting or updating something in the system). After the successful logon attempt to the target system, the system looking for other function groups authorizations (FG-SYST, FM-RFCPING; FG-SRFC, FM-RFC_SYSTEM_INFO; FG-RFC1, FM-RFC_GET_FUNCTION_INTERFACE; FG-RFCH, FM-RFC_GET_UNICODE_STRUCTURE) before it calls the FM RFC_READ_TABLE.

The other thing I have noticed from SAP delivered web service roles is S_RFC authorization object included in it. But the FG is different. I am not sure whether our end application also requires this S_RFC with FGs SYST, RFC1, RFCH and SFRC. I can not confirm this now since we havenu2019t started our application end-to-end testing yet.

I am assuming if our end application do not require S_RFC then the non-sap client program can not logon to the system with the stolen userid/password. I assume the risk can be ignored.

Please let me know about your thoughts..

Thanks,

Himadama

[Former Member]

I have seen this combination of function groups before and you need to be carefull.

It looks like some "creative" development to maximize flexibility at the cost of security.

When you trace, use SM19 and not ST01. You need to decide what to do with the NONE type destinations. If you check them, then you need to either add the access or change the design of this application.

SSL and performance is another urban legend if your systems are appropriately sized. This is not a valid excuse IMO.

Have they considered what the liability will cost... ? Or is http only within the server network?

Cheers,

Julius

[Former Member]

Julis,

Thanks for your details.

When you trace, use SM19 and not ST01.

Yes I used SM19 to find out function modules. ST01 do not list FM.

You need to decide what to do with the NONE type destinations.

Can you please elaborate the risk involved with NONE type destinations?

If we could prove that the risk can only be avoided with SSL then only it is possible trun on SSL. I am not sure whether our arch team has considered these type of risks(internal threats) or not.

is http only within the server network?

Yes it is with in the network only.

Cheers,

Julius

[Former Member]

ST01 also does not list the host of the caller, but SM19 does.

Are you sure that it is in the server network and no external callers can pass dodgey parameters to it?

Looks very shakey to me...

Cheers,

Julius

[Former Member]

Just discovered this thread and I apologize for a late posting of a silly comment...

You're concerned about users sniffing logon information from HTTP requests? Assuming that you have switched network connections I'd say you probably have some advanced users (or admins that can't be trusted). For such people it would also be trivial to get user/password combination from any SAPgui logons if you don't use SNC (in that case the SAPgui network traffic is only compressed, but not encrypted). Now I'm not arguing to simply ignore all security risks - I'm just surprised that there's often concerns in some areas whereas other areas are completely ignored...

Any statements about SSL performance I'd treat like any other performance problem - don't assume too much, test and check your results (maybe that was done already, but it sounded as if your architecture team just voiced some general concerns). Due to different hardware and applications it's almost impossible for anybody to come up with reasonable numbers for estimating the overhead introduced by SSL without doing any testing. E.g. factors like session length (shorter sessions make additional SSL handshake overhead more relevant), caching, etc. have to be considered - so run some different scenarios and loads and see what happens.

[Former Member]

Hi,

Through communication user type map the user to another user id in R/3 and do not disclose the user relation and password to the enduser. or otherwise Try to differentiate the password between the portal and R/3. Don't disclose the R/3 password to the user.

Regards.

Shrinivasan. KV