Making ESS available to WWW

We contacted Lawson support about the recommended settings for this and they replied that it is not documented and would need to be handled by their professioanl services group. From what I've found so far it seems too simple to warrant bringing in consultants. Has anyone doen this on there own?

We have done this... but we are configured a little different here. We use a Citrix farm and everyone is expected to run their sessions from Citrix.... the techs here have made the ESS application available as an external app so we just get connected (userid/password) then click an icon that launches Portal from our intranet. Then a different userid/password gets us to ESS.

<!-- Converted from text/plain format -->

It's really a matter of putting IIS in DMZ or outside the firewall and installing the Websphere plugin to point to that server.  Then using firewall/NAT to 1) route the inside and outside users to the correct web server address and 2) restricting the traffic flow to the websphere server to onlu be allowed to come from the IIS server.
John Henley

Thanks for the feedback. I'm assuming WAS can accept connections from both the inside and outside IIS instances. We wouldn't want to break production access. Our services vendor did this setup during our LSF migration - do  you know where is the WAS plugin install for IIS is documented?

<!-- Converted from text/plain format -->

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/tins_manualWebIIS.html
John Henley

Has anyone had issues with yahoo toolbar or google toolbar or other items causing users issues with access to ESS from off home? Or what browser xml patches, etc. does the home user need to install on their pc for this to work with ESS in LSF9 the xhrnet version.

Yes, we have had issues with esp the pop-up blocking features of these toolbars and even pop-up blocking from the OS. I think if you turn off pop-up blocking for the affected sites, you'll have a lot better luck.

What about any xml patches for IE? Are there any required for the home user to install?

We are bracing for the help desk calls since there are seemlingly infiite combinations of software versions and settings on home computers. There were a number of XML patches that addressed Portal issues a few years back and we had to patch many of our internal systems. I believe Microsoft has rolled these up for W2K and XP now so if the home users have windows updates turned on like we do at corporate they should be ok. I have not have to apply any patches to fix IE for Portal in 2 years now. Wonder how Vista Home edition will behave?

Has anyone had trouble with the redirect when referencing their external server by IP? We're getting the "Portal cannot load without a fully qualified URL" msg when we try to connect to the external IIS webserver instance via IP. If we try to connect to the external by server name it will only work from from inside our FW - outside the connection fails. The endpoint must be taking care of it as the redirect msg is not displayed if we user servername . I wanted to use IP rather than have our ISP add our servername in their DCHP list. Thanks.

I've seen that message, inside the firewall. We were in the habit of using a unqualified host name, and now we have converted to using the full hostname in the URL.

You need to have both the internal and the external IP resolve to the FQDN.

Thanks. The way we are currently set up, if we use IP to connect it tries to do the redirect to the lawson server FQDN but if we use server name is passes through to the SSO login screen without the redirect. We've asked our ISP to set up our servername to resolve to the external IP so we can connect by name from outside. Aside from the redirect being annoying, conencting by IP will never work from outside our domain - the redirect would fail since our lawson server name is not public. The next step will be to get HTTPS working. We have our cert installed and opened up the https port - is there anything needed on Lawson side for this to work?

We've almost got this working after alot of tinkering with the endopoints in ssoconfig. A Lawson KB article indicates that an https cert needs to be installed on both the internal and external webserver assumedly since the internal wil be using https for authentication only. We only bought one cert and installed it on both. The external works great, but portal connections to the internal now complain about an invalid cert (it does let you log in after that). Has anyone been able to get the internal webserver to inherit the cert from the external or are we faced with ordering another cert from verisign for our internal webserver even though we're not really using it for https connections?

An update for the group - To resolve the cert issue we removed the "shared" Verisign cert on the internal and created a user defiuned one (only the external needs to be certified). Then we pushed out a trust for the new cert to our corporate systems via GPO. As for HTTPS - since we changed the url's for both our internal and external webservers to https we decided to change the SSOP service to us "HTTPS always" rather than "HTTPS for login only" as directed in the Lawson KB article on configuring LSF9 for SSL and multiple webservers. By doing this we can fully block non https ports regardless of which iis server the user is connecting to.

Joe, we are planning to undertake this project at my organization as well. Did you only have to install IIS and WAS (application server or network deployment) on the external webserver? I know you would then add and configure the additional endpoints. Any info you have would be helpful.

Thanks,
Eric

Yes we had to install some of the Websphere components and IIS on the external machine. Do not underestimate this project - it sounds fiarly simple but can turn out to be a pain. We found that there are some quirks with ssoconfig and no way of listing the endpoints that were previously configured so if an incorrect endpoint was entered you you'll need to remember exactly what it was in order to remove it. I'm not sure if this is a bug or what but entering a corrected endpoint does not fix the bad one. We went around on this for some time before erasing all the endpoints and starting over to get it working properly. Once the endpoints are all set correctly we went back to https for login only so you can ignore my earlier comment on using https always on the internal - stick with the lawson recommended setting. HTTPS always will work, but nothing is cached so performance suffers on low bandwidth connections. There are also 2 env patches you may need. One for portal and the other is a large LSF9 rollup. We were getting redirected to https and getting a security error when internal users clicked logoff button. It took me a week and a half in LIS before the GSC told me about these. Good luck!

Joe, Did you look at just putting just the IIS web server on the external side vs. IIS -AND- WebSphere?

No, but let me clarify. It's my understanding that you need the websphere plugins on the external machine with IIS - not a full Websphere install. The other thing is how you handle the IIS homedir (webdocs) folder. Right now I have a copy of it locally on the external machine but I would like to change this to point back to the internal webdocs folder so I don't have to apply patches in both places moving ahead.

That is correct--WAS plugins on the external server. You only need one WAS ND.

---

From: forums-lsf-s3-sys-admin@lawsonguru.com
To: John Henley
Sent: Mon Nov 24 15:19:14 2008
Subject: RE: Making ESS available to WWW (729eab78-5f62-4506-9b36-901646d52a5e)

S3 Systems Administration Forum Notification
A message was posted to a thread you were tracking.

Joe O'Toole Posted:11/24/2008 6:19 PM

Subject: RE: Making ESS available to WWW No, but let me clarify. It's my understanding that you need the websphere plugins on the external machine with IIS - not a full Websphere install. The other thing is how you handle the IIS homedir (webdocs) folder. Right now I have a copy of it locally on the external machine but I would like to change this to point back to the internal webdocs folder so I don't have to apply patches in both places moving ahead.

---

You may reply to this thread via e-mail; please do not remove the message tracking number from the subject line, and do not include this message in your reply. To view the complete thread and reply via your browser, please visit:
https://www.lawsonguru.co...et/5553/Default.aspx

You were sent this email because you opted to receive email notifications when someone posted and/or responded to a message on this forum.
To unsubscribe to this thread please visit your user profile page and change your subscription options.

Thank you,
LawsonGuru.com

We would like to do the same thing, but we do not have IIS involved in our current process.  We have our portal on an AIX box... behind our internal firewall.  How can we do this to allow ESS access from WWW?  Do we put the plugin.cfg on an apache server in the DMZ and it will route the WWW traffic into the ESS on our portal server?  What about internal traffic, will it have to go through the apache server in the DMZ or will internal traffic just go directly to the current internal AIX portal server?

Thanks in advance
Dean-O

Ok, here is what we are trying to do (Dean and I work for the same company).

First thing we tried to do was to basilcy offload the SSL to a Citrix Netscaler 9.0 device. I created an external VIP (virutal IP) and assigned it a SSL certificate. I then pointed it to the internal WAS/LSF server. when I goto https://servername.domain.com/lawson/portal/, I get redirected to http://servername.domain.com/lawson/portal/, which wont work because we dont have a VIP for port 80, we need to run this over HTTPS.

My next thought would be to have the netscaler offload SSL traffic for both internal and external users. Create 1 VIP and have it use SSL, and point all internal and external users to it, and then reconfigure the WAS/LSF to use that host name on port 443. So, both internal and external people would goto https://lawsonportal.domain.com. The 2 problems we have are, 1 - we/I dont know where/how to change it from 'servername' to 'lawsonportal' and 2 - how to tell it to use https vs http.

I really think using another server in the DMZ is overkill. I dont really understand the WAS/LSF piece, but I would have to belive this cant be this complicated. I have a dozen other things that I offload the SSL using the Netscaler w/o a problem.

Somewhere is the site, its compairing the actual client URL to the configured URL.

Any help on this would be great!

Thanks!

Brian Danford

There is a Lawson KB article on this: http://kmcollections2.law...EXAMPLE_INFOPATH.HTM

I don't think it's exactly what you're trying to do, but I think it gives you an idea...probably that you need to re-configure the endpoint to be SSL only.

We used this article as well, it's not very detailed in some repsects, but  the smoketests are invaluable for determining if you have SSO configured correctly. I'm not sure if it works the same way on AIX and Windows, but one of the biggest problems for us was getting incorrect endpoints out of the definition. I would recommend documenting what is typed in so you can easily remove them. We found out the hard way that updating them is not the same as removing and re-entering the values.