Hallo!
Ich bin auf der Suche nach einer Definition für den Begriff „Rolle“, wie er v.a. im Zusammenhang mit Workflow - Management - Systemen oft Gebrauch findet.
(kann ruhig auch in Englisch sein)
leider werde ich nirgendwo fündig…
dank im voraus,
JJLehto
Ist es das?
Introduction to the Workflow Management Coalition
What is the Workflow Management Coalition?
The Workflow Management Coalition, founded in August 1993, is a non-profit, international organization of workflow vendors, users, analysts and university/research groups.
The Coalition’s mission is to promote and develop the use of workflow through the establishment of standards for software terminology, interoperability and connectivity between workflow products. Consisting of over 285 members, spread throughout the world, the Coalition has quickly become established as the primary standards body for this rapidly expanding software market.
Mission Statement
Increase the value of customers’ investment with workflow technology
Decrease the risk of using workflow products
Expand the workflow market through increasing awareness for workflow
Why Should a Business Use Workflow?
The Evolution of Workflow Workflow Management consists of the automation of business procedures or „workflows“ during which documents, information or tasks are passed from one participant to another in a way that is governed by rules or procedures. Workflow software products, like other software technologies, have evolved from diverse origins. While some offerings have been developed as pure workflow software, many have evolved from image management systems, document management systems, relational or object database systems, and electronic mail systems.
Vendors who have developed pure workflow offerings have invented terms and interfaces, while vendors who have evolved products from other technologies have often adapted terminology and interfaces. Each approach offers a variety of strengths from which a user can choose. Adding a standards based approach allows a user to combine these strengths in one infrastructure.
The Key Benefits
Improved efficiency - automation of many business processes results in the elimination of many unnecessary steps
Better process control - improved management of business processes achieved through standardizing working methods and the availability of audit trails
Improved customer service – consistency in the processes leads to greater predictability in levels of response to customers
Flexibility – software control over processes enables their re-design in line with changing business needs
Business process improvement - focus on business processes leads to their streamlining and simplification
Workflow Management Coalition Structure
The Coalition is divided into three major committees, the Technical Committee, the External Relations Committee, and the Steering Committee. Small working groups exist within each committee for the purpose of defining workflow terminology, interoperability and connectivity standards, conformance requirements, and for assisting in the communication of this information to the workflow user community.
The Coalition’s major committees normally meet three times per calendar year for three days at a time, with meetings usually alternating between a North American and a European location. The working group meetings are held during these three days, and as necessary throughout the year.
Coalition membership is open to all interested parties involved in the creation, analysis or deployment of workflow software systems. Membership is governed by a Document of Understanding, which outlines meeting regulations, voting rights and so on.
Coalition Working Groups
The Coalition has established a number of working groups, each working on a particular area of specification. The working groups are loosely structured around the „Workflow Reference Model“ which provides the framework for the Coalition’s standards program. The Reference Model identifies the common characteristics of workflow systems and defines 5 discrete functional interfaces through which a workflow management system interacts with its environment - users, computer tools and applications, other software services, etc. Working groups meet individually, and also under the umbrella of the Technical Committee, which is responsible for overall technical direction and co-ordination.
Achievements
The initial work of the Coalition focused on publishing the Reference Model and Glossary, defining a common architecture and terminology for the industry. A major milestone was achieved with the publication of the first versions of the Workflow API (WAPI) specification, covering the Workflow Client Application Interface, and the Workflow Interoperability specification. The Audit Data specification was added in 1997, being followed by the Process Definition Import/Export specification.
A further version of WAPI covers Application Invocation API’s, completing the Coalition’s initial deliverables across the five interface functions. Further work includes the completion of a common object model with object bindings for IDL and OLE, interoperability extensions for security, and additional interoperability models.
The Coalition has validated the use of its specifications through international demonstrations and prototype implementations. In direct response to growing user demand, live demonstrations of a workflow interoperability scenario have shown how business can successfully exchange and process work across multiple workflow products using the Coalition’s specifications.
Gruss
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Ist es das?
Nein, leider. Ich bräuchte eine Definition für den Begriff „Rolle“…
etwa in der Form:
Roles are used in order to assign types of users rather than actual users to tasks. In case a task is not claimed by any user an appropriate scheduling mechanism or additional negotiations have to guarantee that a fulfiller is found. Each role is identified by a unique ID. Examples of roles are editor, proofreader, typesetter, etc. If a task is assigned to a role, which should be the normal case, this task has to be claimed by a specific user.
Nun OK?
( in maessigem deutsch…aber danach in engl)
Die RollenDatenbank
an
Massachusetts Institute of Technology
Jim Repa
[email protected]
Educause-Konferenz
Long Beach, Kalifornien
Oktober 29, 1999
Zusätzliche Informationen vorhanden an http://web.mit.edu/rolesdb
MIT hat ein System eingeführt, genannt die Rollendatenbank, um Ermächtigungen der Leute für die rechnergestützten Unternehmen-breiten Anwendungen zentral zu handhaben. Rollen oder Ermächtigungen werden zentral in den verständlichen Geschäftsbezeichnungen definiert und umgewandelt dann in die gebürtige Darstellung jeder Anwendung, auf die sie zutreffen. Eine Ermächtigung ist eine Instanz 3-part, die aus einer Person, einer Geschäfts- Funktion und einem Kennzeichner besteht. Der Hierarchie-gegründete Kennzeichner definiert den Bereich der Ermächtigung schmal als einzelnes Kontonummer oder breit, als Abteilung, Schule oder die gesamte Organisation. Dieses System unterstützt ein Klima, in dem viele Leute autorisiert werden, ähnliche Aufgaben durchzuführen, aber für unterschiedliche Abteilungen oder steuerliche Bereiche.
Die Darstellung faßt das Design der Rollendatenbank zusammen und beschreibt, wie sie benutzt wird, um Ermächtigungen für Datenlager MITs, finanzielles System DES SAFTS und andere Anwendungen zu handhaben.
Inhalt
Warum eine Rollendatenbank?
Hauptgrundregeln hinter der Rollendatenbank
Was ist eine Ermächtigung?
Der Kennzeichnerbestandteil einer Ermächtigung
Wer kann Ermächtigungen erstellen, aktualisieren oder löschen?
Die Software - wie wird sie eingeführt?
Daten ziehen und aus in die Rollendatenbank heraus
ein Wo sind wir heute?
Pläne während der Zukunft
Warum eine Rollendatenbank?
In einem großen pädagogischem und Forschungsinstitut wie MIT, kann der Job der Erlaubnis der beibehaltenen Leute, spezifische Aufgaben auf mehrfachen Computersystemen durchzuführen kompliziert und zeitraubend sein. Es gibt Richtlinien, die Leute ermöglichen Erwerbe für bestimmte Kontonummer, Bericht auszugeben oder zu genehmigen über die finanzielle oder Personalinformationen, entscheiden auf der Aufnahme eines zukünftigen Kursteilnehmers zu einer spezifischen Schule, zu einem etc… Die Verantwortlichkeit, zu entscheiden wem z.B. auf Kontonummer aufwenden lassen werden sollte, wird von der Abteilung oder von der Einzelperson innerhalb der Abteilung angehalten, der das Konto " besitzt ". Aber das Wissen, das angefordert wird, um die Erlaubnis im finanziellen System aufzustellen, einer Person zu erlauben auf Kontonummer aufzuwenden, wird von einem Systemverwalter für das finanzielle System angehalten. Selbst wenn es eine Schnittstelle für " die allgemeinen Benutzer " zum Eintragen von Ermächtigungsinformationen in einzelne Systeme gab, würde sie für jedes System unterschiedlich sein, und allgemeine Benutzer würden nicht alle diese Schnittstellen erlernen wollen.
Die Abteilungsverwalter mit Wissen über ihre Abteilungß betriebsmittel und wer Zugriff zu ihnen benötigt, nicht eine einfache Weise des Schauens hoch oder des Änderns dieser Ermächtigungen in den verschiedenen Systemen haben, die Zugriff zu ihren Abteilungsbetriebsmitteln geben. Weil zu berichten ist hart, über Ermächtigungen für alle diese Systeme, werden die Ermächtigungen häufig nicht herauf gesäubert, wenn eine Person die Abteilung läßt oder Verantwortlichkeiten ändert. Und es gibt das Potential für Fehler, wenn ein Abteilungsoffizier einen Ermächtigungß änderungsantrag in der Geschäftsterminologie bildet und SIE Person die in das arcane technobabble jedes Systems übersetzen muß.
Wir wollten eine bessere Weise finden, Ermächtigungen der Leute für verschiedene rechnergestützte Systeme beizubehalten, um diese Wartung weniger zeitraubend, und weniger fehleranfällig zu bilden einfacher.
Hauptgrundregeln hinter der Rollendatenbank
Wir folgerten, daß wir den Prozeß des Beibehaltens der breiten Ermächtigungen des Unternehmens verbessern könnten, wenn wir ein Ermächtigungssystem auf diesen vier Grundregeln basieren ließen:
Behalten Sie Informationen über Rollen oder Ermächtigungen der Leute für rechnergestützte Systeme in einer zentralen Datenbank bei, dann verbreiten Sie die Daten zu den verschiedenen Systemen, in denen diese Ermächtigungen erzwungen werden.
Definieren Sie Ermächtigungen oder Rollen in der verständlichen Geschäftsterminologie, dann lassen Sie das System automatisch sie in das arcane Format umwandeln, das durch jede Anwendung angefordert wird.
Machen Sie zunutze die Tatsache, daß Leute in den unterschiedlichen Abteilungen ähnliche Geschäftsaufgaben durchführen, aber mit unterschiedlichen Sets der finanziellen oder Abteilungß betriebsmittel. Definieren Sie Ermächtigungen als three-part Instanzen: Person kann tun Funktion für Kennzeichner
(wer) (was) (wo)
Hier stellt der Kennzeichner eine Abteilung, Kontonummer oder jede mögliche andere Nachricht dar, die den Bereich der Fähigkeit der Person, die Geschäfts- Funktion durchzuführen begrenzt oder kennzeichnet. Kennzeichner werden in den Hierarchien beibehalten, also kann eine Ermächtigung definiert werden, um auf ein " Blatt " eines Baums (z.B., Kontonummer) oder des vollständigen " Zweigs " zuzutreffen (alle Kontonummer in der Schule der Wissenschaft).
Haben Sie die Abteilungsverwalter, die wissen, daß ihrer Abteilung Betriebsmittel und Personal die zum Beibehalten der Ermächtigungen, nicht eine zentrale Person sind, die nicht mit allen Leuten und Betriebsmitteln in jeder Abteilung vertraut sein kann.
Der Begriff eines zentralisierten Ermächtigungssystems ist nicht völlig neu, aber wir könnten keine vorhandenen Systeme finden, die unsere Spezifikationen treffen würden. An MIT gibt es ein Liste-Wartungssystem, das Moira genannt wird, der für Zugriffssteuerung einiger Betriebsmittel innerhalb des Projektes Athena an MIT verwendet wird. Und, die Universität von Michigan hat ein Ermächtigungssystem entwickelt, das auf LDAP basiert. Jedoch folgen keine von diesen dem three-part Modell, das wir bevorzugen (Person + Funktion + Kennzeichner) oder leicht die Hierarchien unterstützen, die ein natürliches Teil Kennzeichner sind. So entwarfen wir und entwickelten unser eigenes System, das wir die Rollendatenbank nennen.
Was ist eine Ermächtigung?
In der Rollendatenbank ist der Hauptzweck, der die Berechtigung einer Person definiert, um durchzuführen, eine Geschäftsaufgabe eine Ermächtigung Wie oben erwähnt, ist eine Ermächtigung eine Instanz 3-part und besteht aus einer Person + einer Funktion + einem Kennzeichner
Wenn man eine Ermächtigung erstellt, muß jeder der drei Bestandteile von einer vorhergehend-definierten Liste von Möglichkeiten ausgewählt werden und die Wahrscheinlichkeit von Fehlern verringern. Person, Funktion und Kennzeichner sind die wichtigsten Felder in einer Ermächtigung; es gibt einige andere geringe Felder, die auch unten behandelt werden.
Die Bezeichnung Ermächtigung deutet an, daß eine Person die Erlaubnis gehabt wird, um etwas auf einem gegebenen System zu tun. In vielen Fällen ist das genau, was es darstellt: die Erlaubnis, damit eine Person eine Geschäftsfunktion in einem rechnergestützten System durchführt. Jedoch kann eine " Ermächtigung " eine Rolle, eine Verantwortlichkeit oder Position in einem workflow-gegründeten System auch darstellen. Eine Person kann viele Ermächtigungen haben, auf gleiche oder die unterschiedlichen Systeme zuzutreffen. Es ist auch möglich, daß eine einzelne Ermächtigung für eine Person mehr als ein System beeinflussen könnte; z.B. konnte eine Ermächtigung, den finanziellen Bericht für Kontonummer zu tun auf das finanzielle System des SAFTS und das Datenlager zutreffen.
Lassen Sie uns jeden der drei Hauptbestandteile einer Ermächtigung betrachten.
Die Person wird durch ein username oder spezifischer, eine Kerberos-Direktion innerhalb des mit.edu-Gebietes dargestellt.
Eine Funktion ist eine der Aufgaben, die einem Benutzer autorisiert werden kann an einem gegebenen System durchzuführen. Funktionen werden durch die Anwendung gruppiert (bekannt als eine " Funktionskategorie " in der Rollenfachsprache). Jede Funktion dazugehörig mit ihr eine spezifische Kennzeichnerart; z.B. bezieht die " finanzielle berichten" Funktion auf eine Kennzeichnerart von " Kontonummer ". Wenn eine Ermächtigung erstellt wird, muß der gewählte Kennzeichner von der rechten Art sein zum Zusammenbringen der Funktion. Einige Funktionen treffen auf mehr als ein System, wie die finanzielle berichtenfunktion zu, die eine Personberechtigung zum Bericht über gegebenes Kontonummer im finanziellen System des SAFTS und im Datenlager gibt.
Ein Kennzeichner kann Kontonummer, Organisationszahl, Etat gruppe, etc. sein. Da Kennzeichner jeder Art in eine Hierarchie organisiert werden, kann ein Kennzeichner ein Zweig des Baums von Kontonummer, ein Zweig des Baums von Organisationen, usw. auch sein. Kennzeichner werden im Allgemeinen von anderen Systemen als Teil einer allabendlich Zufuhr extrahiert. Einige Funktionen sind entweder " alle oder nichts " und benötigen nicht einen Kennzeichner; in diesen Fällen wird ein placeholder- Kennzeichner der NULL in der Ermächtigung umfaßt.
Sind hier einige Beispiele von Ermächtigungen:
Person Funktion Kennzeichner
FredFlyn Erstellen Sie Forderungen F2283900 (Programm BiotechnikPhD)
JaneDoe Genehmigen Sie Forderungen SG_biology (Ausgabengruppe für Abt. der Biologie)
SueSmith Finanzieller Report PC152000 (Profitmitte für Abt. von Chemie)
JonClerk Weisen Sie Zahlen des Angestellten Identifikation zu NULL (kein Kennzeichner benötigt)
Es gibt zusätzliche Felder, denen zu der Zeit eingestellt werden können eine Ermächtigung wird erstellt: effective_date, expiration_date, Bewilligung und do_function. Effective_date spezifiziert das Datum, auf dem die Ermächtigung zuerst in Effekt einsteigt, und expiration_date spezifiziert das Datum, auf dem die Ermächtigung aufhört, wirkungsvoll zu sein. Die Bewilligungs- und do_functionfelder hängen mit der Fähigkeit, Ermächtigungen zu erstellen zusammen und werden in einem folgenden Kapitel erklärt werden.
Zwei zusätzliche Felder werden automatisch für jede Ermächtigung gespeichert: das Datumlast modified und die Person, die die Änderung bildete. Zusätzlich wird ein kompletter Prüfpfad aller Ermächtigungsänderungen in einer anderen Tabelle gehalten.
Der Kennzeichnerbestandteil einer Ermächtigung
Wir denken, daß es lohnend ist, die Gründe zu reiterieren, warum eine Ermächtigung eine unterschiedliche Funktion und einen Kennzeichner hat. Häufig werden Leute autorisiert, eine Funktion nur innerhalb einer organisatorischen Einheit oder eines finanziellen Bereiches zu tun. Leute führen ähnliche Funktionen in den unterschiedlichen Abteilungen durch, aber werden auf ihre eigenen Mittel oder Bereiche begrenzt. Indem man einen Kennzeichner hat, die Zahl Funktionen kann klein gehalten werden, und die Logik, die erforderlich ist, sie in den Systemen zu verarbeiten, die durch das Rollen-DB unterstützt werden, kann verhältnismäßig einfach gehalten werden. Wie oben erwähnt, wenn eine Funktion nicht einen Kennzeichner benötigt, kann die Funktion definiert werden, damit die dazugehörige Kennzeichnerart UNGÜLTIG ist.
Man konnte bitten, wenn Kennzeichner gut sind, warum man nicht mehr als einen Kennzeichner pro Ermächtigung hat? Wir haben gefunden, daß ein Kennzeichner ein guter Kompromiß zwischen Einfachheit und understandability gegen vielseitige Verwendbarkeit ist. Wenn Sie die Sortierung der Rollen, die bevölkeren, haben Sie in einer Geschäftsrichtung, ein Kennzeichner ist im Allgemeinen genug definieren.
Ein typischer Fall würde finanzieller Bericht sein. Es konnte Lots Optionen für das Festlegen von Reports über Aktivität auf einem Konto geben. Man könnte zwei, Kennzeichner für solche Ermächtigungen, die erste für Kontonummer und die Sekunde für eine Liste der möglichen Aktivitäten zu verwenden sich vorstellen, die eine Person berichten könnte über, aber wir haben nicht die Notwendigkeit gefunden, viele unterschiedliche Optionen zu haben hier; bis jetzt nur zwei Optionen sind spezifiziert worden (mit und witho ut salary subtotals), and these have been handled by defining two different functions.
By trying to think in terms of a few simple roles or business functions with a single qualifier, we’ve so far been able to keep the authorizations relatively simple to explain and maintain. In the translation program that converts the Roles-style authorizations into the native format of the target application, in some cases the simple authorization must be translated into a list of complicated options. But this is hidden from the end user, and we’ve kept the Roles function definitions simple and understandable for the people using the Roles Database.
As we mentioned earlier, qualifiers of each type are organized into a hierarchy. For example, organizational units are hierarchical:
When an authorization is created to allow someone to do, for example, personnel reporting, the qualifier selected could be for a lab, a department, or a whole school. This simplifies the process of maintaining authorizations. If the qualifier chosen for an authorization is a branch of a tree and the „leaves“ change, the person’s authorization automatically extends to the new leaves under the tree.
Account numbers are also hierarchically grouped. Their structure is a „web“ rather than a strict hierarchy, ie., an account number can be a member of more than one group.
Who can create, update, or delete authorizations?
The ability to create an authorization is restricted by function and qualifier. An administrative officer in a department will be allowed to grant authorizations for people to perform certain business functions for that department’s resources. For example, an administrative officer (or in our terminology, a Primary Authorizor) within the department of Biology would be able to grant requisitioning authority for any account number within the department of Biology, but not for account numbers in the department of Chemistry. Note that the Primary Authorizor in Biology can grant such an authorization to any person at MIT who has a Kerberos username, not just to people who officially work within the department of Biology.
When granting an authorization, the officer in Biology can decide whether or not the newly-authorized person can further delegate that authorization to others. In this way, a pyramid of responsibility can be defined. A central administrator of the Roles Database needs to know who the Primary Authorizors are for each department, and sets up these people with the authority to create authorizations for resources within their departments. Each of the Primary Authorizors can decide to delegate the authority to grant certain authorizations for the resources of their department or a subset of these resources. Every authorization change is recorded in an audit trail that can be viewed by department heads, auditors, or others to verify that authorizations are being granted according to departmental or institute guidelines.
In the Roles Database, there are two mechanisms for permitting users to create authorizations. Central Roles Database administrators have a „meta-authorization“, an authorization about authorizations, that allows them to create any authorization related to a given system or „function category“. For example, the following authorization would allow JoeRoles to create any authorization within the SAP category.
Person Function Qualifier
JoeRoles Create Authorizations Category SAP (SAP financial system)
Notice that the authority to create an authorization implies the authority to delete or modify the same sort of authorization. In this case, JoeRoles would also be able to delete or modify any authorization within the category SAP.
The second and more common mechanism for permitting users to create, delete, or update authorizations involves the grant flag in an individual authorization. Each authorization has a „grant“ flag that determines whether the person named in that authorization can grant it to others.
If the grant flag is set to Y, the owner of the authorization can grant a new authorization, or delete or change an existing authorization where:
Person is anybody at MIT (with a Kerberos username)
Function is the same function as that in the original authorization
Qualifier is the either the same qualifier or one of its descendents in the hierarchy
Grant-flag is either Y or N
There is also a do_function flag in each authorization that states whether or not the authorization will be effect in the target application. If the do_function flag is set to N and the grant flag is set to Y, then the person can grant the authorization but not perform the business function.
The creation of authorizations with the grant flag equal to Y is the mechanism that would be used to allow a school or department administrative officer, for example an official in the School of Engineering, to set up authorizations for others granting them access to departmental resources. For example, suppose Smith has the following authorization:
Original authorization: Person Function Qualifier Grant-flag
Smith Spend Funds Fund Ctr 100012 (School of Engineering) Y
This would allow Smith to grant an authorization to „Spend Funds“ for all of Fund Ctr 100012, or a subset of it, i.e., any fund or fund center within the School of Engineering. Smith would, for example, be able to grant the following authorizations:
Examples of authorizations Smith could grant: Person Function Qualifier Grant-flag
Jones Spend Funds Fund Ctr 100012 (School of Engineering) Y
Brown Spend Funds Fund Ctr 100056 (Chemical Engineering) N
But Smith would not be permitted to grant the following authorization, because Anthropology is not a subset of the School of Engineering:
Smith can’t grant this: Person Function Qualifier Grant-flag
Rice Spend Funds Fund Ctr 100084 (Anthropology) N
The Software - How Is It Implemented?
The Roles Database system consists of the following software components
An Oracle database running on a DEC Alpha platform.
The database stores authorizations, people, functions, and qualifiers in their respective tables. It has additional tables to keep track of the hierarchical relations between qualifiers, and other miscellaneous information.
A PowerBuilder application, running on client Macintoshes and Windows machines.
The PowerBuilder application is used to
Maintain the list of functions, the 2nd component of authorizations
Maintain authorizations
View authorizations, people, functions, and qualifiers according to a versatile set of reporting options
A set of stored procedures and functions written in PL/SQL.
The stored procedures are used in conjunction with the PowerBuilder application. Security-related processes, such as the checking of meta-authorizations, are implemented in the stored procedures, not in the PowerBuilder front-end.
A set of Perl scripts (using the DBI module for access to Oracle) running on the DEC Alpha.
There are scripts that populate the Person and Qualifier tables each night using data from the Data Warehouse. There are also some scripts involved with transforming Roles-style authorizations into formats usable by SAP. However, for most systems, the transformations of authorization formats are handled by the target system. (See the section on data feeds.)
An Apache web server using Perl CGI scripts running on a separate Sun SPARC station.
The web server was built after the PowerBuilder application, and it provides an easy interface for viewing authorization and other data in the Roles Database. Users access the web interface using Netscape browsers. For web pages that are not „public“, authentication is done using x.509 certificates issued from MIT’s own certificate authority. Any user at MIT with a Kerberos principal can get an MIT-issued certificate that contains the person’s Kerberos principal.
The web interface can be used to
View users’ authorizations in various ways.
View the various qualifier hierarchies, such as Profit Centers and Cost Objects, Organization Units, etc., with or without their related authorizations. The hierarchical displays of these data have turned out to be useful to people at MIT who are not interested in authorizations.
Maintain some types of qualifiers, for the types of qualifiers that are not automatically extracted from data in the Warehouse.
In the future, we plan to enhance to web interface to allow people to maintain authorizations as well, so that the PowerBuilder application will not be needed for anyone except „power-users“.
Data feeds into and out of the Roles Database
The following diagram shows the main areas where data flows into and out of the Roles Database.
The main paths where data flow into or out of the Roles Database are the following:
Supporting information is fed nightly from data warehouse to Roles DB.
These data include a list of people at MIT with their Kerberos usernames, and various types of qualifiers, such as financial objects and organization units. The data are used to populate the Person and Qualifier tables.
The PowerBuilder front-end application is used to create authorizations in the Roles Database, and also to maintain the list of pickable functions.
Authorization information is converted, and transported to various applications.
There are two main ways that authorization data are extracted from the Roles Database for use in target systems:
Target application „pulls“ authorization data from the Roles Database.
This is the preferred scenario.
Authorization data are „pulled“ from the Roles Database using an SQL select statement against a view on the Authorization table.
In this way, a target system can extract a list of authorizations that pertain to it. Where an authorization pertains to a branch of a qualifier tree, the view automatically „expands“ it to show each individual leaf of the tree. Then the target system is responsible for enforcing the authorizations - once authorizations are extracted, the Roles Database is out of the picture.
Roles Database „pushes“ authorization data to target system
Authorization data are periodically processed by a Perl script on the Roles machine to convert them to an external format and then sent to the target application.
This model was used for authorizations for the SAP financial system. We found that we could write the conversion programs more quickly in Perl on the Roles machine than the SAP developers could write them in ABAP/4. There still is an ABAP/4 component, however, which takes flat files of SAP-authorization and SAP-profile changes and applies them to the SAP system. Again, once the authorization information has been pushed to SAP, the Roles Database is out of the picture and has nothing else to do with enforcing the authorizations.
On each of the target systems, users either log on and are authenticated using the Kerberos usernames, or for web-based systems, they are authenticated based on the username contained in their x.509 certificate. Each system checks authority to perform each transaction by comparing the username and desired function and qualifier against its locally stored table of authorizations.
Where are we today?
The Roles Database is used or soon will be used to maintain authorizations for several systems at MIT. So far, only part of the task of the maintaining authorizations has been distributed to the various departments, but the task of defining guidelines and writing documentation is proceeding, as is a phased roll-out of the Roles application to one department at a time. Also at this time, new systems at MIT are adopting the Roles Database for maintaining their authorizations, so the use of the Roles Database is expanding in this dimension also.
Many users across the campus use the web interface for viewing trees of financial objects and related authorizations, and the easy access to the data have made it easier for departments to identify mistakes in their department’s authorizations. Even in the cases where the department is not yet using the Roles application to directly input their authorization changes into the system, the simplified reports of authorizations available via the web interface has made it easier for them to send requests for changes to central system administrators. The next phase of our roll-out will allow more departments to make these changes themselves, and we will see more time savings.
The following systems are using or soon will be using the Roles Database for maintaining authorizations at MIT:
SAP financial system
The Roles Database has been used for maintaining authorization information for SAP since June, 1998. Most of the activity in the Roles Database pertains to SAP authorizations. The availability of web-based reports on departmental authorizations has been essential for some steps of the roll-out of SAP to various departments at MIT. As more components of SAP are adopted at MIT, we will support their authorizations with the Roles Database. Distribution of authorization maintenance is expected to reap the greatest time savings for SAP-related authorizations.
Graduate Admissions system
The locally-developed Graduate Admissions system has also used the Roles Database for maintaining their system authorizations since early 1998. Because the system is based on an Oracle database, it was particularly easy to integrate it with Roles-based authorizations. Maintenance of authorizations is currently done centrally in the admissions office, but there are plans to distribute this maintenance to the departments at some undetermined date in the future.
Data warehouse
MIT’s locally-developed data warehouse currently shares SAP financial reporting authorizations to control viewing of financial data. The Roles DB will soon control authorizations for viewing of personnel data. In the warehouse, converted authorizations are used as a joined table for VIEWs of financial data. This implementation was also relatively easy.
Budget system
MIT has a locally-developed budget system, called NIMBUS, that has used the Roles Database for its authorizations since it went into production earlier this year. Authorizations are currently centrally maintained by the budget office; distribution of maintenance will be discussed at a later date.
Checking of paper Invoices and Travel Documents
The Roles Database is used to store people’s authority to sign paper documents. This summer, it replaced the authorization-checking component of a locally-developed Electronic Requisition System which was phased out after SAP was put into production. People in the Procurement, Travel, Physical Plant, and other offices use the web interface to check the authority of signers of paper documents. (The Roles application does not store digitized signatures or help to combat forged signatures.)
Central IT infrastructure systems
The Roles Database is used to maintain the authorizations for assigning MIT ID numbers and for performing system-related tasks in the Roles Database itself.
Plans for the future
We’ve already mentioned the ongoing work (a) to support the authorizations for more systems at MIT and (b) to continue distributing the job of maintaining authorizations to local departments. In addition, we’re planning the following technical enhancements.
Hierarchicalize functions
Currently, the third component of an authorization, the qualifier, is part of a hierarchy. An authorization for a node in a tree applies to all the leaves as well.
It makes sense to do something similar for function component. A good example comes from some common financial tasks. There currently are four separate functions for „requisition approver,“ „invoice approver,“ „travel documents approver,“ and „financial reporting,“ but in many cases the same person does all four things. So it would make sense to have a parent function, „general financial approver,“ that would have the other four functions as children in a tree of functions. Then a person authorized as „general financial approver“ for the department of biology would automatically have the equivalent of four authorizations, as „requisition approver,“ „invoice approver,“ „travel documents approver,“ and „financial reporting,“ all for the department of biology.
When this enhancement is put into place, extracts of authorizations from the Roles Database will not only expand the qualifiers to show all the leaf-level qualifiers for each authorization, but expand the functions as well.
Create a consolidated tree that includes different types of qualifiers
As a result of the history of stovepipe systems at MIT, there are several versions of a department hierarchy. Personnel organization units, financial profit centers, and financial fund centers all are organized into similar but different hierarchies that represent someone’s view of MIT’s organization structure.
We want to be able to define departmental Primary Authorizors, people who are responsible for setting up authorizations for departmental resources. But there is no single integrated department hierarchy that is linked to qualifiers of various types. To set up a Primary Authorizor for the department of Biology, one needs to define meta-authorizations for SG_BIOLOGY (the top node of Biology’s spending groups), FC100108 (the top node of Biology’s fund centers), 0HPC0000501 (the top node of Biology’s profit centers), and 151000 (Biology’s organizational unit).
Once there is general agreement on a single departmental hierarchy at MIT, with a commitment to maintain links to the various objects associated with each department, it will be possible to create a single Primary Authorizor meta-authorization that covers the creation of any authorization related to a department’s resources. In addition, it will be easy to display on a single report all authorizations related to a department’s resources.
The work involved in developing and maintaining a single overarching department hierarchy at MIT will involve as much political effort as it will technical effort.
Enhance the web interface
We plan to enhance the web interface so that people with the proper „meta-authorizations“ will be able to create authorizations using their Netscape browser. At a later date, we will decide whether to keep maintaining our existing PowerBuilder application or to roll all of its functionality into a more comprehensive web interface.
=======
…und noch ne site neueren Datums zum Thema
http://web.mit.edu/rolesdb/&prev=/search%3Fq%3DRoles…
=======
gruss
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
„Die Rolle beschreibt den Aufgabenbereich eines Bearbeiters. Jeder Bearbeiter kann eine oder mehrere Rollen haben, mehrere Bearbeiter können die gleiche Rolle haben.“
Eigentlich ganz einfach, oder?
Gruß, Stephan
Hi,
sieh dir dazu mal die Seiten von:
an. Dort werden eine ganze Reihe von pdf-Dateien angeboten, wo genau die einzelnen Bestandteile (auch Rollen) erklaert werden.
Viele Gruesse