Managing the URL namespace
The task of a reverse proxy is to enforce access restrictions and forward authorized requests to different services. The URL namespace of the reverse proxy therefore needs to be mapped to the URL namespaces of all the content providers integrated behind nevisProxy.
URL namespace
This means that there must be a mapping between the request URL (on the reverse proxy) and the URL used by the reverse proxy to access the content provider as well as a (preferable) simple way to define which resources in the backend system are protected and which resources may be accessed without any authentication.
URL Glossary
The following samples clarify the URL glossary used:
http://www.company.com/location/resourceis a fully qualified URL- /location/resource is an absolute URL
- './location/resource1' or '../../location/resource2' or 'location/resource3'are relative URLs
The following main design issues should be considered when defining the reverse proxy namespace. (Note that all samples are referring to the setup shown in the section "Sample setup".):
| Rule | Consequences | Problems |
|---|---|---|
| Direct or requesturi mapping:Try to map the content provider's URL namespace (e.g., /appl1 and /appl2) directly into the reverse proxy's root namespace by using matching servlet mappings (i.e., /appl1 and /appl2). This mapping type is referred to as requesturi mapping. | The following link types are working without rewriting:- absolute URLs- relative URLsMultiple servlet mappings (e.g., /appl1 and /appl2) may use the same connector). Cross links and browser bookmarks remain valid. | The content provider's required top namespace (e.g., /appl1 and /appl2) needs to be available on the reverse proxy's URL namespace. |
Subnamespace or pathinfo mapping:If a content provider cannot be mapped into the reverse proxy's top namespace, map the content providers root namespace into a sublocation of the reverse proxy (i.e., map http://appl3.company.com to https://www.company.com/appl3). This mapping type is referred to as pathinfo mapping. | The following link types are working without rewriting:- relative URLs | Only one servlet mapping is meaningful as /appl3/public and /another/mapping/public refer to the same content provider resource. Cross links and browser bookmarks get invalid. |
| If the application provides public resources, the namespace of the application should be designed to reflect the separation between public and protected areas as fully separated subtrees on the content provider. | Mapping security filters only on the protected subtree is possible. | Take care when defining an unprotected content provider namespace /appl3 and just applying protection filters to /appl3/appl because new sub locations on the content provider, e.g. /appl3/other_protected, are accessible without authentication. The content provider either needs to protect itself or an access restriction needs to be added to the reverse proxy configuration. For information about security role filters, see the chapter SecurityRoleFilter |
| Avoid differing namespaces on the same level, i.e., do not map a reverse proxy location /appl4_html to a content provider location /html. | Location renaming is not required, which simplifies configuration a lot. | If you would need to rename locations because a previously used reverse proxy renamed the public namespace in this way, it is recommended to adapt/enhance the content provider's namespace. If the content provider cannot be adapted, a RewriteFilter or the connector's 'URIPrefix' attribute (if available) can be used to manipulate the URL. Take care: Content rewriting and redirects will most likely not work properly in this case. |
The namespace mapping of content providers to the reverse proxies global namespace with the nevisProxy's components is shown in the following mapping overview.
