Issue with SSO network access

For SSO through the SSLVPN, you need to apply a separate access policy to the application. Make it very simple (start -> allow) and assign an SSO profile. Most important, the session variables that you need for this internal SSO will need to come from the external access policy, so I'd set those up as the user logs on to the webtop.

Hi Kevin, Thank you for your reply. yes i create a new access policy for application tunnel but the problem still persist

Okay, just to level set:

1. You have an "external" access policy that establishes the webtop (with all of the links).

    

2. You have an "internal" access policy applied to the application. It has a simple START->ALLOW visual policy, and an SSO profile assigned.

    

3. The session variables required for the internal SSO profile to work (ex. session.logon.last.username, session.logon.last.password, etc.) are created in the external access policy.

    

As a test, configure the internal application so that it can be accessed directly (from some location) and statically assign the required session variables in the internal access policy's VPE. If your SSO profile is configured correctly, you shoould be able to seamlessly SSO to the application without getting prompted for authentication.

Hi kevin, After test i found on debug this type of error "Log Message checking start uri match, start uri: '/c/portal/login;jsessionid=0142064CA98184090335BB521465D094.tomcat1?redirect=%2F&p_l_id=10505', request: '/isession?sess=95570571ddb89c0e9792b0001c65eca7&ipv4=yes&ipv6=yes&Z='"

"Log Message\N: no start uri match"

My guess here is that your SSO is not configured correctly. I would start by creating a very simple access policy that solely tests the SSO:

1. START -> VARIABLE ASSIGN -> ALLOW

Assign the username and password session variables statically in the variable assignment agent. Again, the purpose of this policy is just to test SSO, so everything else is removed. Now unfortunately this is where it gets difficult to troubleshoot remotely, as a form-based SSO can be tricky to configure and highly dependent on the server's requirements. At a minimum though, you need to capture:

1. What identifies a logon form (a specific URI, cookie, or header in the response)

    

2. What identifies the actual logon form on the page (action attribute, form order, form paramater, ID attribute, or name attribute)

    

3. What identifies a successful logon (presence of a new cookie or a redirect to a specific URI)

    

To find all of this information, you'll need to run a client side capture, access the application directly, and logon.