Forum Discussion
SSO in HTTPS Portal Access Resource Items
Variables used in APM don't really fit the strict local vs. global scope model. Session variables are global in nature (accessible throughout), but are protected by a unique identifier that only the session owner would have. In this rare environment, however, where you have one APM session inside of another one, they'll actually share a session. So any session variables that you create in the external (client side AAA) session will be accessible to the internal (server side SSO) session. If the internal policy requires session.logon.last.username and session.logon.last.password for a form-based SSO, then you need to set those values in the external access policy. If you have to perform any additional client side/AAA checks or lookups, then those too need also happen in the external policy. If, hypothetically, you had multiple internal portal VIPs/access profiles, and their respective SSO profiles required different values for username, domain, password, etc., then you'd need to create all of those as separate session variable names in the external policy and adjust the internal SSO profiles accordingly.
These are not global variables in the way that you may be envisioning a global variable. These are session variables, variables that are stored in a specific user session, that are accessible to both access policies.
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