Accounting System Development Group Correspondence
Revised: 97/11/24
Date: Fri, 21 Nov 1997 15:06:46 -0800 (PST)
From: Hugh Sheets
To: dorish@cac.washington.edu, hornung@u.washington.edu,
davidw@cac.washington.edu, karalee@cac.washington.edu,
dcox@cac.washington.edu
Cc: yonah@cac.washington.edu, hugh@cac.washington.edu,
stenvik@cac.washington.edu, remmers@cac.washington.edu,
ken@cac.washington.edu, fox@cac.washington.edu, pete@cac.washington.edu
Subject: Accounting clients meeting....
From 97/11/20 meeting:
Karalee Woody, David Cox, Doris Gallaugher, and Mike Hornung joined the
internal accounting team to discuss clients for accessing accounting
information. Dave Wall was unable to attend. We expect this will be an
ongoing process.
Hugh briefly explained the high priority namespace (authorization and
authentication) is the part of the overall accounting project we are
working on right now, with the accounting (billing, reporting, resource
allocation) to use the namespace foundation. We also expect our
namespace to include customers we don't currently deal with, that would
have an authentication login but not actually any UA accounts, and the
namespace could become very large.
We want to use clients (program interfaces) to query and manipulate
namespace and accounting data for a variety of reasons, including:
- we want to minimize root access
- we want to preserve the confidentiality of our data by giving only
the information needed to who needs it
- we want to eliminate shipping around flat files
- we want to make complicated changes easy and consistent
We want to standardize on web interfaces, but also provide an underlying
command line.
The current clients list:
Clinician data entry (done)
Auxiliary validation data entry
Clients for external administrators - to be defined as needed
Web validate (done)
Web who (done)
Web renew (done)
Web new (close)
Easy status changer, like student-to-staff or staff-to-student, etc.
User-driven reporting
Client for help routers to report customer information (assets, gpw,
mail forwarding, etc) (Bob J and Dave Wall)
Posting client - for applying charges to an account - some are
one-time charges, some recurring monthly. It can be used at the
"point of purchase".
Exps-equivalent client - for reporting the history of an account for
investigating why someone expired. (Mike H)
Clients that perform tasks like disusering or expiring people need to be
sure to do a complete job, like handle listproc lists and membership,
newsgroups, web pages, supplemental accounts, crontabs, and so on.
Doris and Mike reported the status-changer is high priority for them, as
these changes are problematic now.
As we deploy clients, we plan to stop generating the flat files the
client is intended to replace, so we need to know what flat files are
used for.
Date: Wed, 12 Nov 1997 16:52:12 -0800 (PST)
From: Hugh Sheets
To: dorish@cac.washington.edu, hornung@u.washington.edu,
davidw@cac.washington.edu, karalee@cac.washington.edu,
dcox@cac.washington.edu
Cc: yonah@cac.washington.edu, hugh@cac.washington.edu,
stenvik@cac.washington.edu, remmers@cac.washington.edu,
ken@cac.washington.edu, fox@cac.washington.edu, pete@cac.washington.edu
Subject: Accounting clients meeting....
The Accounting project is progressing to the point where we want to get
more specific about the clients that will be needed to query/add/modify
authorization/authentication/accounting data.
We would like to convene a meeting Thursday, November 20, 1997, 4545
third floor conference room, 9:00-10:30, to discuss clients.
Hugh Sheets
University Computing Services, box 354843
Computing & Communications
hugh@cac.washington.edu, 543-4041
Date: Thu, 30 Oct 1997 17:18:56 -0800 (PST)
From: Yonah Karp
To: Oren Sreebny
Cc: Jim DeRoest ,
Hugh Sheets ,
Sid McHarg ,
Sandra Moy ,
Donn Cave ,
Lori Stevens , Jim Fox ,
"T. Stenvik" , Ken Lowe ,
"P. Pulliam" ,
Thomas W Remmers ,
Donn Cave , Brad Greer ,
Ping Lo ,
"J. Blankenship" ,
Pete Libbey ,
Will Hall ,
William Shirey , mjsmith@u.washington.edu,
Michael Pingree ,
Doris Gallaugher ,
Jeanne Branom-Sherman ,
"R. Christ" ,
"R. Stretz" , "M. Lee"
Subject: UA accounting design document
Oren,
This is the accounting design document I mentioned today. While
it is somewhat "draft"-like it is probably worth putting in the
public (C&C) eye, and I will put it up as a link from the
accounting project main page after a bit more review.
This doc may change, possibly significantly, which is why I've
been sitting on it for a while. It's become obvious that it's
more helpful to let people look at it (with this caveat) than
having it sit unread, so here it is. I'm cc'ing people who've
shown interest in this document and this project.
If any of you have questions or suggestions please let Hugh and
me know.
Yonah
=====
DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT
UA Accounting Design Document
Last update: 10/30/97 by Yonah Karp
This project subsumes the current UA Austen-based accounting
system (reconciliation, billing, expiration, account creation,
reporting) into an enterprise-wide system that will offer access
to this data for user and account validation, and should also
streamline and greatly simplify data processing. Management,
Client Services and others will be able to access this data via
various clients. This project also will allow expansion of
our current namespace to a seven-digit user population for
authentication and authorization by internal-to-University as
well as external users.
Goals
. Move all accounting-related functions off VMS
. Stop creating and shipping flat files between computers
(whether encrypted or not) and use a client/ server database model
. Direct loading of INFORMIX DB from UNISYS (HEPPS, SDB, etc.)
. Move billing functions to the Business Office
. Give C&CI and other C&C units secure clients to search
and view sensitive data rather than the current (C&CI) model
of root access for account administration
. Use web-based clients when possible
. Move current Li validation service to a commercial database
accessed by ODBC clients
. Enable large communities of people with access to University
online resources an entree
. Allow access to relevant databases via LDAP
Accounting functions to be replicated in reengineered system include:
. Student validation processing
. Faculty/Staff validation processing
. Clinician validation processing
. Auxilliary account validation processing
. Other Li functions
- Email forwarding (@u)
- Securid information repository
. Expiring UA accounts
. Reconciling UA accounts
. Tracking UA account usage
. Billing UA account usage
. Reporting UA account usage
. Class list generation
. Resource adding on UA systems for specific classes
Accounting functions to be examined (and possibly retired) for
reengineered system include:
. Day 1 and Day 10 class processing
. "Scrubbing" CUF records
. Quarterly processing
. Current quarterly reports
. Maintain a list of visiting scholars (with accounts) who
have no US social security number (C&CI)
. Maintain working list of external budgets (C&CI)
Accounting functions new to reengineered system include:
. Client creation for external-to-University administrators to
add and delete identity and authentication information and
set expiration flags for external users
. Management of very large name spaces, perhaps a million people,
where most users would never actually have an account on UCS
computers but would be known for authorization/ authentication
purposes
. LDAP access from a variety of clients
. UNISYS validation (possible)
. LDAP staffdir/studentdir (possible)
Current clients and flat files likely to be retired
. who (Austen)
. validate (daffy/red)
. fvf.info (Austen flat file)
. svf.info (Austen flat file)
. exps (Austen utility)
. charges (Austen utility)
New clients requested or envisioned:
. Clinician data entry
. Auxilliary validation data entry
. External clients for external administrators
. Web validate (done)
. Web who (done)
. Web renew (done)
. Web new (close)
. Easy student-to-staff or staff-to-student status change
. Client to generate unused uids
. User-driven reporting
. Many other clients for C&CI to be determined
. Other clients for external users
Phases
. See phase one doc of pilot projects
(depts.washington.edu/ast/projects/acctg/phase_1_plan.html)
. External Clients -- pilot
. Extended namespace
. External Clients
. Expiration
. Billing/Reporting
People involved
Internal
Jim Fox
Yonah Karp
Ken Lowe
Pete Pulliam
Tom Remmers
Hugh Sheets
Tracy Stenvik
Affiliated
Jeanne Branom-Sherman
Thomas Profit
James DeRoest
Doris Gallaugher
Mary Ellen Lee
Ping-Yun Lo
Michael Pingree
Sid McHarg
Bill Shirey
Martha Smith
Robert Stretz
Rob Christ
Lori Stevens
Brad Greer
Oren Sreebny
DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT
Date: Wed, 4 Jun 1997 07:28:36 -0700 (PDT)
From: Thomas Profit
To: Hugh Sheets
Cc: yonah@cac.washington.edu, Tom Profit
Subject: Re: Accounting System Development Group meeting cancelled....
Hugh, Thanks for the note about the cancelled meeting. I think you are
very correct in assessing this as a very large and complex project and
breaking it up into smaller more manageable pieces is the right thing to
do. I am still very interested in following the project and would like
very much to help in some way.
bye for now
Tom
On Fri, 30 May 1997, Hugh Sheets wrote:
> remmers@cac.washington.edu, smcharg@cac.washington.edu,
> stenvik@cac.washington.edu, stretz@u.washington.edu,
> tprofit@cac.washington.edu, yonah@cac.washington.edu
> Subject: Accounting System Development Group meeting cancelled....
>
> The Accounting System Development Group meeting scheduled for
> Wednesday June 4 has been cancelled. Rather than announce a
> meeting date and time, I plan to leave this until circumstances
> warrant the convening of a full meeting. I do plan to post email
> status reports. I also welcome input to the project.
>
> Work has been progressing. This is a very large project that was
> unrealistic to specify completely initially, so we have divided
> it into phases. Where possible, we will phase-in completed
> pieces and phase-out (if appropriate) what has been replaced. In
> this way, real work can proceed while later phases are being
> specified. Smaller working meetings will be held as we move
> through this process. In such a model, we must look far enough
> ahead to account for later phases that are affected by what is
> happening now - we don't want to "paint ourselves into a corner".
> This will also require some "bridging" of old and new systems to
> keep critical processes running.
>
> We have identified the following list of needs for this project
> (in no particular order, and subject to additions/deletions):
> - Student validation processing
> - Faculty/Staff validation processing
> - "direct" loading of INFORMIX DB from UNISYS
> - Expiration
> - UA reconciliation
> - Billing
> - Reporting
> - Li (UA validation)
> - Email forwarding (@u)
> - UNISYS validation
> - LDAP staffdir/studentdir
>
> The specifications for the first phase are well underway, which
> address the first three needs listed above. We are working on
> creating an INFORMIX database for loading Faculty/Staff and
> Student validation information in a more direct means from the
> UNISYS systems to replace some of the processing done on VMS
> hosts and handle some of the functionality done now by Li.
>
> Hugh Sheets
> University Computing Services, box 354843
> Computing & Communications
> hugh@cac.washington.edu, 543-4041
>
Date: Fri, 30 May 1997 12:40:23 -0700 (PDT)
From: Hugh Sheets
To: Accounting System Development Group ,
deroest@cac.washington.edu, dorish@cac.washington.edu,
fox@cac.washington.edu, hugh@cac.washington.edu,
jbranom@cac.washington.edu, ken@cac.washington.edu,
mel@cac.washington.edu, mpingr@cac.washington.edu,
pete@cac.washington.edu, plo@cac.washington.edu,
remmers@cac.washington.edu, smcharg@cac.washington.edu,
stenvik@cac.washington.edu, stretz@u.washington.edu,
tprofit@cac.washington.edu, yonah@cac.washington.edu
Subject: Accounting System Development Group meeting cancelled....
The Accounting System Development Group meeting scheduled for
Wednesday June 4 has been cancelled. Rather than announce a
meeting date and time, I plan to leave this until circumstances
warrant the convening of a full meeting. I do plan to post email
status reports. I also welcome input to the project.
Work has been progressing. This is a very large project that was
unrealistic to specify completely initially, so we have divided
it into phases. Where possible, we will phase-in completed
pieces and phase-out (if appropriate) what has been replaced. In
this way, real work can proceed while later phases are being
specified. Smaller working meetings will be held as we move
through this process. In such a model, we must look far enough
ahead to account for later phases that are affected by what is
happening now - we don't want to "paint ourselves into a corner".
This will also require some "bridging" of old and new systems to
keep critical processes running.
We have identified the following list of needs for this project
(in no particular order, and subject to additions/deletions):
- Student validation processing
- Faculty/Staff validation processing
- "direct" loading of INFORMIX DB from UNISYS
- Expiration
- UA reconciliation
- Billing
- Reporting
- Li (UA validation)
- Email forwarding (@u)
- UNISYS validation
- LDAP staffdir/studentdir
The specifications for the first phase are well underway, which
address the first three needs listed above. We are working on
creating an INFORMIX database for loading Faculty/Staff and
Student validation information in a more direct means from the
UNISYS systems to replace some of the processing done on VMS
hosts and handle some of the functionality done now by Li.
Hugh Sheets
University Computing Services, box 354843
Computing & Communications
hugh@cac.washington.edu, 543-4041
Date: Wed, 28 May 1997 14:00:30 -0700 (PDT)
From: Mary Ellen Lee
To: Hugh Sheets
Cc: Oren Sreebny ,
"Doris J. Holmes" ,
Keith Mason ,
Sid McHarg ,
Ping Lo , tprofit@u.washington.edu,
hugh@cac.washington.edu, yonah@cac.washington.edu
Subject: Re: TSAT, UNISYS accounting
Status report:
Hugh and Yonah have seen TSAT demonstrated and have a better understanding
now of how standard end user UNISYS accounts are set up. We are all in
agreement that the complexities and unique data elements associated with
establishing the handful of "development" accounts (a.k.a USERCODES) on
the UNISYS systems should not be considered at this time.
Samples of the standard paper "Administrative Access Request" now in use
are on their way by courier to Hugh.
What's next:
Hugh and Yonah want me to state requirements on behalf of C&C Client
Services as to elements/features required for the entities that will
replace UNISYS accounts as IS applications move a to Web-based user
interface.
All that these proposed features would result in would be a account that
could access Web pages requiring SecurID authentication. For features that
would move a user past a very basic "any UW employee" level to a higher
level of access, Hugh and Yonah have been guided to seek out Ping and the
DBA group who are the logical liason between UCS Systems and the
individual application teams/central campus departments who will be
developing the web based applications.
If I have a role in this interaction at all, it would be to guide the
groups involved toward the development of post-audit, rather than
pre-access, controls and to ensure that no assumptions are made as to
Client Services being able to provide staff/expertise to support any but
the following scenario; note that in this scenario, the email address
info@cac is used to represent a pared down and cross trained staff under
Doris' supervision in what is now C&CI. Adminapp@u remains to handle
admin. applications not yet capable of being delivered via this model.
New Administrative Access Request Process:
Employee acceses a web page that interrogates for: Employee ID, name,
birth date.
The process validates the information.. exceptions being (1) not an
employee (2) failure to supply ID number and birth date correctly and (3)
already has basic access.
In the case where an employee already has a basic account, they could be
given the option to generate a request for a "supervised" account.
Initially, these requests would be sent to info@cac for assessment, but I
believe that if we include a flag in the new database for it, people can
be qualified as "supervisors" the first time thru this process and be
handled more directly by info@cac (see below) when future supervised
accounts are requested.
If this is, indeed, a validated request for a new administrative account,
then the web page sends a request to info@cac to send a (disabled) SecurID
to the employee's work address (from HEPPS). With the SecurID would be
sent instructions to send email to info@cac acknowledging receipt and
requesting the SecurID be enabled.
While the SecurID is in transit, the employee has completed the basic
account process (resulting in a record on the new "accounts" data base)
and perhaps already also moved on to other Web pages that enable them to
request specific application privledges (eg. the ability to input Positive
Time Reports to HEPPS).
What have I missed here ? This seems to be the model that supports the
vision of those who are developing the Positive Time Reporting application
and is in keeping with the reality that our handling now of the paper
requests does not really add control beyond what would be provided by the
features above; in that we do not (1) check signatures (2) know who should
be signing and (3) have any way to ascertain that we are actually
collecting paper forms up front for accounts we establish.
mary
PS... if this is actually all we need, then I may just launch a parallel
process with Glenn Eades to look at how we might simply put his USERCODE
equipped client population thru the same initial account setup process...
:-) FAST and ERGO ad hoc reporting capabilities "on the Web".. now there's
a concept !
Date: Tue, 27 May 1997 14:15:05 -0700 (PDT)
From: Mary Ellen Lee
To: Hugh Sheets
Cc: hugh@cac.washington.edu, yonah@cac.washington.edu
Subject: Re: TSAT, UNISYS accounting
Yes, I have plenty of time available this week. Since I drive by 4545
twice daily between about 10:00 and 14:00 it would seem to be most
convenient for all if I came there.. there is nothing magic about devices
reagrds my use of keynes.u at them... since part of my mission is to make
sure keynes.u is accessible from anywhere, I look for opportunities to
demo in places it is not normally used.
I'll propose either tomorrow 5/28 or Thurs 5/29 at 10:30 and see if either
of those times is a good fit.
mary
On Tue, 27 May 1997, Hugh Sheets wrote:
> Mary - I would like to take you up on your offer for a 15 minute demo
> of USERID and USERCODE attributes. At this point in the project,
> this will be a good start.
>
> Since creating USERIDs through "new" on the UNISYS system will
> be examined as a later phase in this project, identifying
> attributes will allow us to proceed with developing the
> database now and adding this functionality later if it still
> seems like the way to go.
>
> I can come to you at 3737 - maybe that will be the easiest for
> just you and I since I imagine you have your station all set up
> for this.... or if this is not a consideration, we can meet here
> in my office if that is better for you.
>
> Would you have a time slot available this week?
>
> Hugh
>
> On Tue, 20 May 1997, Mary Ellen Lee wrote:
>
> > Hugh continues to demonstrate that he has the ability to "get it" :-)..
> > this is a dangerous trait, Hugh.. for those of us who "get it" end up
> > administering UNISYS accounts :-).. there are better things in life,
> > really!
> >
> > What Hugh has right (still my point of view) is that YES! it is desirable
> > to have what are now USERIDs created by the users themselves thru a "new"
> > process.
> >
> > To resolve the remaining statements into true/false can be done easily by
> > showing Hugh (and Yonah too) the TSAT screens that reveal the attributes
> > of both USERIDs and USERCODEs. I could easily stop by 4545 and spend about
> > 15 minutes or so to do this. I'd defer if either Keith or Sid wanted to do
> > this instead.. although of course they probably don't use these screens
> > very often :-) themselves.
> >
> > Again, right now USERCODEs (which I had proposed we defer for a while) are
> > only a handful of accounts relative to USERIDs. Right now very few users
> > need them.
> >
> > From my perspective, it is useful for Hugh to have looked at my
> > justification for deferring USERCODEs from the initial project with
> > totally fresh insight. Maybe something like a Keith/Sid/Mary/Ping meeting
> > is called for to look again at how adminapp@u is setting up "basic" access
> > for users now; at what accounts could not (assuming there are some that
> > could not) deliver all of their features via a UA login; and at whether we
> > are not presented with an opportunity here to rethink differences that may
> > well have been rendered moot by the passage of time and emergence of
> > different connectivity technologies.
> >
> > So I'm open to being invited to any/all side sessions that anyone wants to
> > set up at 4545 so that matters affecting ease of use of administrative
> > systems not be left up to chance. Hugh's naivete is *far* too precious a
> > commodity to waste ! ... :-) and I promise not to get him as adept in
> > UNISYS account particulars as :-) Tom and Oren are !!
> >
> > mary
> >
> > On Tue, 20 May 1997, Hugh Sheets wrote:
> >
> > > Lets just see if Hugh is getting any of this....
> > >
> > > Mary, you point out the difference between a UNISYS "USERID" which
> > > pretty much just logs you in, and a "USERCODE" which is a standard
> > > UNISYS "account" and which then allows a customer to do their work.
> > > The customer logs in with a "USERID" and switches to a "USERCODE" to
> > > do anything. This "USERCODE" has associated with it a list of what
> > > applications it is allowed to use. I hope this is in the general
> > > ballpark; right now I hope to keep this in the simplest terms.
> > >
> > > It sounds like the idea of using "new" to create the basic UNISYS
> > > "USERIDs" using what I will call our usual validation model (what we
> > > do now with "new" on UA machines) is desirable. Correct?
> > >
> > > If I'm doing OK so far, this leaves the difference between the "USERID"
> > > and "USERCODE". Is your idea to leave this difference alone, or to
> > > close up this difference?
> > >
> > > What I mean here is if the "USERID" and "USERCODE" are different,
> > > different processes/decisions are used to make them. If we can make
> > > the "USERID" and "USERCODE" the same thing, or map them one-to-one,
> > > we need to make sure the "USERID" has the potential of having all the
> > > attributes of a "USERCODE", and maintaining the information it takes to
do
> > > that in the new database, and the UNISYS systems query the database. If
> > > the "USERID" and "USERCODE" can't be the same thing, or it it decided
they
> > > shouldn't be for whatever reason, maybe the database would just have a
> > > mapping of "USERID" to "USERCODE"? Maybe a "USERID" maps to multiple
> > > "USERCODEs"?
> > >
> > > Please feel free to comment or correct my misconceptions.
> > >
> > > Hugh Sheets
> > > University Computing Services, box 354843
> > > Computing & Communications
> > > hugh@cac.washington.edu, 543-4041
> > >
> > >
> > >
> >
> >
>
>
Date: Tue, 20 May 1997 17:29:51 -0700
From: Oren Sreebny
To: Hugh Sheets ,
Mary Ellen Lee
Cc: "Doris J. Holmes" ,
Keith Mason ,
Sid McHarg ,
Ping Lo , tprofit@u.washington.edu,
hugh@cac.washington.edu, yonah@cac.washington.edu
Subject: Re: TSAT, UNISYS accounting
Hugh and Mary and all-
Sounds like y'all are on the right track here - I suggest that Hugh and
Mary go ahead and set up this meeting to discuss possible deferment of the
usercode issue.
- Oren
----
From: Mary Ellen Lee
To: Hugh Sheets
Cc: Oren Sreebny ; Doris J. Holmes ; Keith Mason ; Sid McHarg
; Ping Lo ;
tprofit@u.washington.edu; hugh@cac.washington.edu; yonah@cac.washington.edu
Date: Tuesday, May 20, 1997 5:15 PM
Subject: Re: TSAT, UNISYS accounting
Hugh continues to demonstrate that he has the ability to "get it" :-)..
this is a dangerous trait, Hugh.. for those of us who "get it" end up
administering UNISYS accounts :-).. there are better things in life,
really!
What Hugh has right (still my point of view) is that YES! it is desirable
to have what are now USERIDs created by the users themselves thru a "new"
process.
To resolve the remaining statements into true/false can be done easily by
showing Hugh (and Yonah too) the TSAT screens that reveal the attributes
of both USERIDs and USERCODEs. I could easily stop by 4545 and spend about
15 minutes or so to do this. I'd defer if either Keith or Sid wanted to do
this instead.. although of course they probably don't use these screens
very often :-) themselves.
Again, right now USERCODEs (which I had proposed we defer for a while) are
only a handful of accounts relative to USERIDs. Right now very few users
need them.
From my perspective, it is useful for Hugh to have looked at my
justification for deferring USERCODEs from the initial project with
totally fresh insight. Maybe something like a Keith/Sid/Mary/Ping meeting
is called for to look again at how adminapp@u is setting up "basic" access
for users now; at what accounts could not (assuming there are some that
could not) deliver all of their features via a UA login; and at whether we
are not presented with an opportunity here to rethink differences that may
well have been rendered moot by the passage of time and emergence of
different connectivity technologies.
So I'm open to being invited to any/all side sessions that anyone wants to
set up at 4545 so that matters affecting ease of use of administrative
systems not be left up to chance. Hugh's naivete is *far* too precious a
commodity to waste ! ... :-) and I promise not to get him as adept in
UNISYS account particulars as :-) Tom and Oren are !!
mary
On Tue, 20 May 1997, Hugh Sheets wrote:
> Lets just see if Hugh is getting any of this....
>
> Mary, you point out the difference between a UNISYS "USERID" which
> pretty much just logs you in, and a "USERCODE" which is a standard
> UNISYS "account" and which then allows a customer to do their work.
> The customer logs in with a "USERID" and switches to a "USERCODE" to
> do anything. This "USERCODE" has associated with it a list of what
> applications it is allowed to use. I hope this is in the general
> ballpark; right now I hope to keep this in the simplest terms.
>
> It sounds like the idea of using "new" to create the basic UNISYS
> "USERIDs" using what I will call our usual validation model (what we
> do now with "new" on UA machines) is desirable. Correct?
>
> If I'm doing OK so far, this leaves the difference between the "USERID"
> and "USERCODE". Is your idea to leave this difference alone, or to
> close up this difference?
>
> What I mean here is if the "USERID" and "USERCODE" are different,
> different processes/decisions are used to make them. If we can make
> the "USERID" and "USERCODE" the same thing, or map them one-to-one,
> we need to make sure the "USERID" has the potential of having all the
> attributes of a "USERCODE", and maintaining the information it takes to
do
> that in the new database, and the UNISYS systems query the database. If
> the "USERID" and "USERCODE" can't be the same thing, or it it decided
they
> shouldn't be for whatever reason, maybe the database would just have a
> mapping of "USERID" to "USERCODE"? Maybe a "USERID" maps to multiple
> "USERCODEs"?
>
> Please feel free to comment or correct my misconceptions.
>
> Hugh Sheets
> University Computing Services, box 354843
> Computing & Communications
> hugh@cac.washington.edu, 543-4041
>
Date: Fri, 16 May 1997 20:36:25 -0700 (PDT)
From: Mary Ellen Lee
To: Hugh Sheets
Subject: Re: Question....
An astute question actually. It may well be that some plan by UNISYS or
Sid & company is in the works such that I'm wrong in trying to defer what
looks like a series of very complex exceptions for very few accounts in
the interest of getting campus users into a different model sooner rather
than later.
USERIDs, which are issued to everyone but development and systems types,
are severely crippled USERCODES; they can store no files, for example, nor
run any executable code.. the only thing they can do is get a users thru
the login screens and deliver them (through another home grown, feature
rich online formatting environment called DFDS) the fixed-screen
applications that their TSAT records specify. Other than their names (eg.
"hugh") as far as the underlying UNISYS security system is concerned,
every single one of these accounts (there have been as many as 8,000) are
identical.
USERCODEs are actual UNISYS accounts that other UNISYS installations would
recognize. While they recently (a dramatic move by Keith and Mary to deal
with several auditor/programmer/telnet issues) gained TSAT records to
"normalize" them somewhat, 99.9% of their functionality is derived from
the underlying UNISYS security system and not from TSAT.
They do things like CONNECT to our disaster recovery host during disaster
recovery testing, permit file management/editing, source code compilation
and the like. The UNISYS system accounts that store the actual databases
and under which the batch system object codes run are USERCODEs. In this
realm, it signifies, for example, which UNISYS files systems are
accessible and which specific A-Series host you are actually using.
Long term, all C&C provided accounts, including the USERCODEs, should be
accessible through a campus wide login and hence interact extensively with
the new data base being visualized here and now. If you should want/need
priviledges on the UNISYS that require a USERCODE, because it is
"emotionally" important for what will happen someday, your new USERCODE
would still be named "hugh" in the same way that I had mine renamed "mel"
from "ICUADP015".
Sid, however, will probably remain SYSJOBSM (Keith is SYSJOBKWM and Ping
is DBAJOB003) for some time to come even if it means some switchover of
control after login to the UNISYS; that SWITCH facility exists and I
expect it to be quite valuable as we convert even a few accounts to a new
strategy for the highly exciting "HEPPS on the Web" mission. Of course, we
would look like the silly ones since we would end up switching from a
dummy USERID spelled "hugh" or "mel" to a USERCODE named "hugh" or "mel".
SWITCHing between usercodes (and even USERIDs) is normal and acceptable
behavior now for administrative users so this would be a "no big deal"
situation; and this SWITCH facility will also be needed to deal with the
USERCODEs that are accessed by groups and not individuals... the one by
virtue of which our direct deposit slips and the preceding processes all
happen, for example.
USERCODES, by the way, are what the very few accounts still $billed$ out
on the UNISYS system are.
Again, I may be all wrong about the approach here, Sid may want to start
with the USERCODEs.
mary
PS it may also be useful for you to know that TSAT is the tool for any and
all security administration functions on the UNISYS.. it creates, modifies
and deletes both USERCODEs and USERIDs. The actual creation of any account
now is the province of the UNISYS computer operators (or Sid's staff, of
course :-)).. not myself and/or C&CI. This may help you realize just how
appealing the concept of campus users being able to run "new" to get a
very basic account is to me :-)
On Fri, 16 May 1997, Hugh Sheets wrote:
> I ask your patience with my naive questions....
>
> > The information and plan presented here involves only standard end-user
> > accounts for the administrative systems. These are known to many as
> > USERIDs. It does *not* address accounts (USERCODES) fundemental to
> > application/systems development or the production (online and batch)
> > environments. Presumably those would remain unchanged and responsibility
> > for maintaining those accounts directly on UNISYS hosts in the future is
> > a separate issue.
>
> Are you drawing a distinction between "standard end-user accounts" on the
> UNISYS system(s) which you call USERIDs and "USERCODES" which are another
> kind of account on the UNISYS system(s) where the levels of controls
> for TSAT are applied? You don't want to mess with the current
> levels of controls for TSAT in our new accounting database, that is
> "USERCODES"? If this is so, using me for an example, I'm "hugh" on all
> uniform access machines. My USERID on the UNISYS systems would be
> "hugh", but assuming I have a "USERCODE", what would that be? Not
> "hugh"?
>
> Hugh Sheets
> University Computing Services, box 354843
> Computing & Communications
> hugh@cac.washington.edu, 543-4041
>
Date: Fri, 16 May 1997 13:32:10 -0700 (PDT)
From: Mary Ellen Lee
To: Hugh Sheets
Cc: Oren Sreebny ,
"Doris J. Holmes" ,
Keith Mason ,
Sid McHarg ,
Ping Lo , tprofit@u.washington.edu
Subject: Re: TSAT, UNISYS accounting
See below for a try at it, Hugh.. as Sid so sagely pointed out, the
existing environment will continue to grind along indepently of all of
this:
On Thu, 15 May 1997, Hugh Sheets wrote:
> Mary: It would be extremely helpful if you could write up a specification
> or plan for how you envision the TSAT and any other UNISYS account
> authorization/authentication working within the database
> environment were are designing.
>
> Hugh Sheets
***
Hugh asks if I will develop a plan for having the new integrated UW
account database meet the needs of administrative account control and
authorization; here's what I think might work; at least as a starting
point to raise any issues optimism for an exciting future may be obscuring
from my view:
***
Scope:
The information and plan presented here involves only standard end-user
accounts for the administrative systems. These are known to many as
USERIDs. It does *not* address accounts (USERCODES) fundemental to
application/systems development or the production (online and batch)
environments. Presumably those would remain unchanged and responsibility
for maintaining those accounts directly on UNISYS hosts in the future is a
separate issue.
Nothing here considers needs/plans of the Medical Centers administrative
enviroment. However, I feel there is nothing about a centrally
administered personal account with SecurID protection, granted on a basis
of valid employment status, that is antithetical to what their long term
goals may be.
***
Background:
TSAT is a rich, robust and extremely dependable security system (data
base driven) which builds on the basic UNISYS USERCODE controls, but far
exceeds the UNISYS vision. It offers control capabilities by location
(station); user (account); application (sub account... called "driver")
and even time/date.
As the administrative applications were developed, different levels and
types of TSAT controls were preferred by user departments and application
developers. In several instances, controls different in perspective than
those available in TSAT were also desired and these were implemented in
separate security subsystems within applications themselves. In no case
has any application ever used *all* TSAT capabilities for control.
Administering all administrative account security centrally has become
impossible due in no small part to the complexity of that mission. All
non-TSAT-based security is now administered by persons in the central UW
department responsible for the application (eg. for Student Records, this
is the Division of Admissions and Records); TSAT administration at the
application level is now moving to those same departments.
C&C and the central administration both want to see the degree of control
currently exercised within the existing scheme of both TSAT and
accompanying authorization procedures significantly relaxed and replaced
by more useful post-audit controls.
***
Moving Forward:
The location (station) basis for control has been obsolete for some time
now and will not pertain to the new application environments. What counts
is that the right person is using the application, exclusively.
TSAT presently supports still obscure (and therefore usually problematic)
methods of controlling the ability to print data or control printers. It
seems reasonable to have all such controls migrate either to the
application or default to the print capabilities of the desktop
environment. Since the advent of a windowed desktop environment,
controlling the ability to print data from a security standpoint has been
obsolete as a concept.
It is not clear what element (currently the UW Organization Code Financial
Data Base data element is used with suffixes to modify it) would be used
to define access at the user level. It is a given that elements will be
present (an updated) on the new data base to reflect the
college/department a person works within.
In the model presented by the HEPPS Team, nothing like Organization Code
is required, so my plan is to capitalize on that oportunity and abandon
this level of control... thus a person who is an employee would get a
centrally administered account based only on the fact that they are an
employee, but said account would provide no administrative functionality
in and of itself. It would belong to them as long as they were employed
anywhere at the UW.
At the application (ie. DRIVER) level, TSAT currently supports these basic
controls:
College/department orientation (same as above.. UW Org Code)
"Flavor" of the application permitted; called TSAT "default"
Modifier - presently only the HEPPS application uses a TSAT
element, known as Transaction List, to create options
within the default
My view of moving forward in way that both prepares the way for more
decentralization of authorization and post-audit responsibilities, and
fits the mandated lack of staffing support for central administrative
account administration, is that this application level of control would
either be set up and maintained on the new data base by departments other
than C&CI (eg. Division of Admissions and Records) or be a part of
application-contained security systems.
The latter idea would be preferred given that keeping a central account
data base well tuned to meet all other needs would be less likely if any
component was variable by number of administrative applications (which I
am not treating as a given, static number) and preference of application
designers.
mary
Date: Thu, 15 May 1997 14:27:07 -0700 (PDT)
From: Hugh Sheets
To: mel@cac.washington.edu, tprofit@u.washington.edu
Cc: hugh@cac.washington.edu
Subject: TSAT, UNISYS accounting
Mary: It would be extremely helpful if you could write up a specification
or plan for how you envision the TSAT and any other UNISYS account
authorization/authentication working within the database
environment were are designing.
Hugh Sheets
University Computing Services, box 354843
Computing & Communications
hugh@cac.washington.edu, 543-4041
Date: Thu, 15 May 1997 14:13:28 -0700 (PDT)
From: Hugh Sheets
To: Accounting System Development Group ,
deroest@cac.washington.edu, dorish@cac.washington.edu,
fox@cac.washington.edu, hugh@cac.washington.edu,
jbranom@cac.washington.edu, ken@cac.washington.edu,
mel@cac.washington.edu, mpingr@cac.washington.edu,
pete@cac.washington.edu, plo@cac.washington.edu,
remmers@cac.washington.edu, smcharg@cac.washington.edu,
stenvik@cac.washington.edu, stretz@u.washington.edu,
tprofit@cac.washington.edu, yonah@cac.washington.edu
Subject: Accounting System Development Group meeting postponed....
Our planned Accounting System Development Group meeting Wednesday,
May 21 has been postponed until Wednesday June 4, 10:30 am. I'll
be sending out a reminder prior to the meeting.
As always, please send along any ideas you have for features or
requirements that we should know about during this specifications phase.
Hugh Sheets
University Computing Services, box 354843
Computing & Communications
hugh@cac.washington.edu, 543-4041
Date: Thu, 01 May 1997 16:04:11 -0700 (PDT)
From: HUGH@u.washington.edu
To: yonah@cac.washington.edu
Cc: hugh@cac.washington.edu
Subject: Accounting group minutes (draft - for your additions/changes)
Accounting System Development Group highlights from 4/16 and 4/30:
------------------------------------------------------------------
An effort was made to assemble a group of people representing the various
areas of C&C that are or may be interested in the accounting system of UCS.
This includes the authorization system controlling who can get accounts on
what systems, email forwarding, resource allocation and usage information,
etc.
04/16/97:
---------
The first general meeting - a general overview about what this project
was about was given. Several handouts were distributed. Some
explanation of the current system(s) was given to highlight the need for
a new system.
An objective of the meeting was to try to identify the bounds of the
project. Some specifics discussed were the student and faculty
validation information we get nightly and whether we should consider this
as a given for the forseeable future. The flow of this information, yes,
the vehicle (ftp-ed files) no. There has long been the desire to utilize
a database product, so options were discussed. Sid's group, Technical
Support Services, has extensive experience using database products and
has standardized on INFORMIX. Sid offered access to the INFORMIX
database product and some technical expertise from his staff.
We were wondering if the UNISYS system does accounting/billing, and if we
could pass this function there, or have the UNISYS system pass this to
us. As it turns out, there is minimal activity of this nature on the
UNISYS system, so we decided to not consider this.
Action items:
- UCS programmers will begin compiling functional specifications.
- UCS programmers will investigate INFORMIX database product with
assistance from Technical Support Services group.
- Everyone will think about their area of C&C and what they use
or may use this Accounting System for.
- Meet again April 30.
04/30/97:
---------
A progress report on the development of specifications was given. A
handout prepared by Tracy Stenvik was distributed showing the data used
in the current systems and the sources.
We discussed how information would get imported into an INFORMIX
database, such as nightly student and faculty/staff data, and determining
daily usage. Ping assured us this could be done a lot easier than the
current process.
Mary Ellen Lee discussed the process used to set up UNISYS accounts and
how they are permitted to look at subsets of the data maintained on the
UNISYS system. ....... should this validation process drive off our
data and be recorded in our data? .......
--- my notes are incomplete ----
Tom Profit asked about the Locke and TV Technologies billing, and whether
these should be included in this system. We discussed whether we might
give someone else billing information to have CTIs and invoices generated
if there is a good system available somewhere already, or the reverse if
we come up with a good system. Yonah will talk to Sandy about this.
Action items:
- UCS programmers will continue compiling functional specifications.
- UCS programmers will continue to investigate INFORMIX database product
with assistance from Technical Support Services group.
- Yonah will talk to Sandy about how other C&C groups do billing.
- Everyone will think about their area of C&C and what they use
or may use this Accounting System for, and be sure these needs are
addressed in this design phase.
Our next meeting will be Wednesday May 21, 1997.
Date: Mon, 28 Apr 1997 14:26:40 -0700 (PDT)
From: "Doris J. Holmes"
To: Bill Shirey
Cc: Jim DeRoest ,
Jim Fox , Hugh Sheets ,
"Jeanne E. Branom-Sherman" ,
Ken Lowe ,
Pete Pulliam ,
Tracy Stenvik ,
Yonah Karp ,
Michael Hornung ,
Oren Sreebny
Subject: Re: Accounting meeting reminder.....
Bill,
Great to hear that the svf be expanding soon. We're psyched!
Forgive me if this question has been answered in previous emails. But,
for those students w/blanks in the PAC field... will they get a message
other than "the info you've provided doesn't match..." when attempting to
run "new"? Or will a blank field generate a msg that tells them they need
to get a star code?
Thanks,
Doris
Doris J. Holmes
Manager, Computing & Communications Information
U of W, Box 355670
Seattle, WA 98195
email: dorish@cac.washington.edu
voice: 206-543-5925
fax: 206-543-3909
On Mon, 28 Apr 1997, Bill Shirey wrote:
> I'm afraid this is the first I've heard of this group and this meeting,
> and I won't be here Wednesday. Let me know if I should have someone else
> from my team attend.
>
> Coincidently, the svf file that's created Tuesday night will be the first
> to implement the new features that were agreed to over the last couple
> months, namely:
>
> * students who have accepted an offer of admission for a future quarter
> will be on the file with a status of "A".
>
> * grad students on an official leave will be on the file with a status
> of "L".
>
> * With the exception of newly-admitted students (status "A"), students
> who have not used STAR to create a Private Access Code (PAC) will have
> blanks in the PAC field. Newly-admitted students how haven't created
> a PAC will have their birthdate in the PAC field.
>
> ------------------------------------------------------------------------
> Bill Shirey bshirey@cac.washington.edu
> Manager, Student Systems http://weber.u.washington.edu/~bshirey
> Information Systems, Box 354844 (206) 543-6324 Fax: (206) 543-0831
> COMPUTING & COMMUNICATIONS 4545 15th Avenue, NE
> University of Washington Seattle, Washington 98105-4527
> ------------------------------------------------------------------------
>
> On Mon, 28 Apr 1997, Hugh Sheets wrote:
>
> > Don't forget the Accounting meeting this Wednesday, April 30, 10:30,
> > 4545 third floor conference room.
> >
> > We have been working on the requirements/specifications based on the
> > current system. Hopefully, all of us have been thinking about the
> > particular needs of the groups we represent so we can be sure to get
> > a complete set of requirements.
> >
> > Hugh Sheets
> > University Computing Services, box 354843
> > Computing & Communications
> > hugh@cac.washington.edu, 543-4041
> >
> >
> >
>
>
Date: Mon, 28 Apr 1997 13:54:28 -0700 (PDT)
From: Bill Shirey
To: Hugh Sheets
Cc: Jim DeRoest ,
"Doris J. Holmes" ,
Jim Fox , Hugh Sheets ,
"Jeanne E. Branom-Sherman" ,
ken@cac.washington.edu, Mary Ellen Lee ,
Mike Pingree ,
Pete Pulliam ,
Ping-Yun Lo ,
Tom Remmers ,
Sid McHarg ,
Tracy Stenvik , stretz@u.washington.edu,
Thomas Profit ,
Yonah Karp ,
Oren Sreebny
Subject: Re: Accounting meeting reminder.....
I'm afraid this is the first I've heard of this group and this meeting,
and I won't be here Wednesday. Let me know if I should have someone else
from my team attend.
Coincidently, the svf file that's created Tuesday night will be the first
to implement the new features that were agreed to over the last couple
months, namely:
* students who have accepted an offer of admission for a future quarter
will be on the file with a status of "A".
* grad students on an official leave will be on the file with a status
of "L".
* With the exception of newly-admitted students (status "A"), students
who have not used STAR to create a Private Access Code (PAC) will have
blanks in the PAC field. Newly-admitted students how haven't created
a PAC will have their birthdate in the PAC field.
------------------------------------------------------------------------
Bill Shirey bshirey@cac.washington.edu
Manager, Student Systems http://weber.u.washington.edu/~bshirey
Information Systems, Box 354844 (206) 543-6324 Fax: (206) 543-0831
COMPUTING & COMMUNICATIONS 4545 15th Avenue, NE
University of Washington Seattle, Washington 98105-4527
------------------------------------------------------------------------
On Mon, 28 Apr 1997, Hugh Sheets wrote:
> Don't forget the Accounting meeting this Wednesday, April 30, 10:30,
> 4545 third floor conference room.
>
> We have been working on the requirements/specifications based on the
> current system. Hopefully, all of us have been thinking about the
> particular needs of the groups we represent so we can be sure to get
> a complete set of requirements.
>
> Hugh Sheets
> University Computing Services, box 354843
> Computing & Communications
> hugh@cac.washington.edu, 543-4041
>
Date: Mon, 28 Apr 1997 12:27:41 -0700 (PDT)
From: Hugh Sheets
To: Accounting System Development Group ,
deroest@cac.washington.edu, dorish@cac.washington.edu,
fox@cac.washington.edu, hugh@cac.washington.edu,
jbranom@cac.washington.edu, ken@cac.washington.edu,
mel@cac.washington.edu, mpingr@cac.washington.edu,
pete@cac.washington.edu, plo@cac.washington.edu,
remmers@cac.washington.edu, smcharg@cac.washington.edu,
stenvik@cac.washington.edu, stretz@u.washington.edu,
tprofit@cac.washington.edu, yonah@cac.washington.edu
Subject: Accounting meeting reminder.....
Don't forget the Accounting meeting this Wednesday, April 30, 10:30,
4545 third floor conference room.
We have been working on the requirements/specifications based on the
current system. Hopefully, all of us have been thinking about the
particular needs of the groups we represent so we can be sure to get
a complete set of requirements.
Hugh Sheets
University Computing Services, box 354843
Computing & Communications
hugh@cac.washington.edu, 543-4041
Date: Tue, 22 Apr 1997 15:12:26 -0700 (PDT)
From: Hugh Sheets
To: Mike Pingree
Cc: hugh@cac.washington.edu, Yonah Karp
Subject: Re: New accounting system....
This is the system we currently use to generate monthly invoices and CTIs
for Uniform Access computer usage, which does not seem too interesting to
IS, but we are also including our authorization system - who is staff,
faculty, students, who has accounts where, who is authorized to have
accounts where, who has left the UW, email forwarding, etc. We pass
email address information to the UNISYS system daily, billing information
monthly, etc.
In case any areas of IS may want to look at any of this sort of
information, they may want to be in on the specifications phase so we
can be sure we have what they will need. We get some of this
information from IS also. For example, we get our
Student Validation information from Bill Shirey, so we are planning to
invite him so we know what is available in what form so we can perhaps
design a new system to receive this information easier.
I do not really know the extent of all the players so we want to get
the word around as to what we are planning..
Hugh
On Tue, 22 Apr 1997, Mike Pingree wrote:
> I'm confused... what "accounting system" are we refering to?
>
> On Fri, 18 Apr 1997, Hugh Sheets wrote:
>
> > Mike: As you may have heard, we (UCS) are planning on overhauling our
> > accounting system, including our authorization system. We plan to
> > store everything (usage, authorization) in a database. At this
> > time in the planning stage we are developing the specifications
> > for the database, so it would be good to hear from your group about
> > what you will expect to get from this system.
> >
> > If you have some folks in mind who you think should be included
> > in this level of planning, let me know and I'll make sure they
> > know about the meetings.
> >
> > Hugh Sheets
> > University Computing Services, box 354843
> > Computing & Communications
> > hugh@cac.washington.edu, 543-4041
> >
> >
> >
>
>
Date: Thu, 10 Apr 1997 11:48:20 -0700 (PDT)
From: Hugh Sheets
To: dorish@cac.washington.edu, jbranom@cac.washington.edu,
hornung@cac.washington.edu, smcharg@cac.washington.edu,
plo@cac.washington.edu, deroest@cac.washington.edu,
yonah@cac.washington.edu, ken@cac.washington.edu,
pete@cac.washington.edu, stenvik@cac.washington.edu,
fox@cac.washington.edu, tprofit@cac.washington.edu
Cc: hugh@cac.washington.edu
Subject: Re: New accounting system....
Wednesday April 16, 10:30, in the 4545 3rd. floor Conference Room seems
to fit everyone's schedule. See you there.
Hugh Sheets
University Computing Services, box 354843
Computing & Communications
hugh@cac.washington.edu, 543-4041
On Tue, 8 Apr 1997, Hugh Sheets wrote:
> Its time to start planning the new accounting system for UCS. This is
> moving the existing VMS-based system into a UNIX-based
> alternative. There have been many improvements suggested over the years,
> and this is the time to build the system we want and need. Lets not
> exclude any accounting aspect at this time.
>