|
Let me see if I understand you. It's not enough if the application
secures them from actually using an application, it must also not show
them that, if they had the authority, they could do certain things? Why?
Because they would go to your boss, roll on the floor and scream "I want
it!" over and over until your boss relents?
On a related note, are there still items on the website that Application
Administration doesn't control who can get in there?
Jim was right on another matter. It's important to use the security built
into the IBM i and not rely upon the interface to control security. A
classic example is "We have *public *all on all data but that's alright -
our 5250 menu system has no command line." Totally ignoring file
transfer, Excel built ins, ftp, remote command execution, etc.
And still related, what version are we talking about? IOW, with or
without level 16 of ptf group SF99368? In there they did a rewrite of
this port 2001 stuff. I have it on one lpar but I've not had the time to
see if it has visual granularity in addition to access granularity.
And I shudder to mention this, but you could block port 2001 on your
firewall except for access by a few IP addresses.
And on another thing, if they can't do anything but it just informs them,
using a graphic which shows them how much space is available on disk, for
an example, where's the harm in that? Is there a fear that they'll see
that you have 10% available of a 1TB system and try to snag on to that to
store their engineering drawings? Or the SAN manager may see you have too
much available and ask for it back?
Granted, I'm not talking about unfettered access to viewing spool files. I
still remember an employee who complained about her check stub before it
was printed. But she had matched the wrong stub with the wrong check. We
promoted her to HR Director.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: "Lorne Sturgeoff" <lorne.sturgeoff@xxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx,
Date: 02/06/2013 05:29 PM
Subject: Re: How to secure IBM Navigator For I
Sent by: midrange-l-bounces@xxxxxxxxxxxx
Thanks, Jim.
What I'd really like is to be able to specify which user profiles have
access to the Web application and then, within the application, I'd like
to
be able to control which functions appear on the left panel. Some users
only
need Basic Operations. They don't need to know that the other stuff
exists.
We have attempted to secure the underlying commands where possible and we
have invoked Application Administration for those items that it covers.
Application Administration will create an access error if someone tries to
access something for which he/she is not authorized but it will not mask
those items in the web app.
Cheers,
Lorne.
"Jim Oberholtzer" wrote in message
news:mailman.14253.1360186671.10847.midrange-l@xxxxxxxxxxxx...
What Rob is pointing out is the Application Administration is
independent of the thick client or the web based client. It will act on
both.
You are correct that the Application is not quite granular enough at
some levels but it can block most things. You'll need to look to the
underlying commands and APIs to really restrict those functions. You can
start by making sure your users do not have *JOBCTL or *SPLCTL. That
will go a long way to achieving what you want if I understand the
requirements properly.
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
