webservice proxy sso

[Former Member]

Hi all,

how can I configure a webservice proxy from one Abap system to another abap system using SSO?

I try to use the sm59 destinations type G, but no work's.

can anyone explain a little example?

thanks in advance,

david

[Former Member]

Hi,

I know.

Now I can call a webservice, but to work correcty I need uninstall the security on the webservice side.

In this case, on the SICF that get the wsdl file.

But I need create a SSO connection to this wsdl file.

I've read on this forum that I need create a rfc type G, but no work or I cannot be capable to run this.

thanks

david

[Former Member]

Hi,

I need create a Webservice call from ABAP (se80 -> package -> create service call), and the call gate (LPCONFIG) using SSO to another ABAP Webservices.

david

[SergioFerrari]

It's a pity but the Wizard has not yet learned this.

It knows only RFC (locally defined).

If you are able to call a Web Service from a simple report (ABAP type 1), I think you only need 10 minutes more to call a WS manually from WDA.

In this forum you'll find a lot of suggestion to make use of the assistance class (WD_ASSIST) where the complete ABAP Object framework is available.

Obviously you have also to define and fill the context manually .

Sergio

[Former Member]

Hi David,

you can create a web service porxy client in SE80. See the enterprise service tab.

Or see the option to open any object type and go enterprise services.

Here you can create a proxy by loading or connecting to a WSDL.

The result is an ABAP class method you can call from WDA.

This works with or with XI.

XI offers more features such as mappings, but the raw call from ABAP stack without

XI works.

regards

Phil

[Former Member]

Hi David,

who or what is logging on to the systems? (The security design question)

SYSTEM A -> calls System B.

But is the user making this connection ?

ie Is it a system user or the current user ?

If it is the front-end user, who should be calling a web service from code,

then the users browser should be involved.

The user also get the ability to reject the sending of the ticket. (browser setting)

Imagine you have an SSo2 ticket, you use connect to an Http service.

This website steals your ticket and tries to connect the same site as you.

Hence browser supplies the ticket approach, not server grabs tickets to connect somewhere

for you.

HOWEVER,

2 systems can trust one another.

Ie of SYSTEM A has authenticated you, that is good enough for System b.

This is easy to setup with RFC calls.

See sm59 and SMt1 and SMt2.

Once a trust between the 2 systems is established, the RFC connection is marked as type trust. The current user id is then used.

FOR HTTP it is not quite so simple. (well I find it harder to setup)

From memory

SYSTEM B needs profile parameters.

login/accept_sso2_ticket = 1

The RFC HTTP connection created in SYSTEM A to access B

needs to have send ticket checked

SYSTEM A needs also needs

login/create_sso2_ticket = 2

The security help should have more details on this.

http://help.sap.com/saphelp_nw2004s/helpdata/en/8c/2ec59131d7f84ea514a67d628925a9/frameset.htm

You should also look at transaction STRUST to export and and import certificates.

Can only recommend Docu if you havent tried this before.

regards

Phil.