Making ESS available to WWW

I would recommend putting the HTTPS webserver in the DMZ and not use redirects. Anything that exposes your internal server name or IP to the outside world is an open invitation to hackers not to mention what the auditors will say. Does SSOConfig work on AIX? If so, the endpoints you define will take care of what traffic is going https vs http on the internal and external (or virtual in your case) webservers.

We got it to work by using Microsof't's ISA server to securely route requests from an outside name to the application server.  It works well.  I've also repackaged the ESS javascript js and htm files in to an iframe page the removes the requirement for the portal from home.  This way it works well from any browser and is less intensive on the system.

Making it work with the SSO LSF9 security was a bit tough but it's working.  I wouldn't mind sharing if anyone is interested.

Is this thread still alive? I cannot get the smoke test to show the external server name? Has anyone else had that problem.

Did you run ssoconfig successfully to completion? If you post the syntax you are using for the smoketest I will compare it to mine.

 I run the /ssoconfig/CfgInfoServlet on the internal server and get the internal server login and http URL.  Then I run /ssoconfig/CfgInfoServlet  on the external server (the endpoint) and still get the login and http URL of the internal server.  Is this the info you're asking about?

For ssoconfig, I have configured my primary service (SSOP) with the http and https url of the internal server.  I have it configured for https at login only.  This is the URL that is returned for both servers during the smoke test.  Whatever I set this URL to is what is returned.  It's like it doesn't even care about the endpoint.

HTTPS for login only is the correct setting, however you need to make sure you have the server name, http or https and ports set correctly for both servers in all the url strings defiuned in ssoconfig. If set up correctly, when you run the infoservlet smoketest using http and the internal server name it should return the https address on the loginurl and the http address on the httpurl. If you run the smoketest on the internal using https it will always return https for both urls. When the smoketest is run using https and the external sever name it should return https for both urls as well. There is a Lawson KB article on Multiple Endpoint Configuration - have you reviewed this?

Hopefully this thread is still sort of monitored, because we're in a similar spot here.

We want to make ESS available externally for our users, however, we'd like it to be opt in.  We'd also like to limit the external access to ESS/MSS only leaving portal/rss/etc available internally only.

Now I've got HTTPS running just fine, and we're only using a single webserver right now (all Lawson components run on seperate servers so the box only has IIS/WebSphere Plugins installed).  Our current webserver is sitting in our DMZ as well so from a logistics standpoint, I'm hoping we're ok.

Does anyone have external access deployed in their environment for only ESS/MSS and, if they do, has anyone figured out a way to make it opt-in for employees that only want to have their access available externally?

Next...

Apparently some webserver issues going on - see next post...

Posted By Joe O'Toole on 03/26/2009 02:30 PM

Posted By Joe O'Toole on 03/26/2009 01:57 PM

There are 2 different issues here. First I would make sure you really want to run "everyone" through the DMZ webserver. There are numerous reasons I would not - a few in no particular order: 1) security - if one is breached all your web access is gone. 2) patches / maint on external webserver will take all your web access down 3) Traffic - why route your internal users through the DMZ? 4) Throughput - assuming you have full HTTPS running (and this is a MUST) on the external, why force all your internal portal traffic to be encrypted with no caching when all you need is HTTPS for login only?

Some of these could be less of an issue if your application users only run LID, but sooner or later most shops will have some portal app users plus anyone using ESS/MSS must go through portal. Controlling what functionaliy they have based on point of access would also be aother tough thing to tackle since content is assigned based on user. We assign fixed content to our "ESS/MSS only" users and lock them out from changing their content through default.xml mods. In LSF I think this can be done from an admin screen as well.

As for opt-in, you would need some intercept or a different front end before the user hit portal where they could log in and agree to the terms and conditions. Then the next time they hit it it would let them through if the flag was set. We thought about doing this but decided it was not necessary at this point. Have you considered puting a disclaimer stating "by clicking on this link I understand and agree to the terms and conditions of remote access"? Good Luck!

Joe,

How do you limit external webserver only serve ESS?

We are in the spot to make Vendor self service available to WWW. Please share your experience if you have.

We are looking into using netscaler for ESS web access and saw the post from Brian and Dean.  Can I get an update on how that is working for you company.  Also, is any one else using this solution or have abandoned the idea of using it?  Thanks....

We are also getting ready to do this, but using ISA server to publish the ESS site. I have v8 working, but I am having problems with v9 and the url error message that appears.

What we are doing is using an external SSL VPN, and then the ISA to publish the webserver so it will not be directly on the internet. I see that user schlenk has got this to work and would be very interested in what he did with ISA.

 We are considering implementing ESS now as well, and I have a question along the lines of this thread that I have not seen explicitly addressed.  

We are LSF9, NT, SSO- ADAM.  All of our managers using MSS have an account on the AD (~500 users), but line-level employees all have a generic login to the AD based on their bases (65 locations).  We would prefer to not provide the other 4000 employees individual access to the AD (our helpdesk/infrastructure guys are adamantly against it), but I don't see how we can make this work with SSO.  Any suggestions?

Are you using ldapbind (i.e. SSOP password authenticates against your corporate AD)?

If so, then you will have to have new AD accounts for all of the users, as each RM ID will require a unique SSOP identity as well as XXX_EMPLOYEE identity.

Yes, we are.  I was afraid that would be the answer.  The going price for 4000 NT licenses is an expense we weren't looking forward to...

Thanks, as always for your insight.

Do you actually need to buy windows licenses to create a user in AD? They really aren't "logging in" to Windows server, are they?

I did go back and read the fine print, and you do need to obtain the licenses, based on my interpretation of the license being required for "authenticating to the server".

Hello Joe.

We've not taken this leap of faith yet and still retain all ESS access from inside the network. However, our HR group would very much like us to allow external access.

I know it's been over a year now, but how is this setup working out for you? I wonder if you would mind if I contacted you to bounce some questions on this topic off of you at some point in the future, since you've already done it and it sounds like your configuration is simialr to our own? We too have the IIS web server, Websphere, SQL and Lawson (and I believe that like yours, they too are) all on the same Windows 2003 server. Thank you.

It has worked great for us and taken some load off of our already stressed network. Many users "at home" broadband connections are faster than our private frame relay WAN and they prefer working in the the pricvacy of their own home. Security concerns are limited to employees keeping their passwords private, which is a personal responsibility and holds true for an individuals login to any website. I will PM you my email address.

We have recently been down this road and I took a little different approach. We did not modify anything on the backend other than to create a separate folder under the /web of Lawson for the new ESS which includes a couple of pages created with info. posted from Mike Schlenk which remove ESS's reliance on IE and allow all browsers except the current Opera 10.x to work

We use an ASA on the outside doing a web based SSL VPN which is tied to AD with only a link to ESS. When the user clicks on this it pulls the data through a Netscaler which is offloading the SSL and rewriting the external and internal names of the Lawson server which then pulls the new ESS page into the end-users browser. They then authenticate with a different userid and password for ESS.

I would be happy to provide more specific information if anyone would like. We do this for 12 environments as we act as an ASP.

Mike,
I'm extremely interested in what you've done. We're trying to incorporate Lawson ESS time entry form into SharePoint and are looking to bypass the portal home. If it's still available I'd love to see your js and htm files as well as your SSO solution for LSF9. I've successfully retrieved the JSESSION and C.LWSN cookies remotely, but haven't been able to authenticate into the portal page. Ideally, we can get the cookies, and land our users through an iframe into the index.htm file.
Thanks!

-adam

I am definitely interested in having a discussion with you.  Since we have upgraded from V8 to V901; we cannot get EMSS to work externally.  In version 8 it allowed us to

published it on to the public internet by putting an Apache server in the DMZ to handle reverse proxy chores and used a Cisco ACE in front of that to handle SSL termination.

I have a document that shows how I fudged the html to deliver the ESS pages without portal.  I can send it to you.  Send me a private message on this site with your email address and I'll send it to you.

Hello,

I was wondering if anyone has restricted access to users connecting from home?  We have a VMWare solution that we are testing that allows access to our intranet and therefore our ESS.  However this will also allow users who have credentials to perform S3 applicaton work to have access to that while at home as well such as HR,AP,GL,SC,PU....  Our management would like to limit the capability such that we only provide individual Lawson personal HR benefit access to home users.  We are still on LAUA but will be migrating to LS9 over the next 12 months.  Has anyone restricted the Lawson access for at home users?