APM OWA 2010 webful/webreadyl

Are you talking about directing requests to different pools based on LDAP group membership? Do you also need SSO?

Maybe one of the easiest thing would probably be something like this:

when ACCESS_ACL_ALLOWED {
    switch -glob [string tolower [ACCESS:data get session.ldap.last.attr.memberOf]] {
        "*groupa*" {
            pool groupa_pool
            WEBSSO::select groupa_sso
        }
        "*groupb*" {
            pool groupb_pool
            WEBSSO::select groupb_sso
        }
    }
}

The idea here is that, at the end of the access policy evaluation and every request afterwards, you'll switch on the group membership value obtained form the LDAP query, and then 1) send the request to a specific pool, and 2) select a specific SSO profile. The above is just an example, so your specific implementation might be different based on how you query LDAP and what you're looking for. In 11.4+ you can use the LDAP Group Resource Assignment agent in the VPE to select resources (like a pool) based on group membership, but you'd still have to use an iRule to select an SSO profile.

HI Kevin, here I'm one step before : I'm trying to configure the OWA portal and the "normal" authentication action using LDAP with SSO.

I didn't find on the APM configuration where I can use an owa template page instead of the standard F5 authenticaton . I've used the apm wizard and I'm having something like this:

If I try to access the VIP, I see the default auth page

and the authentication doesn't work.... Do you see anything wrong on the workflow? Regards, Mauro

Okay, so let's trace through this config.

1. The user accesses the APM VIP and is presented with a logon form
2. The supplied credentials are used to perform an LDAP auth
3. If that's successful, you'll then need an LDAP query to get the user's membership info
4. Assuming the LDAP query is successful, use a modified form of the above iRule to select a pool and SSO profile based on the returned membership information

You may actually want to tackle this in two parts:

1. Create an access policy, assign an SSO profile, and statically assign the session variables needed for that SSO profile to work. This is simply to test the SSO profile. Assign this access policy to a VIP and statically assign the correct pool. Because you're statically assigning the session variables (ie. username and password), you shouldn't see a logon form - just SSO directly into the application. Do this for each SSO so that you know they work.

    

2. Now modify the above access policy:

    

   • Remove the static variable assignment
   • Add the logon form agent
   • Add the LDAP Auth agent
   • Add the LDAP Query agent

   • Add the SSO Credential Mapping agent (as required)

      

     Now test this with the pool and SSO profile still assigned. If it works, open the APM Reports and investigate what you get back from the LDAP query, specifically looking at the "membership" information. For AD that's probably going to be the session.ldap.last.attr.memberOf variable. Now remove the pool and SSO profile, add the iRule to the VIP, and then modify the iRule to accommodate the LDAP membership session variable and what you expect the value to be. If the LDAP query matches one of the values in the iRule, it should select the correct pool and SSO profile dynamically.

      

HI Kevin, it seems that the first part works (as I see on the APM logs "session.policy.result' set to 'allow') , but I can't access the backend application.

It seems that my portal is pointing to the / page:

    Code Feb 10 17:00:57 HQ-F307-F5-Lab info apd[9481]: 01490007:6: b2a8fc9c: Session variable 'session.logon.last.username' set to 'x1cdcdcdc'
Feb 10 17:00:57 HQ-F307-F5-Lab info apd[9481]: 01490007:6: b2a8fc9c: Session variable 'session.logon.page.errorcode' set to '0'
Feb 10 17:00:57 HQ-F307-F5-Lab info apd[9481]: 01490007:6: b2a8fc9c: Session variable 'session.policy.result' set to 'allow'
Feb 10 17:00:57 HQ-F307-F5-Lab info apd[9481]: 01490007:6: b2a8fc9c: Session variable 'session.sso.token.last.password' set to '**********'
Feb 10 17:00:57 HQ-F307-F5-Lab info apd[9481]: 01490007:6: b2a8fc9c: Session variable 'session.sso.token.last.username' set to 'x1cdcdcdc'
Feb 10 17:00:57 HQ-F307-F5-Lab debug apd[9481]: 01490000:7: AccessPolicyD.cpp func: "sendAccessPolicyResponse()" line: 1514 Msg: DONE WITH ACCESS POLICY - send 'we are done with access policy for this session' code
Feb 10 17:00:57 HQ-F307-F5-Lab debug apd[9481]: 01490000:7: AccessPolicyD.cpp func: "process_request()" line: 723 Msg:   ** done with the request processing **
Feb 10 17:00:57 HQ-F307-F5-Lab debug websso.0[13126]: 014d0001:7: constructor
Feb 10 17:00:57 HQ-F307-F5-Lab debug websso.0[13126]: 014d0001:7: webssoContext constructor ...
Feb 10 17:00:57 HQ-F307-F5-Lab debug websso.0[13126]: 014d0001:7: 16 headers received
Feb 10 17:00:57 HQ-F307-F5-Lab debug websso.0[13126]: 014d0001:7: http header *[:method][GET] (len=3)
Feb 10 17:00:57 HQ-F307-F5-Lab debug websso.0[13126]: 014d0001:7: http header *[:uri][/] (len=1)
Feb 10 17:00:57 HQ-F307-F5-Lab debug websso.0[13126]: 014d0001:7: http header *[:version][HTTP/1.1] (len=8)
Feb 10 17:00:57 HQ-F307-F5-Lab debug websso.0[13126]: 014d0001:7: http header *[:custommeta][idle timeout¨] (len=350)

where do I have to change that URI? As for sure, something is missing here on the portal/policy configuration...

thanks for your help,

Mauro

"session.policy.result' set to 'allow' just means the client side (VPE) portion of the access policy completed successfully. You still have to deal with SSO. What kind of SSO is it?

Hi Kevin, On the SSO object I've only have a credentials mapping...I've created this object using the wizard

That's not SSO. An SSO is a separate profile that you apply to the access policy that interacts with the application in some way, ie. passing Kerberos token, NTLM challenge/response, HTML form post, etc. The SSO Credential Mapping agent in the visual policy really does nothing more than prepare the session variables that will be used by the SSO profile. For example, form post and NTLM SSO generally need username and password, while Kerberos needs username and domain. You need to determine what the application requires in the way of authentication, and then select/configure the correct SSO profile.

Hi Kevin,

in this case, my OWA APM application has to intermediate between the client and the OWA application on the backend server. As I see from the configuration, I've configured (during the wizard) the SSO with the "HTTP basic" method.

which type of method do I have to use with this type of authentication? I'm wondering this could be something "standard" for OWA....form method ?

Thanks, Mauro

HTTP Basic is a standard web auth method that base64-encodes the user/pass and injects into an Authorization header to the server. It normally manifests as a popup logon box in front of the browser window. This is also one of the easier SSOs to configure, and simply requires username and password variables passed to it.

Is this how you have OWA configured to authenticate users? If you connect directly to OWA, how is the user challenged?