For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Patrick_Norde's avatar
Patrick_Norde
Icon for Nimbostratus rankNimbostratus
Oct 14, 2015

Assign APM webtop without redirecting to it

Hello all,

 

i am working on an APM implementation and facing some problem that does not easily solve itself. Let me describe the situation: Customer wants to publish 2 websites that need authentication using APM. They also want to allow access to a webtop where employees may access other applications, including the published websites.

 

We have built three virtual servers. Two virtuals which allow access to the published websites. These virtuals have been assigned a pool that contain the webservers and also an APM access profile. We have also built a third virtual server that has been assigned the same APM access profile as the other virtual servers.

 

The customer wants employees to be able to perform the following: - Access one of the published websites, get authenticated and get access. - Because an employee was authenticated in the previous step, they may also access (without further authentication) the second published website. - After going to the published websites an employee must also be able to open the webtop portal and access applications from there, again without further authentication.

 

When having built the configuration as described above, when a user has been authenticated to the published application and is going to the portal webtop we see that this cconnection is being reset by the F5. This may be caused because the webtop resource was not assigned in the first place. Would it be possible to assign it "dynamically" at some later moment ?

 

Thought to solve it by assigning the webtop for all applications, also for the public websites. However, in this case a user will always be redirected to the webtop. It seems that the webtop cannot be suppressed so that we can perform a redirect to the original website that the user was requesting in the first place.

 

Having tried many "clever" configuration steps, searched DevCentral, i do not have any idea at this moment how to solve this... However, there must be someone who has faced the same situation before, or not ?

 

application delivery
BIG-IP Access Policy Manager (APM)
deployment
LTM
security

3 Replies

  • EmBee_57573's avatar
    EmBee_57573
    Icon for Nimbostratus rankNimbostratus
    Oct 14, 2015

    hi, maybe you can use an irule in which you craft a condition with access:::disable

     

  • EmBee_57573's avatar
    EmBee_57573
    Icon for Nimbostratus rankNimbostratus
    Oct 14, 2015

    hi, maybe you can use an irule in which you craft a condition with access:::disable

     

  • Walter_Kacynski's avatar
    Walter_Kacynski
    Icon for Cirrostratus rankCirrostratus
    Oct 15, 2015

    I have done this with the following iRule:

    when ACCESS_POLICY_COMPLETED {
    set sid [ACCESS::session data get "session.user.sessionid"]

    switch [ACCESS::session data get "session.policy.result"] {
        "allow" {
            switch -glob [ACCESS::session data get "session.server.landinguri"] {
                "/saml/idp/profile/redirectorpost/sso" {
                     If the logon is being driven by a SAML request then don't interfere with the default redirect logic
                }
                "/webtop" {
                     If the user has requested the webtop explicitly then don't interfere
                }
                default {
                     Instead of going directly to the WebTop send the user to their original URL.
                     They can get back to the WebTop by going to /webtop via the redirect handled in ACCESS_ACL_ALLOWED
                    if { [ACCESS::session data get session.assigned.webtop] starts_with "/Common/" } {
                        if { [string length [ACCESS::session data get session.server.landinguri_base64]] != 0 } {
                             session.server.landinguri_base64 is for release 11.5.1
                             Handle Multi-Domain Authentication Landing URI
                            ACCESS::respond 302 Location "[ACCESS::session data get session.server.network.protocol]://[ACCESS::session data get session.server.network.name][ACCESS::session data get session.server.landinguri_base64]"
                        } elseif { [string length [ACCESS::session data get session.server.multidomain_host]] != 0 } {
                             session.server.multidomain_host is for release 11.6.0
                             Handle Multi-Domain Authentication Landing URI
                            ACCESS::respond 302 Location "[ACCESS::session data get session.server.network.protocol]://[ACCESS::session data get session.server.network.name]/F5Networks-SSO-Req?SSO_ORIG_URI=[b64encode [string range [ACCESS::session data get session.server.landinguri] 33 end]]"
                        } else {
                             The Request originated on the Primary Auth URL / Single Domain Auth
                            ACCESS::respond 302 Location "[ACCESS::session data get session.server.network.protocol]://[ACCESS::session data get session.server.network.name][ACCESS::session data get session.server.landinguri]"
                        }
                    }
                }
            }
        }
    }
}

when ACCESS_ACL_ALLOWED {
    switch -glob [HTTP::uri] {
        "/webtop" {
             Allow the user to get back to the webtop if they navigate to a backend server
            ACCESS::respond 302 Location "https://[HTTP::host]/vdesk/webtop.eui?webtop=[ACCESS::session data get session.assigned.webtop]&webtop_type=webtop_full"
        }
    }
}