[14] in Management Reporting Authorizations Team
A Brand New List and a Draft Report
daemon@ATHENA.MIT.EDU (Rocklyn E. Clarke)
Thu Jul 3 01:21:00 1997
Resent-From: "Rocklyn E. Clarke" <RCLARKE@mitvma.mit.edu>
Resent-To: MRAUTH-L List Archive <mrauth-mtg@menelaus.mit.edu>
Date: Tue, 14 Jan 97 13:14:31 EST
From: "Rocklyn E. Clarke" <RCLARKE@mitvma.mit.edu>
To: MIT Management Reporting Authorizations Team
<MRAUTH-L@mitvma.mit.edu>
----------------------------Original message----------------------------
Greetings!
I have taken the liberty of setting up a listserv list to handle our team
email. I have subscribed the following people to mrauth-l@mitvma.mit.edu:
broberts@MIT.EDU Barry Roberts
rferrara@MIT.EDU Robert V. Ferrara
skellogg@MIT.EDU Stephen R. Kellogg
sroach@MIT.EDU Stephen Roach
RCLARKE@MITVMA Rocklyn E. Clarke
georgep@MITVMC.MIT.EDU George V. Petrowsky
Bob Ferrara has asked me to submit to him a one page report on our project
which includes the following items:
- a current status statement
- a scope statement
- a statement of rough resources
- a statement of missing resources
- a statement of dependenicies
- a rough idea of transition
The report is due today (Tuesday, January 14, 1997). Here is the draft of what
I plan to submit. Since Bob is on this list he can use the draft as is if
necessary, but I wanted to give you folks a chance to correct any errors or
inaccuracies you may notice. Please send your replies back to the list (this
should be the default anyway).
Rocklyn
-------------------------------------------------------------------------------
The SAPAUTH project is charged with developing a scheme for managing
SAP transactions and reports and Management Reporting authorizations
in such a way that the following criteria are met:
1. Ordinary users will only be able to display or change their own
transactions.
2. "Power users" will not be inconvenienced by unnecessary restrictions.
3. "Central Office" users will have the broad unrestricted access that
they need.
We have been evaluating three approches:
1. Herbert Lederer, one of our SAP consultants, has suggested that we
change MIT's business processes to make them more compatible with the
existing SAP R/3 authorization scheme. We would then be able to use
native SAP authorization objects to control client access.
2. Steve Roach, another one of our SAP consultants, has suggested that
we develop "front-ends" for selected native SAP transactions. These
front-ends could be made to do authorization checking in almost any
way we chose prior to invoking the underlying native transation.
This approach assumes that we can restrict access to selected native
transactions in such a way that only suitably authorized users and
ABAP programs would be able to invoke them.
Our most recent tests have demonstrated that this assumption is not
consistently valid.
3. David Rosenberg, another one of our consultants, has suggested that
we make use of a third party software package called "Legacy Link"
to generate the front-ends required for Steve Roach's approach in a
more authomated fashion. Further conversations with SPO America, the
producers of Legacy Link, have made it clear that this is no longer
a viable alternative.
Our resources include the following team members:
Rocklyn Clarke
Stephen Kellogg
George Petrowsky (as needed)
Steve Roach
Barry Roberts
We will doubtless also make use of other staff members and consultants
as needed.
At the moment, the only missing resources are those required to redesign
from scratch the MIT SAP R/3 implementation. Such a redesign would make
this project much easier to carry out.
This project is dependent on the following for successful completion:
1. continuing staff availability
2. a suitable development/test environment (in place)
3. appropriate training (happening as needed)
4. active cooperation from SAP.
Ideally, we want SAP to incorporate exits suitable for performing locally
implemented authorization checking in each R/3 transaction and report.
Once this project is complete, there will be a significant additional
workload which will have to be absorbed somewhere within the Institute.
Herbert Lederer's approach could easily require that four additional
staff members be hired to perform ongoing management of authorizations
(this might be reduced by developing a suitable software tool). Steve
Roach's approach would require that a significant amount of staff time
be spent on retrofitting system modifications to new releases of the
SAP R/3 software. This would presumably take place either within the
I/T Service Process, or within the Management Reporting Process. It
is our current hope that much of the burden of managing authorizations
would be moved to the departments since after all, the request for such
authorizations and access controls originated with them.
