Forum Discussion
Domain cookie issues
Hello,
Here is the issue I am trying to resolve: We have an SAP portal which is broken into two parts ie the SAP Netweaver portal ( Access policy SAP_N) and and SAP HCM Portal (Access Policy SAP_H). The SSO between the two sections is handled by SAP internally. SSO is only applied to the SAP_N policy.
In addition we have a full webtop used to host OWA (initially). The issue i am having is that when a user opens a browser and logs in to the SAP Netweaver portal, navigates to the HCM section and then opens another window or tab and attempts to access the full webtop, I get the error " Your session could not be established, Invalid session ID". This issue is happening I think because of the APM domain cookie. All the applications are part of the same domain (single domain) and initially had the domain cookie set to "domain.com" for all policies. We then removed the domain cookie entry for SAP_N and Full Webtop and now user can logon to the Netweaver Portal and open Webmail in a different tab with no issues however the minute they go the HCM section Webmail session gets logged out or killed.
The APM domain cookie settings are as below: SAP_N = None SAP_H = domain.com Full_Webtop = none
Is there a way to set unique cookies or rename the default MRH session cookie such that users can go between SAP and Full wbtop without any issues.
Thanks,
karthik
9 Replies
- Michael_Koyfman
Cirrocumulus
What version are you running?
- Karthik_Krishn1
Cirrostratus
12.0.0
What version are you running?
- Karthik_Krishn1
Cirrostratus
12.0.0
Hello,
Solution 1: You can define a multidomain sso access profile and attach it to every VS (but mix between web access and webtop is sometimes bad)
Solution 2: you setup each VS as SAML SP and you add a SAML idp to authenticate users. Once a user is authenticated on the IDP,he can go to every app that rely on the same IDP without further authentication
Solution 3: in v12.0.0, you have now a scope option in each access profile. I think you can extend the scope and allow access to other apps.
Solution 4: you use irule to make it works your way. I already developed irules to manipulate apm sessions and it works fine in many cases
But to solve this issue, you first need to stop having an apm cookie that spread the whole domain: domain.com
You can have only one MRHSession by hostname.
- Karthik_Krishn1
Cirrostratus
Thanks. I think the only option we have is option 4 . Would you be able to share the irule for this. I am keen to try this.
- Yann_Desmarest_
Nacreous
Hello,
Solution 1: You can define a multidomain sso access profile and attach it to every VS (but mix between web access and webtop is sometimes bad)
Solution 2: you setup each VS as SAML SP and you add a SAML idp to authenticate users. Once a user is authenticated on the IDP,he can go to every app that rely on the same IDP without further authentication
Solution 3: in v12.0.0, you have now a scope option in each access profile. I think you can extend the scope and allow access to other apps.
Solution 4: you use irule to make it works your way. I already developed irules to manipulate apm sessions and it works fine in many cases
But to solve this issue, you first need to stop having an apm cookie that spread the whole domain: domain.com
You can have only one MRHSession by hostname.
- Karthik_Krishn1
Cirrostratus
Thanks. I think the only option we have is option 4 . Would you be able to share the irule for this. I am keen to try this.
Hello,
Please find below a small irule to get a session cookie from another App1 (protected by APM) and play Basic SSO to the App2. I keep a APM profile on App2, in case that the first connection come here.
when HTTP_REQUEST { set apm_cookie [HTTP::cookie value MRHSession] if { [ACCESS::session exists -state_allow -sid $apm_cookie] } { ACCESS::disable set username [ACCESS::session data get -sid $apm_cookie session.logon.last.username] set password [ACCESS::session data get -sid $apm_cookie -secure session.sso.custom.password] set basic $username:$password HTTP::header insert Authorization "Basic [b64encode $basic]" } }You should not take this irule as-is because you probably need to add speicific actions. You can also define a variable at the begining of your VPE and add a condition that allow the session without any further processing if the variable is filled. Thus, you just need to replace few lines of code by :
ACCESS:session data set session.logon.last.custom.sso 1
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com