Forum Discussion
joesnyder_13328
Nimbostratus
NimbostratusAPM Policy not being re-evaluated when using single domain SSO
We have several policies set up to protect several web-based applications. Our policy is essentially an external logon page, then an AD Auth, and finally an AD query to verify that the user is allowed to access that application based on a AD role. We have configured the APM to use Single Domain SSO, HTTP Only, and all of the cookies belong to our top level domain so users can navigate from one site to another and not have to login again. The only issue appears to be that if a user logins into an application they have permissions to, then navigates to an application they don't have permission to they are granted access. It seems like it isn't evaluating the APM policy when the user goes to a different site. How can I maintain the user's ability to not have to sign into every application, but force the user to have to go through the APM policy to verify they have access when they go to a different application?
- Kevin_Stewart
Employee
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.
