APM Access Policy Design Using Attribute-based LDAP

Are these separate virtual servers mapped to separate domains? Do the users have separate URLs they access?

These separate virtual servers are mapped to separate domains.

 

The users have separate URLs they access.

 

Okay, so are you asking how to design one access policy that can be used in many virtual servers, or simply how to design access policies that provide access based on LDAP attributes?

 

 

Also, how are users authenticating? (ie. user/pass?)

Okay, so are you asking how to design one access policy that can be used in many virtual servers, or simply how to design access policies that provide access based on LDAP attributes?

 

 

Also, how are users authenticating? (ie. user/pass?)

I am asking how to design one access policy that can be used in many virtual servers.

 

The main issue is how to authenticate user based on which VS a user is accessing since each VS has a different LDAP filter requirement.

 

 

Users are authenticating with just user/pass.

 

Okay, one last question (hopefully). When you say "domain", do you mean active directory domain or fully qualified domain? Are all LDAP calls to the same AD or different ADs based on the virtual server the user accesses?

We use ADAM (Microsoft AD Application Mode), which is an attribute-based LDAP server.

 

All LDAP calls are going to the same LDAP server group.

 

The domain I referred to is the FQDN.

 

 

To give a specific real-live example:

 

mba.domain.com is a portal access for MBA students, requiring its own branding of the login page and access is restricted by user account with appropriate attribute (mba_portal_access=TRUE)

 

law.domain.com is a portal access for law students, requiring its own branding of the login page and access is restricted by user account with appropriate attribute (law_portal_access=TRUE)

 

There may be some students enrolling in a joint-degree program such as MBA/Law degree.

 

 

idp.domain.com is a typical shibboleth application that should be accessible by all portal users.

 

owa.domain.com is a typical web mail application that should be accessible by anyone (I simplified it so that it is accessible by portal users for now).

 

Access scenario 1:

 

A user accessing https://mba.domain.com will be redirected to https://login.domain.com for APM login which should be displaying the MBA branding login page. After the authentication and authorization process, user is SSO into the MBA portal. If the user clicks on an e-mail link inside the portal, APM will SSO and launch the https://owa.ubalt.edu/owa link. If a user is joint-degree student, he or she can go to https://law.domain.com and automatically SSO by the APM.

 

Access scenario 2:

 

A user accessing https://law.domain.com will be redirected to https://login.domain.com for APM login which should be displaying the law branding login page. After the authentication and authorization process, user is SSO into the law portal. If the user clicks on an e-mail link inside the portal, APM will SSO and launch the https://owa.ubalt.edu/owa link. If a user is joint-degree student, he or she can go to https://mba.domain.com and automatically SSO by the APM.

 

Access scenario 3:

 

A user accessing https://owa.ubalt.edu/owa will be redirected to https://login.domain.com for APM login which should be displaying the generic login page. After the authentication and authorization process, user is automatically SSO into the OWA.

 

I finally fnished setting up my APM logic for LTM access. The only thing left is the look and feel.

 

Thank everyone!