Santosh Lad wrote:
But we have been struggling to get the best setup for Timeout across the environment such like
1. Timeout for SM Sessions between Siteminder and FIORI Gateway
2. Timeout for MYSAPSSO2
3. How to redirect users to IdP SSO login page after either of it timeout?
4. SAML2 has an option to create "Legacy Logon Ticket" which we have turn in ON. Do we need it?
5. FIORI Launchpad services like PERS, keep asking user id and password after successful login in Launchpad. We had to setup all services to "Alternatives logon procedure" to use SAML Assertion. How to create SSO cookies for all services once logon to Launcpad.
5. Conflict of MYSAPSSO2 cookies with other SAP Website. I noticed same MYSAPSSO2 cookies being used if we have 2 different website connecting to ECC (Trusted relationship)
Example -
a. FIORI connect to ECC with Trusted relationship
b. PPM NWBC connect to ECC with Trusted Relatiopship.
But if I log out from one website, other website errors "sessions does not exist"
How to deal with it?
Well, since you are using SAML 2.0 for authentication (with Siteminder acting as IdP and Fiori Frontend Server acting as SP) there's no need for SAP Logon Tickets (cookie MYSAPSSO2) anymore - so the answer to question #4 is "no". That also solves your problem #2 and #5.
When launching the Fiori launchpad, the SAML 2.0 authentication takes place and a Security Session is created (and cookie SAP_SESSIONID_<ABAP systemID of the Fiori Frontend server>_<ABAP client ID> is set). All subsequent OData calls (via XMLHttpRequest) will use the Security Session. Only when not transmitting any OData requests for a longer period of time, the Security Session might time-out. If that happens, the SP (ABAP) will submit a request to the IdP to request a new SAML Assertion. Unfortunately, that cannot be done using XMLHttpRequests. But we have a solution for that: we call it "XML Logon protocol". In short: when the backend detects such a situation and also detects that the XMLHttpRequest was submitted from a Fiori client (using the Fiori client library), it will react accordingly; currently, we are able to instruct the client to submit a http request to the IdP using an iFrame. Of course, that requires that the IdP does not prevent that.
Regarding your last question:
Well, part of SAML 2.0 is the "Single Log-Off" feature: once you submit a Logoff request to any of the SAML entities (IdP or any SP) all other SAML entities will be notified upon the logoff request (by the IdP) and will react accordingly. So, what you describe is "working as designed".
Since you logon only once (at the IdP) you can also logoff only once - that's the design principle of SAML 2.0.