Add portal application

Access Gateway applications can use policy and specialized policy configuration to create portal applications. In a portal some, or the bulk of traffic, is handled by a single back end, but other traffic is routed to specific back ends based on access policy and URI requests.

This guide details how to configure a header based application to route traffic to different back ends based on specific URI requests.

Architecture


In this architecture an end user requests a resource which is composed of the core URL, in this example www.myportal.com, and specific resources, everything to the right of the /. Access Gateway, using policy and additional configuration, then routes requests to one of several back ends. In this example any requests of the form www.myportal.com/2nd would be routed to 2ndbackend.myportal.com Likewise, requests of type www.myportal.com/3rd to 3rdbackend.myportal.com and all others to backend.myportal.com. This guide will take you through the configuration of the header application and associated resources to configure such a portal application.

Rewriting concepts and examples

Portal applications use custom policy, along with configuration, to define rules to access multiple back ends. Typically there is a default policy which redirects all URI's not referenced in other policy to the default back end application. Additional policy statements, along with their configuration, rewrite requests and redirect to other back end applications.

Examples and expectations:

The following examples describe user requests, what we would normally expect as the behavior behind the request, and provide examples of the inbound and outbound rewrites.

User request Expected behavior

Inbound & outbound rewrites

myportal.com/ Redirect to backend.myportal.com. backend.myportal.com
myportal.com/
myportal.com/abc.htm Redirect to backend.myportal.com/abc.htm. backend.myportal.com/abc.htm
myportal.com/abc.htm

myportal.com/2nd Redirect to 2ndbackend.myportal.com based on /2nd. 2ndbackend.myportal.com
myportal.com/2nd

myportal.com/2nd/efg.html Redirect to 2ndbackend.myportal.com based on /2nd.
Strip /2nd on inbound rewrite. Add /2nd back on out bound rewrite.
2ndbackend.myportal.com/efg.htm
myportal.com/2nd/efg.htm
myportal.com/3rd Redirect to 3rdbackend.myportal.com based on /3rd. 3rdbackend.myportal.com
myportal.com/3rd

myportal.com/3rd/hij.html Redirect to 3rdbackend.myportal.com based on /3rd.
Strip /3rd on inbound rewrite. Add /3rd back on out bound rewrite.
3rdbackend.myportal.com/hij.htm
myportal.com/3rd/hij.htm

More specifically:

Policy

Description

Default


The default policy is applied to all requests which don't match some other specific policy. The default policy causes requests to be rewritten against the default application domain and then forwarded to the back end application. After the request is serviced the result is rewritten back to the original domain and returned.

Re-write policy 2nd


Each subsequent back end includes a policy and advanced configuration to re-write requests as required. The policy itself specifies the URI root that triggers it. In this example URI would be /2nd. Rewriting rules would the remove the URI as well as redirect to a secondary back end application(2ndbackend.myportal.com in this example).

Re-write policy 3rd


Each subsequent back end includes a policy and advanced configuration to re-write requests as required. The policy itself specifies the URI root that triggers it. In this example URI would be /3rd. Rewriting rules would the remove the URI as well as redirect to a secondary back end application(3rdbackend.myportal.com in this example).

 

 

Before you begin

  • Determine the external URL used by the application, in this example www.myportal.com
  • Determine the universe of possible URIs, and their associated back ends.
    In this example:
    www.myportal.com/2nd > 2ndbackend.myportal.com.
    www.myportal.com/3rd > 3rdbackend.myportal.com.
    And all others to backend.myportal.com.
  • Determine all required header attributes required for authentication.

Typical workflow

Task

Description

Create a containing group
  • Best practice, create an optional group to be assigned to the application.
Create header application
  • Create a header application which defaults to the shared common back end.
Assign certificate to a portal application
  • Assign an optional certificate to the application.
Add additional attributes
  • Add optional, but often necessary, additional attributes to the application.
Add required access policy
  • Add all required policy for all serviced URIs
Test the application
  • Test the application using header and policy simulation.