clientless - sso

Your thread title actually suggests the answer. You can use the clientless-mode header in the HTTP_REQUEST event, collect the payload if it's a POST request (and a specific URI?), and then process the values inside the access session from ACCESS_SESSION_STARTED and beyond. Clientless-mode will allow youto pass through and evaluate an access policy without the initial 302 redirect to /my.policy. The biggest downside of clientless mode is that you can't do any interactive functions in the policy (ie. logon forms, message boxes, and some other things). Here's an example:

when HTTP_REQUEST {    
    HTTP::header insert "clientless-mode" 1        
    if { ( [HTTP::method] equals "POST" ) and ( [string tolower [HTTP::uri]] starts_with "/auth" ) } {        
        HTTP::collect [HTTP::header Content-Length]              
    }      
}    
when HTTP_REQUEST_DATA {    
     parse the XML payload in request        
}

would we be able to auth the users credentials??

 

Absolutely. Collect the attributes from the payload in the HTTP_REQUEST_DATA event, assign to local variables, and then assign them to session variables in ACCESS_SESSION_STARTED. From there you can do whatever auth/query you need within the policy evaluation.

 

So first let me back up and say that clientless-mode won't allow you to use a login page in the policy. So then the client will post their credentials in the XML, the iRule will pick these up, assign them to APM session variables, pass those to an auth agent, and then perform any additional policy evaluation requirements (ex. LDAP query more group membership). The access session will be assigned and a cookie sent to the client on the first response from the back end server. Here's an example:

when HTTP_REQUEST {
    HTTP::header insert "clientless-mode" 1
    if { ( [HTTP::method] equals "POST" ) and ( [string tolower [HTTP::uri]] starts_with "/auth" ) } {
        HTTP::collect [HTTP::header Content-Length]
    }
}
when HTTP_REQUEST_DATA {
    foreach x [split [HTTP::payload] "&"] {
        switch -glob $x {
            "username=*" {
                set username [lindex [split $x "="] 1]
            }
            "password=*" {
                set password [lindex [split $x "="] 1]
            }
        }
    }
}
when ACCESS_SESSION_STARTED {
    if { [info exists username] } {
        ACCESS::session data set session.logon.last.username $username
    }
    if { [info exists password] } {
        ACCESS::session data set session.logon.last.password $password
    }
}

Now granted, this is a very simple test where the client is simply posting credentials.

curl -v http://10.70.0.100/auth.php -d "username=bob.user&password=password"

But hopefully you see where I'm going with it. Collect the payload in the HTTP_REQUEST_DATA event, set some local variables, collect those local variables in the ACCESS_SESSION_STARTED event and send them to access session variables, then use those access session variables within the access policy to auth and/or query. You can drop an AD auth right into the visual policy with this example. If successful, the request will pass through to the back end server, and on first response the client will get the APM session cookie.

i get it now.. but i have a follow-up qns.. for the future state F5 login page, once authenticated, we have an iRule that based on a URI, we switch to different pools... This request would always hit the /auth URI..

could i disable the APM portion (login page and all - ACCESS::disable) and bounce it to a different VS that handles the auth portion and everything else mentioned above??

when ACCESS_ACL_ALLOWED {
    switch -glob [string tolower [HTTP::uri]] {
        "/" - 
        "/nhl/*" - 
        "/nba/*" - 
        "/mlb/*" {pool Pool_us-sports}
        "/auth/*" {
            ACCESS::disable
            virtual vs-xml-posting
            }
        default {pool Pool_other-sports}
    }
}

and once it bounces to that other VS i could have a APM policy that does auth and sso and the iRule to pull the info would be like this -

when HTTP_REQUEST {
    HTTP::header insert "clientless-mode" 1
    if { ( [HTTP::method] equals "POST" ) and ( [string tolower [HTTP::uri]] starts_with "/auth" ) } {
        HTTP::collect [HTTP::header Content-Length]
    }
}
when HTTP_REQUEST_DATA {    <u+200e>
<u+200e>     parse the XML payload in request  <u+200e>
<u+200e>        set username [findstr [HTTP::payload] "" 13 "<lt; HTTP_REQUEST {
    HTTP:"]<u+200e>
<u+200e>        set password [findstr [HTTP::payload] "" 6 "ode" 1
    if { ( [HTTP::met<lt;<u+200e>        set password [fi"]<u+200e>
<u+200e>        log local0. "Username - $username , Pwd - $password<u+200e> "
<u+200e>}<u+200e>
when ACCESS_SESSION_STARTED {
    if { [info exists username] } {
        ACCESS::session data set session.logon.last.username $username
    }
    if { [info exists password] } {
        ACCESS::session data set session.logon.last.password $password
    }
}

<u+200e> <u+200e> log local0

What do you think????l0. "Username - $user

Would you need to do all of that? Assuming that the FIRST request is a POST to "/auth" with credentials, subsequent requests should all come with the session cookie, so that:

 

1. You could technically only enable clientless-mode for this request, and

    

2. Simply set the pools in the ACCESS_ACL_ALLOWED event for everything.

    

All subsequent requests will have the session cookie, so they should all skip to the ACCESS_ACL_ALLOWED event. You might also want to send a "reject" response if the user attempts to request a URI other that "/auth" without the session cookie.

 

mmmmmmm.. good point.. just have it all in one iRule...

 

I would actually want the future request to other URIs to use the initial session cookie.. the POST sends info to our servers, and we spit back a couple of links to other URIs so when the user gets it, they click on it and should already be auth'ed..

 

thanks Kevin..