Symantec Access Management

I'm exploring the option of front ending WebLogic and WebSphere with the CA SPS, technically it is possible since the SPS is nothing more than Apache with the SM agent and tomcat acting as an HTTP forwarder to the back end applications. Based on the reseach that I've done so far, it seems like WebLogic and WebSphere recommends that the HTTP Plugin be installed on Apache, which is an HTTP module that runs on Apache to provide better performance and load distribution to the back end WebLogic or WebSphere app servers. In order to install the mod_wl_20.so module, the .so file needs to be loaded in Apache which I'm not sure is supported in the CA SPS. My question is, have any of you had the experience of front ending WebLogic or WebSphere with the CA SPS without the HTTP plugin? I would really apprecaite your thoughts on this use-case. Thanks, Michael

Anyone have any experience to offer mjeanjacques?

Michael Jean-Jacques wrote:

 

I'm exploring the option of front ending WebLogic and WebSphere with the CA SPS, technically it is possible since the SPS is nothing more than Apache with the SM agent and tomcat acting as an HTTP forwarder to the back end applications. Based on the reseach that I've done so far, it seems like WebLogic and WebSphere recommends that the HTTP Plugin be installed on Apache, which is an HTTP module that runs on Apache to provide better performance and load distribution to the back end WebLogic or WebSphere app servers. In order to install the mod_wl_20.so module, the .so file needs to be loaded in Apache which I'm not sure is supported in the CA SPS. My question is, have any of you had the experience of front ending WebLogic or WebSphere with the CA SPS without the HTTP plugin? I would really apprecaite your thoughts on this use-case. Thanks, Michael

No experience with SPS, but maybe you can extrapolate.

We have tried front-ending WebSphere with a HTTP Reverse Proxy using a standard web agent, along with the WebSphere Application Server Agent (ASA) on WebSphere, and the WebSphere application works great.

On a different application, we have tried only using the ASA on WebSphere, with no front-end proxy or agent, and the application never worked right.

I believe the ASA documentation previously stated that a standard web agent proxy was required to front-end WebSphere, but current implementations no longer require the front-end web agent proxy.

Based on our experience, the front-end porxy with a standard web agent is still required.

Dear All,

We are also exploring the option of front ending WebLogic with CA SPS ... can you please help to share the information if you have find anything.

Thank you

SPS acts as a proxy. We need not deploy any other external proxy modules OR plugins on SPS.

We define in SPS proxyrules.xml where the request needs to be proxied to. A sample proxyrules.xml is as below.

Proxy Rules with hostheaders.

###################################

[root@spsproxy-test1 ~]# more /ProgramFiles/CA/Agent-for-SharePoint/proxy-engine/conf/proxyrules.xml

<?xml version="1.0"?>

<?cocoon-process type="xslt"?>

<!DOCTYPE nete:proxyrules SYSTEM "file:////ProgramFiles/CA/Agent-for-SharePoint/proxy-engine/conf/dtd/proxyrules.

dtd">

<!-- Proxy Rules-->

<nete:proxyrules xmlns:nete="http://www.ca.com/" debug="yes">

<nete:cond type="host" criteria="equals">

        <nete:case value="sp1.spsproxy-test1.sps.com:80">

                <nete:forward>http://sharepointmac1:2000$1</nete:forward>

        </nete:case>

        <nete:case value="sp1.spsproxy-test1.sps.com:443">

                <nete:forward>http://sharepointmac1:2000$1</nete:forward>

        </nete:case>

        <nete:default>

                <nete:forward>http://www.aol.com$0</nete:forward>

        </nete:default>

</nete:cond>

</nete:proxyrules>

###################################

Now the nete:forward could hold a URL which is a proxy to weblogic or websphere. Where websphere.sps.com is the front end URL and websphere.com is the actual backend websphere server.

       <nete:case value="websphere.sps.com:80">

                <nete:forward>http://websphere.com:8090$1</nete:forward>

        </nete:case>

Now try accessing http://websphere.sps.com/snoop

This should send the request to SPS and inturn SPS should proxy to Websphere for retrieving /snoop.

Do not forget to define a new VH in Server.conf for 'websphere.sps.com'.

Try this and let know.

NOTE : This is only catering the basic proxy function. This does not speak about any further deeper integration aspects.

Regards

Hubert

Hi Hubert,

we have an end application deployed in such a Weblogic cluster. So the forward has to happen on weblogic cluster ( which is defined in the so file). SInce we cannot import any so file on the SPS, how can we redirect/forward to the weblogic cluster. Any insight would be really helpful.

Regards,

Robab

Thank You Robab

I think the simple answer is we need to start thinking SPS as a single unified component instead of breaking it down as Apache / Tomcat. I understand it is difficult given the fact that it is design that way. Since CA ships SPS as a bundled one single product, integration between different components within SPS is tightly coupled. Therefore the current design does not support nor provide the flexibility to incorporate any 3rd party modules into the mix. Hence trying to look at a option to deploy the plugin within SPS may not work nor would be support by CA and it may cause detrimental impact to other functionality of SPS.

If we wish to use the capabilities and features of a ProxyPlugin which is shipped with Weblogic or WebSphere, I would recommend we would need to have a WebServer (which would act as a Software LB) in between SPS and App Server Cluster.

SPS1 -->> Apache (acting as Software LB with Weblogic Plugin) -->> Weblogic Cluster.

The proxyrules.xml on SPS1 would have the definition of apache webserver. Therefore for the SPS the backend would the Apache WebServer (Acting as Software Loadbalancer for Weblogic Cluster).

Alternatively, if you'd wish to have this feature incorporated to support add-on module and have that inter-working with current design - an Enhancement Request would be the way to go. This would go into evaluation and prioritization based on the market acceptance and business justification process before it comes into Engineering work stack. Hence this involves time to delivery.

Regards

Hubert

Robab and Hubert,

Great discussion on this topic! Hubert, I definitely agree with you in terms of looking at the SPS as on single product (Apache with Tomcat) and if add-ons were added to the product there are no guarantee that it would be scalable or even supported by CA. I think there definitely need to be an enhancement request to look at the feasibility of incorporating installing the WebLogic or WebSphere HTTP plugin.

With that being said, I looked at a few other options and I believe if you are using F5 BIG-IP, the following architecture should work:

USER --> F5 LB --> SPS --> F5 LB (Configured for WebLogic) --> WebLogic Cluster

See this pdf on how to front end WebLogic with F5

http://www.f5.com/pdf/deployment-guides/weblogic-iapp-dg.pdf

thanks Hubert and mjeanjacques.

The idea is to point to weblogic cluster directly from the SPS. In the present setup the client has OHS with apache plugin pointing to the weblogic cluster. Both your approach suggest extra components to be installed in front of the present component. I really dubt the client will accept the solution.

Also on another note, SM doesnot have an agent for F5 and hence directly protecting F5 is also not possible without SPS in front of it?

Regards,

Robab

Thank You Robab

As you suggested the current solution is OHS (with plugin pointing) to weblogic cluster. There is no extra component which needs added on. The current solution stays as it is. Example...

Current Solution.

OHS (with plugin) ==>> Weblogic Cluster.

Proposed Solution.

SPS ==>> OHS (with plugin) ==>> Weblogic Cluster.

Hence the additional component is SPS. I think it is all about understanding what a product does and not assuming by just looking at different components. My assumption is that the customer has been misguided by the fact that SPS includes apache. Thus the apache embedded within would work the same way as a unbundled apache would work.

The purpose of SPS is far wider than just acting as a proxy to a cluster. It is a gateway and a solution. There are CA Solution applications which are bundled within SPS e.g. Federation App, Auth Az WebServices, SessionAssurance etc. All these apps function within the SPS layer in conjunction with apache / tomcat / siteminder agent. Hence as I mentioned earlier, the component within SPS are tightly coupled, to maintain the integrity of Gateway / Solution that these Apps provide.

Thus from a customer perspective, it is about divulging the "Right Information" and thus setting the "Right Expectation".

Again as we concluded in our earlier thread, this is not the end. We could always raise an Enhancement Request to have it supported in future. Please work with Customer and CA Account Manager to have the Enhancement Request raised. When the Enhancement Request is delivered in a future release of SPS, you could get rid of the OHS layer.

Hope this should help you move ahead.

Regards

Hubert

In addition to Hubert's comment, the enhancement request need to be submitted via communities.

The specified item was not found.

Product manager will review the enhancement request idea once it submitted.

Regards,

Kar Meng

I think the best approach depends on what your real requirement is. You say that the customer already has OHS with the proxy plug-in in front of Web Logic.

If the requirement is to provide SSO to the customer's application on Web Logic, I think the best approach is simply to install a web agent on the OHS.

If you are using the SPS for other applications, you will still get single sign-on between these applications and the Web Logic applications as web agent and SPS receive session cookies from same policy server.

My view on WebSphere and WebLogic is to use the front end web server and proxy plugin recommended by IBM or Oracle respectively. That way you should be fully supported by IBM/Oracle for any application server issues. Then deploy the SiteMinder web agent on the web server to provide SSO. Most likely you will also deploy the SiteMinder application server agent on the application server as well.

Thanks everyone for your valuable input.

We actually wanted to replace the OHS with SPS and not put SPS in front of OHS.

Also as suggested by kenpe, yes we can use the approach of intalling a web agent on the OHS, though we want to remove any dependancy on oracle, hence will want to replace the OHS all together.

Hi Robab,

As SPS components (apache, tomcat) are tightly coupled, replace the OHS with SPS is not supported as we cannot treat SPS as a single Apache component. The Application server plugin will not work on SPS or might behave differently compare to deploy the plugin to standalone apache. We understand the requirement on your side but this cannot be achieved at the moment. I forseen this is an interesting feature that we can enhance in future release.

Regards,

Kar Meng