SSO across multiple domains and group membership check

Thanks Ngutierrez31. We have over 50 URLs in production and a similar number in dev, each of which will need specific LDAP group membership check to ALLOW access to. I am hoping to enable SSO across all of these and hoping that the membership check could be done during individual URL access and DENY (without NULLing the session out) if disallowed. Wouldn't this cause a bloated VPE?

If Webtops allow creation of ACEs and ACLs ahead of time (and as and when new ones need to be created via an API), I am guessing any user's full ALLOW list is created during the initial sign-on... Is that correct? If true, this might solve what I am trying to do.

Regards - Prakash

I'm not sure what you mean by "NULLing the session out" but we can avoid a bloated VPE as much as possible with the use of wildcards in the AD/LDAP query agent.

And yes, upon authentication and assignment of the webtop, only the assigned resources (based on on the memberof membership) will be available to the group and the ACL will be applied to those resources to further limit a perhaps broad resource assignment. I assume that this is what you mean by a users "allow list"?

You can limit the l4/l7 resources assigned to each group based off of the LDAP/AD memberof query result if that's what you mean by site-specific access.

After your login page and your AD auth or LDAP auth agent, use an LDAP/AD query agent in the visual policy editor and make a unique branch ending for each different result of the configurable memberof query. See the below document for information about the LDAP/AD query agent.

https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-authentication-single-sign-on-12-1-0/3.html

You can then use the advanced resource assign agent to assign unique portal access or application access resources based off of the result of the query agent. If you'd prefer to assign a network access resource with broad access, you can solve the granularity issue with an APM l4/l7 ACL. APM ACL's should also always be used with portal access resources.

Also take note of ensuring that no layered virtual server gets in the way of your ACL being assigned if dealing with network access resources. If so, be sure to attach the following irule to the layered virtual server in order to force the evaluation of the necessary ACL's: ACCESS::acl eval $acl_name_list.