The best way to explain what you're seeing is to explain how APM access sessions work. When you make your first request to an APM-protected VIP, you don't have a session cookie, so the policy immediately redirects you to the special /my.policy URI and sends the APM session cookie. This cookie contains the globally unique identifier of a record in APM's session database, and its "state" is tracked throughout the policy execution phase. Upon receiving this redirect your browser calls back to the /my.policy URI and officially starts the access policy processing - the stuff in the visual policy (ie. logon pages, AD auth/query, etc.). At the end of that policy evaluation, APM issues another redirect back to the originally-requested URI and sets the state of the session as "active". When you come back from this redirect, your access session cookie indicates an active session and you bypass the visual policy and go straight to whatever SSO you have configured. And for each subsequent request you do the same thing, never to go through the visual policy again.
Now, if you set this session token as a domain cookie (which you have), and then access other VIPs within that same domain, your browser is going to send that cookie to these VIPs. They'll see this as an active session and never process their own access policies. That is what you're experiencing.
So then the goal here is to a) provide single sign-on between applications, and b) allow each application to process its own access policy. At a minimum you can't use a domain cookie because that ties all of the applications to a single access token. Your best bet is probably to use SAML and build a separate "logon" VIP to act as the Identity Provider (IdP). Your first request to an application gets forwarded to the IdP where you authenticate and return to the application with an assertion of identity. Instead of a logon form in the application VIPs, you have a SAML Auth agent. Requests to other VIPs (once previously authenticated), also get redirected to the IdP, but since you already have a session with the IdP you get an immediate redirect back to the app with a new assertion, and each application processes its own access policy separately. The only downside of this approach is that it requires a separate session for each application plus one for the IdP, which counts N+1 against your total access session count. You can optionally do this with multi-domain mode directly from within the access policy configuration, in "host" token mode, but SAML will likely be the more robust and simpler option.
Nimbostratus
