Re: [EXTERNAL] Implementing "Application Only Access" in LX

Thank you.  Glad to know that Infor did this right.  Now we just need to 
decide on when to pull that switch.

We'll probably go with authorization lists instead of supplemental group 
profiles.

We were in the same boat as you.  Multiple little chapter-S companies, all 
with their own library.  Instead of xxSSA we used SSA##.  Went nuts with 
the number of group profiles and supplemental groups.  Found our SAVSECDTA 
jumped from 5 minutes to an hour.  Called IBM and they used PRTPRFINT to 
verify that this was exactly why SAVSECDTA jumped.
That, and changes to an authorization list doesn't care about waiting 
until we can lock the object.

Later we also consolidated all of our libraries into one.

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:   "McGovern, Sean" <sean.mcgovern-3iVVkb1WNbF8UrSeD/[email protected]>
To:     BPCS ERP System <bpcs-l-Zwy7GipZuJhWk0Htik3J/[email protected]>
Date:   10/11/2017 08:57 AM
Subject:        Re: [BPCS-L] [EXTERNAL] Implementing "Application Only 
Access" in LX
Sent by:        "BPCS-L" <bpcs-l-bounces-Zwy7GipZuJhWk0Htik3J/[email protected]>



Yes, we have around 30 BPCS/LX environments. Each environment has a 2 
character code assigned. NH for North Haven, TM for Tampa etc. All objects 
within the environment are owned by xxSSA, where xx is the 2 character 
code.

Users adopt authority from BPCSMENU to the data. *PUBLIC is *EXCLUDE.

All file objects in every environment also have group profile LXDTAUSE 
assigned with *USE access. Support staff and Super Users have this as a 
Supplemental Group on the user profile to give read access to all data 
(from either within or outside BPCS/LX).

All file objects in every environment also have group profile LXSSAALL 
assigned with *ALL access. This can be used for automated jobs, interfaces 
etc.


-----Original Message-----
From: BPCS-L [mailto:bpcs-l-bounces-Zwy7GipZuJhWk0Htik3J/[email protected]] On Behalf Of Rob Berendt
Sent: 11 October 2017 12:18
To: bpcs-l-Zwy7GipZuJhWk0Htik3J/[email protected]
Subject: [EXTERNAL] [BPCS-L] Implementing "Application Only Access" in LX

We've gotten a lot more concerned about security on our data.  In general 
everyone who has access to this lpar has need to get into Infor LX.
Something that really hasn't been true for 25+years is that if you change 
their user profile to LMTCPB(*YES) they no longer have access to the 
command line and cannot get to the data outside of the programs.
Well longer ago than some people working on IBM i and it's predecessors 
have been alive there have been ways around that.  For example:
- "IBM Navigator for i" which is loaded on every IBM i and is available at
http://youribmi:2001
- IBM Access Client Solutions "Run SQL scripts".
- Excel
and really a rather unlimited number of other possibilities.
And while the auditors are still concerned with securing some commands 
like STRSQL (and forget about newer ones like RUNSQL, etc), and some 
people push Exit Point programs, it's still like playing "Whack-a-mole".
Quite some time ago Wayne Evans coined a phrase called "Application Only 
Access".  In this model the users do not have access to the data.  *PUBLIC 
is *EXCLUDE and the users are NOT part of some group, authorization list 
or any other method to gain direct access to the data.

Suppose your data is owned by SSA.  And SSA is the only user with access 
to that data.
Now, suppose you have a program named BPCSMENU.  And that program is owned 
by SSA.  And, that program is set with "User profile" = *OWNER and not 
*USER.  Then that user could call BPCSMENU and if that program accesses 
the data the user could see that data.
Now let's say the rest of the programs do not have "User profile" set to 
*OWNER but have it set to *USER.  And all those programs (such as ACR100)
have "Use adopted authority  . . . . . . . . . . . . :   *YES".  What this
means is that the user could not call ACR100 directly and get access to 
the data since the "User profile" is set to *USER.  However if they called 
it from an unbroken call stack in which every program between BPCSMENU and
ACR100 have "Use adopted authority  . . . . . . . . . . . . :   *YES" then
they would have access to that data.
This is the difference between Use adopted authority" and "User profile"
and why you do not just make them both *OWNER and *YES.  They do different 
things.

Infor ships their programs out of the box with "User profile" set to *USER
and Use adopted authority  . . . . . . . . . . . . :   *YES.  Which is
what you want. Except for the initial BPCSMENU type program.

So in theory this should work for us, providing the users have *USE (aka 
read only) access to the programs.

Has anyone done this?  Have you set *PUBLIC to *EXCLUDE and try this?  How 
did it work out for you?

How do you handle those "super users" who have a business need to query 
certain files with either 5250 based tools or with client server or web 
based tools?  Do you give them *USE (aka read only) capability to certain 
files?  Do you limit them only to 5250 based queries which you write and 
call from a menu (which our users will not accept since it limits "what 
if" stuff).


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

--
This is the BPCS ERP System (BPCS-L) mailing list To post a message email: 
BPCS-L-Zwy7GipZuJhWk0Htik3J/[email protected] To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives at 
https://archive.midrange.com/bpcs-l.

[CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this email 
is proprietary to Medtronic and is intended for use only by the individual 
or entity to which it is addressed, and may contain information that is 
private, privileged, confidential or exempt from disclosure under 
applicable law. If you are not the intended recipient or it appears that 
this mail has been forwarded to you without proper authority, you are 
notified that any use or dissemination of this information in any manner 
is strictly prohibited. In such cases, please delete this mail from your 
records. To view this notice in other languages you can either select the 
following link or manually copy and paste the link into the address bar of 
a web browser: http://emaildisclaimer.medtronic.com
-- 
This is the BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at https://archive.midrange.com/bpcs-l.



-- 
This is the BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at https://archive.midrange.com/bpcs-l.