HTTP Adapter - Security question/issue

[Former Member]

All,

Once a (communication) user can post messages to XI via the HTTP adapter, the sender can take the identity of any sender (“spoofing”). Simply specifying another Sender in the URL allows to take someone else's identity.

The question now is: how to avoid that a HTTP sender would take the identity of another sender? Or is there an authorization mechanism (hidden feature) that allows me to link certain accounts to certain sending Parties or Business systems?

For adapters that use a Sender Agreement, the security of the underlying middleware can be used. Example:

The J2EE JMS adapter reads messages from a queue where only specific users are allowed to put messages on (the JMS broker

Kind regards, Guy Crets

[former_member185751]

Hi Guy,

Messaging users can be authenticated by SSL client certificates. Both inbound and outbound connection can be secured by SSL.

There are two good documents on XI security available in the following website:

1.service.sap.com/security -check under XI heading

2.also a "how-to" step-by-step guide in service.sap.com

If you are unable to find them, drop your email id here, i will send them to you.

Regards,

Sridhar

[Former Member]

Thanks Sridhar,

Thanks for your feedback. But my question is related to authorization, not authentication. FYI: we already have SSL with client certificates in production use with XI 2.0.

To rephrase my question: the sender puts the actual sender name and interface name in the URL. Nothing prevents the sender to pretend being someone else. XI does not allow (to my knowledge) to make the relationship between a certain XI user account and a party or partyless sender service.

Kind regards, Guy Crets

[Former Member]

I had the same concerns when we implemented on 2.0 several months ago. My question was for the SOAP adapter, but it's the same interface spoofing issue.

I finally asked OSS about it, and a solution to this is planned in a future SP (for 3.0). I don't have any further information at this point.

--Dan King

Capgemini