Skip to main content
Version: 7.2402.x.x RR

Sample setup

For the integration tasks explained in the task section ), the following configuration sample is used for reference.

The reverse proxy's sample URL namespace defines four applications running on three content providers (the * is a placeholder for any sublocation):

#ok: using requesturi mapping
https://www.company.com/appl1/*     -> http://svappl.company.com:8080/appl1/*
https://www.company.com/appl2/*     -> http://svappl.company.com:8080/appl2/*

#ok: using pathinfo mapping
https://www.company.com/appl3/*     -> https://svappl3.company.com/*

#invalid: using requesturi mapping
https://www.company.com/appl4/html/*-> http://svappl4.company.com/appl4/html/*
https://www.company.com/appl4/images/*        -> http://appl4.company.com/appl4/images/*

#invalid: using pathinfo mapping
https://www.company.com/appl4/html/*-> http://svappl4.company.com/*
https://www.company.com/appl4/images/*        -> http://svappl4.company.com/*

A visualization (including authentication, authorization, and caching) for this setup is shown in the following graphic:

Sample setup visualization

This setup visualizes the following:

  • /appl1 and /appl2 are residing on the same content provider and use the same connector.
  • /appl1/weak, /appl2/and /appl3/ are protected and therefore require authentication. They are all single sign-on, but depending on the security roles (AuthWeak, AuthStrong) and the order of access require an authentication stepup.
  • /appl1/weak and /appl2 in addition require the user to be an administrator (RoleCustomer). nevisProxy performs an authorization step.
  • /appl4 is used as a sample for an invalid mapping.
  • all authentication steps are performed by nevisAuth, and the required login pages are rendered locally by the reverse proxy (no unauthenticated access into intranet required).
  • /appl1 and /appl2 as well as the nevisAuth access are using the nevisProxy failsafeness feature.
Last updated on