If I may elaborate, multi-domain SSO requires an additional VIP - one for each application and another "login" VIP. The multi-domain policies are all configured to point to the login VIP for authentication. When the user makes the first request to the app VIP, it redirects to the login VIP, the login VIP access policy authenticates the user, then redirects back to the app VIP. There's two modes by which it can do that. The first mode sets a domain-scoped APM session cookie in the browser so that the browser will send this same cookie back to the app VIP. The second mode sends the session token in the URI of the redirect. The app VIP then issues a redirect back to itself to set this value as a local host-based cookie. Both modes allow the app to share client session information with the login VIP. There's one important caveat to this methodology. The app VIP's access policy is NEVER evaluated. The user is redirected to the login VIP, redirected back to the app VIP with a token, and then the app VIPs access policy (visual policy) is completely ignored. You can still do server side SSO, but no opportunity to do any additional queries inside the VPE. You must then gather all of the information you need about the client from the login VIP. SAML presents a similar pattern, but does indeed allow the app VIP's policy to be evaluated.
The absolute simplest method, however, is to simply define the APM session token with a (single domain) domain scope. So for example, app1 = app1.domain.com, app2 = app2.domain.com. The user accesses app1's VIP, authenticates locally and gets a domain-scoped session cookie (domain = domain.com). Whenever the user accesses app2 it passes that cookie and the second app allows entry and the access policy is never evaluated (except for server side SSO).