What I do is that I run an Apache instance per system and uses Apache to
setup
the library list - this is a quite simple way of setting different system on
the same
system up.

What the Apache conf. has of settings is quite simple to hide:

# Hide Apache Configuration Files
<Directory /conf>
order allow,deny
deny from all
</Directory>


Some of the programs is shared even thoug datalibs may be different, for
example
all framework maintenance programs are shared.

The librarylist has a numer of libs

PEXTDTAXXX data library that is hidden (XXX) is the instance
PEXTCGIXXX this lib can be reached true a server directive
PEXTRPCXXX this lib can also be reached true a server directive and holdt DB
REST services
PEXTLIBXXX this is for supporting programs and is hidden
PEXTCGI this is the Framework Maintenance lib an can be reached true a
server directive
PEXTAFW the Framework API's and this i hidden
PEXTCD2 the Core API and CGIDEV2 and this is hidden

The corresponding apache server folder (/PEXTWEBXXX) only holds files of no
importance all other IFS files are in an other folder structure
/POWEREXT/XXX/... and thereby hidden

To be able to do change management and to add, update or remove applications
from a instance all data in common files and all IFS files are marked or
oganized with an Application Group e.g PX for powerext, US for user programs
and so on.

So the actual folder structure is POWEREXT/XXX/PX/... or
POWEREXT/XXX/US/.... making me able to move programs and IFS definitions
files around between instance XXX and instanse YYY and even have different
versions of different applications running on the same server.

Now security ... every CGI program or REST service that is exposed true
server directives are protected by a system that at login time runs true the
system with user acces rules and makes an registration in a database of what
programs the user (that now is a session) is entitled to process - this
regsiration is only on a main function level. Each registration has the
session ID and a request ID and the CGI program name and can even hold
hidden parameters and the session ID, the request ID and the program name
must match.

When a CGI program is called - the program may have use of other REST
services, so in the CGI program call there is an registration of wich REST
services it will use and again the are registrered in the database
and request ID is passed to the client.

The Session ID's and the Request ID's are both 32 bytes long and are built
by a timestamp and a CEERN0 who's feed is constatly shiftet between
users and all the registration only exist while the session is active and
not timed out.

So you will have to guess the combination of 32 x 32 bytes and the program
name to run any service in the system and still there may be hidden
parameters the prevent you from doing anything.

It is simply impossible to guess, so you can launch a "trial on error"
attach but the possibility that you can get true within the timeframe is
very unlikely, so you can intercept communication as the only way and still
it will be limited what you can do especially if you don't have a full
description of what the REST services does and even then the service may be
limited by hidden parameters.

Im also working on a blueprint of how to secure parameters send back to the
REST server isn't altered - this is however a rather tricky thing and builds
on the same technology as IBM i uses in the Level Check routine


On Mon, Nov 22, 2010 at 4:17 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

From: Joe Pluta
I'm not sure what you're asking. What would be different?

I was mostly interested in the deployment aspects of EGL/Java based web
services
under a cloud services scenario, where a single server may be used to
support
multiple tenants. And you answered it, kind of.

Your libraries could be set up by library list, while your authorities
would
be by user.

Of course.

I suppose each tenant would have a library list associated
with it, with the authorities identified by the user profile.


Yes, that makes sense.

The only complexity is if you're using stateless servers; you'd need to
switch environments between calls ...

My understanding is that Servlets don't run under library lists. Are you
referring to IBM i host servers, alone? Would you create an intelligent
connection pool manager to determine which tenant each request belongs to?
Users probably wouldn't like the overhead of resetting host server library
lists between calls.

or else have one server for each tenant
and make sure requests are directed properly.

I can see that. Assign each tenant to their own HTTP server port? Run 20
instance of the HTTP server, and 20 instances of WAS. Would that be the
best
approach?

Personally, I prefer stateful servers in which I set up the environment
when
the session is established. Much simpler, but that's just me. I'm a
KISS
kinda guy :).

Just to be clear, is that to say that each user would have their own
individual
stateful connection to a native server?

But this is all technical detail stuff. The important point is that you
can secure a multi-tier application, and you can do it effectively.


I agree that one can secure multi-tier applications. Actually, I was
trying to
sidestep the security question because I was more interested in what you
might
recommend for deployment/runtime efficiency sake.

-Nathan




--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.