SSO from corporate portal(non -SAP) to ABAP webdynpro

[Former Member]

Hi techies

We have a project where we need to configure SSO from corporate portal(non -SAP) to ABAP webdynpro(URL)

Can we implement SSO in this screanio.

In this corporate portal web Application(NON SAP) authencitation happens through LDAP

ENV

SAP ERP 6.0(ABAP+JAVA)

NOn-SAP : My world Application

Thanks

Haroon

[Former Member]

>Can we implement SSO in this screanio.

In this "screanio", no but in this scenario, surely yes.

It is very well described in the Portal documentation on help.sap.com...

Regards,

Olivier

[Former Member]

I didnt get you Oliver

can you tell me why

Thank You

Haroon

[Former Member]

Hi again,

I missed the fact that your portal is a NON SAP Portal.

So excuse me for my wrong answer.

I don't know a standard solution in that case.

You should ask your portal vendor about SAP SSO.

Best regards,

Olivier

[Former Member]

Which SSO technology are you currently using, meaning how does the user authenticate against "My world"?

Or will that also be new, meaning that your options are still open?

One option would be to look into SAML, which is also interoperable from non-SAP systems.

Cheers,

Julius

[tim_alsop]

Hi,

The most common approach to this kind of requirement is to use HTTP headers. The non-SAP portal would authenticate the user using any method it supports, then store the userid in a HTTP header, so that when accessing the SAP portal, the SAP portal knows who the user is. This isn't the most secure solution, but it is used widely by SAP customers for meeting the same needs as you.

As already mentioned, SAML can be used, but SAML requires a lot of setup and additional infrastructure. So, even though SAML is the best technological solution for this kind of requirement, it might not be the cheapest to setup and implement.

Another solution I have seen used, is to make both portals use the same method of user authentication. For example, if the non SAP portal uses Integrated Windows Authentication to know the user logged on at workstation, and you make the SAP portal use same method of authentication, the user will get an SSO experience when they logon to either portal because they will be recognised as the same user regardless of which one they logon to first.

THanks,

Tim

[Former Member]

Thanks for the reply

My question is corporate portal (NON SAP) should not ask for username and passowrd when it call the webdynpro URL (ABAP).

corporate portal (NON SAP) uses LDAP as authentication

For this Http header wil work ?

How to implement the http header

Thank you

Haroon

[Former Member]

Which service is it calling?

Which type of operating system are you on?

Have you tried doing a search? (you are not the first person to do this...)

Cheers,

Julius

[Former Member]

Hi techies

Thanks for the reply

Since i am not aware of SSO from non-sap to sap can somebody guide me how implement SSO

I want to call the URL of ABAP webdynpro BSP from the NON_SAP portal

I did search but couldnt find the relavent doc

MY confusion is NON-SAP uses LDAP authencitation and SAP uses ABAP as UME ?

Can u clear this confusion or i do not need to change the UME else i need to call the ABAP URL only

ENV

SAP : ECC 6.0 (ABAP only)

NON_SAP: Windows 2003 server

OS -SAP : SOLARIS

Thank You

Haroon

[allaine_tabilin]

Hi Haroon,

Your solution will just be using logon tickets for the SSO. However, can we ask how you plan to sync the ABAP UME with the LDAP. Is the LDAP to ABAP UME synchronization already in-place?

Your non-SAP system should be a system that can read / accept a logon ticket (or a HTTP cookie MYSAPSSO2). If it doesn't have it currently, you can ask your developer to create the required coding (to call the APIs from SAP to generate the cookie). The idea is to authenticate first to SAP (or have SAP) to generate the ticket before you connect or use the BSP service in SAP. For that, you can use a generic system id in SAP (communication or system type id). Once the ticket is generated, use that for SSO connections.

SAP also has a help file on other soulutions http://help.sap.com/saphelp_nw04/helpdata/en/4f/bd2c3a11f3bf31e10000000a11402f/frameset.htm

Thanks,

Allaine

[WolfgangJanzen]

We have a project where we need to configure SSO from corporate portal(non -SAP)  to ABAP webdynpro(URL)
Can we implement SSO in this screanio.

The only SSO mechanism that is currently available (in this scenario) is X.509 client certificates.

As of NWAS ABAP 7.02 (next basis release for the up-coming Business Suite) SAML 2.0 is supported, in addition.

Both are standards - not proprietary solutions. And that's the (only) way to achieve a cross-vendor SSO.

[tim_alsop]

>

> The only SSO mechanism that is currently available (in this scenario) is X.509 client certificates.

This is not strictly true, and perhaps a little misleading. As you know, this can also be acheived using HTTP header variables, if a Java stack is available, and I have helped many companies implement SSO using this kind of approach. A large number of customers are not prepared to issue and manage client certificates for SSO and often the non SAP portal does not support this kind of approach. Instead, the easiest solution for a SAP customer is to make the non SAP portal store the users id in a HTTP header and then pass the requet to a Java stack, and the Java stack will then issue an SSO2 ticket and redirect to ABAP stack. The ABAP stack will be configured to trust the SSO2 ticekt issued by Java stack and will then log the user on using this ticket.

Thanks,

Tim

[WolfgangJanzen]

... this can also be achieved using HTTP header variables, if a Java stack is available ...

This is not the point - and BTW: you can then just use the SPNEGO support offered by NWAS ABAP (w/o the need for HTTP header variables which need to be populated by an external component which needs to reside between the browser and the server - without the chance to bypass it).

I assume that a straight solution (only external portal and ABAP - no additional components) was requested.

And under that constraints my previous answer should be read.

Cheers, Wolfgang

PS: NWAS ABAP does not support HTTP Header Variables for "authentication" - and you cannot deploy your own "custom login modules". SAML 2.0 will be the (standard-based) solution to overcome all that: then you can use an external SAML Identity Provider (IdP) which could implement and provide any authentication method - and an ABAP system could benefit from it (w/o the need to modify any ABAP coding). Isn't that a nice thing? (Just configure, don't code anything)

[tim_alsop]

>

> This is not the point

I am not sure what "point" you are referring to. My reply was supposed to highlight to anybody today or in future who reads this thread that SSO from non SAP portal to SAP systems can be done without requiring x.509 client certs - your post suggested this was required and implied that no other options were available other than SAML (in future release).

> - and BTW: you can then just use the SPNEGO support offered by NWAS ABAP (w/o the need for HTTP header variables which need to be populated by an external component which needs to reside between the browser and the server - without the chance to bypass it).

I am not aware of SPNEGO for NWAS ABAP - I thought that Java stack was required. I assume you made a typo ?

Anyway, if SPNEGO is used, this assumes that the user has logged onto non SAP portal using the same user account that they logged onto Windows with, or that the non SAP portal is using IWA (e.g. SPNEGO). If this is not the case, and the non SAP portal is asking the user to logon with a user account name which is not same as Windows domain account name, then the SPNEGO approach you mentioned may not be suitable, but it is certainly a very valid option, just like HTTP header variable method is also a valid option (but less secure).

So, now it is clear that this can be implemented using x.509 client certs, HTTP header, and SPNEGO. In fact any form of authentication can be used that is supported by SAP via standard login modules or custom login modules. Also, SAML can be considered, but only if the non SAP portal will support this and customer is using correct version of SAP software.

>

> I assume that a straight solution (only external portal and ABAP - no additional components) was requested.

> And under that constraints my previous answer should be read.

If you were going to make this assumption, then you should have said so - somebody in future reading your post might not realise your assumption. I hope you don't mind me correcting you on this ?

[WolfgangJanzen]

>

> - and BTW: you can then just use the SPNEGO support offered by NWAS ABAP

> I am not aware of SPNEGO for NWAS ABAP - I thought that Java stack was required. I assume you made a typo ?

Oh, sorry - that's a typo. Please replace "NWAS ABAP" with "NWAS Java".

No, you are right - there is no SPNEGO support for NWAS ABAP.

> So, now it is clear that this can be implemented using x.509 client certs, HTTP header, and SPNEGO. In fact any form of authentication can be used that is supported by SAP via standard login modules or custom login modules.

Yes - but it requires an (additional) NWAS Java.

> Also, SAML can be considered, but only if the non SAP portal will support this and customer is using correct version of SAP software.

Yes - and here no NWAS Java is required (but an additional SAML 2.0 Identity Provider, to be frank - however in the given case that could be the non-SAP portal). I'm aware that certain vendors (which I cannot name here) have concrete plans for this (non-SAP portal in combination with ABAP backends, based on SAML 2.0). Yes, it requires pretty new product versions - on all sides (non-SAP and SAP). But that's the way that's taken next (Next-Generation SSO).

Cheers, Wolfgang

[tim_alsop]

> Yes - and here no NWAS Java is required (but an additional SAML 2.0 Identity Provider, to be frank - however in the given case that could be the non-SAP portal). I'm aware that certain vendors (which I cannot name here) have concrete plans for this (non-SAP portal in combination with ABAP backends, based on SAML 2.0). Yes, it requires pretty new product versions - on all sides (non-SAP and SAP). But that's the way that's taken next (Next-Generation SSO).

Yes, I agree that SAML 2.0 is the way forward in future, but most customers are looking for a solution today, and don't want to depend on software upgrades which might not be available for a while (it takes many years for some customers to plan upgrade to new versions of SAP software).

[Former Member]

Another 4th option which I have seen used (really crap though...) is to use a generic RFC user to authenticate on the backend ABAP system and then re-implement your own authentication or identification mechanism to catch the user ID name on the non-SAP system.

Doing a where-used-list search on some dodgey FM's usually finds them quickly. Watching the gateway via SMGW can be usefull as well.

The application on the non-SAP system has to take care of all the security upfront and if the ID name matches the ability to perform certain tasks (you will not get around check tables for this - so it is not a scalable authorization concept either...) then just send the lot into the workflow engine which by default normally passes all checks.

Those I have seen generally do not make an existance check on the user ID either.

See SAP Note 1251255 (which I can strongly recommend implementing) to contain this or "isolate" it against badly designed vendor software.

Cheers,

Julius