Share:|

One of the biggest challenge which customer face who upgrade from BAO 7.6.x to BAO 7.7 or 7.8 is that ASSO doesn't allow multiple WebApp URL, and if you try to use a CNAME, Alias, VIP or Loadbalancer (to avoid single point of failure) it will alway rewrite the URL back to registered WebApp URL, which might eventually cause a  request failure if the URL is not resolvable from out network or in some case in restricted internal network.

 

Below example is valid for scenario where a VIP or Loadbalancer are used to access the ORCA webservice to avoid single point of failure for ORCA web service.

Lets start with an example: Assume that I have BAO CDP server named "cdp.bao.local", it’s the same name which is used during installation and is been used in web app url of ASSO, I also have an HACDP and it has a name "hacdp.bao.local", I also have a loadbalancer in front of these two server to manage the ORCA requests and avoid single point of failure, LB has Alias/CNAME as "xyz.bmc.com" which I used in my code or 3rd part application to access ORCA webservice from outside the network now if I want access ORCA webservice using external url I will use "https://xyz.bmc.com:28080/baocdp/orca" however when the request reaches the server ASSO automatically rewrite the to registered WebApp URL  which is internal url in this case i.e.  "https://cdp.bao.local:28080/baocdp/orca" or "
https://hacdp.bao.local:28080/baocdp/orca" (based on where LB direct the request) which may not be accessible from outside network irrespective of whether ORCA is added in excluded URL in SSO. This is the default behavior of Atrium SSO and cannot be changed to the best of my knowledge.

To solve this if we re-register ASSO agent with external name (CNAME or Alias) or LB Name, ORCA will start to work fine however base on the way your infra is been design or number of redirection in your network you may find your self stuck in a re-direction loop in browser whenever you try to access grid console using internal url which is "https://cdp.bao.local:28080/baocdp" or
"https://hacdp.bao.local:28080/baocdp"  since URL rewrite to "https://xyz.bmc.com:28080/baocdp" or end with a message saying too many re-directions. The same happen if a CNAMEor VIP is used.

 

To resolve this problem we would have to tweak the system a bit with below mentioned trick.
What we need to do is use a Name/FQDN which is accessible internally (i.e. it can be resolved internally) and it should be accessible externally (i.e. name should be resolved to your loadbalancer IP address). Since for accessing Grid console we need a direct access so that we don't get stuck in redirect loop. however for ORCA It usually work irrespectively.

 

Below are the high level overview of the steps we will be performing.
1. Register the CDP ASSO agent with LB or CNAME FQDN lets say xyz.bmc.com
2. Add a mapping for CDP IP to Loadbalancer FQDN in hosts file of the machine from which Grid Manager will be called and Administrate through those machine.

 

HAORCA.png

 

Apart from above there is alternative option

1. Continue to use CDP and HACDP name in ASSO agent. However make the calling system resolve the CDP and HACDP name to a IP address of LB.

2. Add a hostname mapping for CDP and HACDP name to Loadbalancer IP/ VIP in the external system which are calling ORCA web service.

 

HAORCA2.jpg

 

Note :

1. This workaround would offer you kind of High Availability for ORCA webservice with single end point (for consuming in 3rd party application and custom codes) considering the fact that the requests reached the respective CDP nodes without any failure from Network and OS end, although product was not originally intended to offer High Availability for ORCA  webservices with single point to consume, as per the Product design HA grid configuration with the CDP and HA-CDP manages all CDP failures by election. That is, configuration will provides redundancy for job processing elements of the grid.

 

2. This problem has been addressed in BAO 7.9 release when RSSO will be introduce as a new authentication system since for a typical new installation RSSO will be using the same tomcat instance as BAO and there will be no URL rewrite in it.

 

 

New Workaround

-----------------------

Recent Development showed as that there is one more workaround which can be implemented by modifying the web.xml of the CDP's which will by pass the redirection for Orca, RESTful and Legacy web service. 

 

Below are the changes which we need to make in the CDP's web.xml located in ("<BAO_CDP_HOME>\tomcat\webapps\baocdp\WEB-INF\web.xml")

Change SSO agent URL pattern to /gm/* instead of /* in web.xml as shown below thereby preventing SSO JEE filter from redirecting or rewriting URL to register WebApp URL when ORCA, Legacy or Restful Web Services are called.

  <filter>

        <filter-name>Agent</filter-name>

        <filter-class>com.bmc.atrium.sso.agents.web.jee.JEEFilter</filter-class>

        <init-param>

            <!-- SSOPrincipal -->

            <param-name>principalAttrName</param-name>

            <param-value>com.bmc.ao.sso.principal</param-value>

        </init-param>

        <init-param>

            <!-- SSOToken -->

            <param-name>tokenAttrName</param-name>

            <param-value>com.bmc.ao.sso.token</param-value>

        </init-param>

        <init-param>

            <!-- Identifier from SSOToken -->

            <param-name>tokenIdAttrName</param-name>

            <param-value>com.bmc.ao.sso.tokenId</param-value>

        </init-param>

        <init-param>

            <!-- Name from SSOPrincipal -->

            <param-name>useridAttrName</param-name>

            <param-value>com.bmc.ao.sso.userid</param-value>

        </init-param>

    </filter>

    <filter-mapping>

        <filter-name>Agent</filter-name>

        <url-pattern>/gm/*</url-pattern>

        <dispatcher>REQUEST</dispatcher>

           <dispatcher>INCLUDE</dispatcher>

        <dispatcher>FORWARD</dispatcher>

        <dispatcher>ERROR</dispatcher>

    </filter-mapping> 

With this new workaround you don't have to making any further changes in the host file mapping and you would be able to use Alias, VIP and CNAME while calling webservice.