Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

SAML Web SSO not setting the MYSAPSSO2 cookie. Causing OData issues.

former_member186439
Participant
0 Kudos

We have implemented SAML 2.0 Web SSO between a NetWeaver system and Microsoft ADFS.  ADFS acts as the identity provider.  Web SSO is based on a redirect with a POST binding. 

We thought everything was working great.  All of our SAP-hosted web pages come up without requiring anyone to enter a user name and password.  However, now that we are trying to work with SAPUI5, JavaScript, and OData-based web services, we are encountering a problem.  Our calls to the OData-based web services do not appear to be authenticated - Basic Authentication prompts are appearing. 

If we run the same function without Web SSO, everything works as expected.  The initial web server 'hit' generates Basic Authentication prompts.  And, once authenticated, the downstream web service call does not generate any authentication prompts.

Comparing the two scenarios using Fiddler, the difference appears to be the MYSAPSSO2 cookie.  Basic Authentication to the web page creates the MYSAPSSO2 cookie which satisfies the authentication needs of the web service call.  SAML 2.0 Web SSO to the web page does not create the MYSAPSSO2 cookie so the web service requests additional authentication.

Am I misunderstanding something about Web SSO?  Is there something I can do to get the Web SSO to generate the MYSAPSSO2 cookie?  Is this an authentication handler issue?

1 ACCEPTED SOLUTION

former_member186439
Participant

The short answer to this problem was that we went into SICF for the web service, went to the Logon Data tab, selected Alternate Logon Procedure, and re-ordered the Logon Procedure List  and moved SAML Logon to the top of the list (before Basic Authentication).  This fixed the problem.

Now, why did this work?  First thing is we needed to understand was the difference between the MYSAPSSO2 cookie and a SAP_SESSIONID_<sid>_<client> cookie.  Seems that both of these cookies can indicate that a web user has already been authenticated by the SAP system.  The Basic Authentication logon procedure both sets and accepts the MYSAPSSO2 cookie.  The SAML Logon procedure both sets and accepts the SAP_SESSIONID cookie.  I'm not sure why the Basic Authentication logon procedure doesn't accept the SAP_SESSIONID cookie, and I'm also not sure why the SAML Logon procedure is below the Basic Authentication procedure in the list (thus ensuring that it never get executed?).    

5 REPLIES 5

cris_hansen
Advisor
Advisor
0 Kudos

Hi Steven,

Maybe a good start is reading SAP note 1257108, a SSO troubleshooting note. You can also use SAP note 2181120 for tracing security events in HTTP in ABAP AS.

For SAML2 matters, I recommend the following links:

SAML 2.0 Configuration

SAML 2.0 in ABAP AS wiki page

Troubleshooting SAML 2.0

SAML 2.0 trace

I hope this helps.

Regards,

Cris

former_member186439
Participant

The short answer to this problem was that we went into SICF for the web service, went to the Logon Data tab, selected Alternate Logon Procedure, and re-ordered the Logon Procedure List  and moved SAML Logon to the top of the list (before Basic Authentication).  This fixed the problem.

Now, why did this work?  First thing is we needed to understand was the difference between the MYSAPSSO2 cookie and a SAP_SESSIONID_<sid>_<client> cookie.  Seems that both of these cookies can indicate that a web user has already been authenticated by the SAP system.  The Basic Authentication logon procedure both sets and accepts the MYSAPSSO2 cookie.  The SAML Logon procedure both sets and accepts the SAP_SESSIONID cookie.  I'm not sure why the Basic Authentication logon procedure doesn't accept the SAP_SESSIONID cookie, and I'm also not sure why the SAML Logon procedure is below the Basic Authentication procedure in the list (thus ensuring that it never get executed?).    

0 Kudos

Hi Steven,

We are having the same issue... We have SAML enable on SAP system but when we try to hit Fiori Launchpad... it is prompting for the SAP ID and password...

In which SICF we have to change the setting to Alternate logon Procedure...

Can you please provide me the SICF path...

Can you pls also send me details of your dispatcher... you can change the hostname for your web dispatcher...

Regards,

Kalpesh Mehta

0 Kudos

Hello,

We have same issue ...

1. When  an user visit launchpad URL, URL will redirect user to identity provider (IDP) for SAML authentication.

2. Then IDP authenticate with SAML2.0 token back to gateway.

3. Gateway accept the SAML2.0 token and issue SSO2 logon ticket.

4. Use logon ticket to back-end SAP BO system

Now the first step above is OK as SAML token can be authenticated back to gateway. however we have now authentication pop-up for user credential on both back-endSAP BO


However, when we disabled SAML  SSO works perfectly fine to SAP BO system


Can you please let me know what in whiich SICF service, we need to change ?


Regards,

Kunal Salunkhe

0 Kudos

First, make sure that your SAML2 service provider is configured to issue logon tickets.

1.Start the SAML 2.0 configuration application (transaction SAML2).
2.On the Local Provider tab, choose the Service Provider Settings tab.

3.Choose the Edit pushbutton.

4.Under Miscellaneous, enter On in the Legacy Systems Support (Issue Logon Ticket) field.

5.Save your entries.

Then you can make sure the logon procedures are in the correct order as described above.  For the Fiori Launchpad I think that is something like default host/sap/bc/ui5_ui5/ui2/ushell/shells/abap/.