[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]

Business Layer

Hier werden die Komponenten entworfen, die eigentlichen Geschäftsregeln enthalten.

Beispiel :

DEFINE CLASS clsBusiness AS CUSTOM OLEPUBLIC

 

   oMTX = NULL

   oContext = NULL

 

PROCEDURE clsBusiness.TransferMoney

 

LPARAMETERS tnAccountSrc, tnAccountDest, tyAmount

 

THIS.oMTX = CREATEOBJECT(MTX_CLASS)

THIS.oContext = THIS.oMTX.GetObjectContext()

 

* Parameter überprüfen

IF VARTYPE(tnAccountSrc) != "N" THEN

   RETURN ERROR_WRONG_TYPE

ENDIF

 

IF VARTYPE(tnAccountDest) != "N" THEN

   RETURN ERROR_WRONG_TYPE

ENDIF

 

IF VARTYPE(tyAmount) != "Y" THEN

   RETURN ERROR_WRONG_TYPE

ENDIF

 

* Geld abbuchen

loDBKundenSrc = THIS.oContext.CreateInstance("DBWest.Accounts")

lnRetVal = loDBKundenSrc.Update(tnAccountSrc, -tyAmount)

IF lnRetVal != ERROR_SUCCESS THEN

      THIS.oContext.SetAbort()

      RETURN ERROR_ACCESS

ENDIF

 

* Geld aufbuchen

loDBKundenDest = THIS.oContext.CreateInstance("DBEast.Accounts")

lnRetVal = loDBKundenSrc.Update(tnAccountSrc, tyAmount)

IF lnRetVal != ERROR_SUCCESS THEN

   THIS.oContext.SetAbort()

   RETURN ERROR_ACCESS

ENDIF

THIS.oContext.SetComplete()

 

RETURN ERROR_SUCCESS

 

PROCEDURE Error

   THIS.oContext.SetAbort()

ENDPROC

 

ENDDEFINE

Presentation Layer

Web Browser

Hierbei wird eine ASP-Seite verwendet, die mit Hilfe des IIS-auf eine Komponente des Business-Layer zugreift.

Client-Anwendung

Dies kann jede beliebiges Programm sein, welches in der Lage ist, COM-Server aufzurufen wie WORD, EXCEL, ACCESS, VISUAL BASIC.

Zugriffsrechtverwaltung

Für die Entwicklung von gesicherten Anwendungen ist das Security-Modell von NT ist sehr beschränkt und schwer zu verwalten. Mit NT-Security impersonifiziert die MTS-Komponenteninstanz den Client und arbeitet im Security-Kontext des Clients bei allen Zugriffen. Dies bietet eine ausreichende Sicherheit für alle Objekte, die der Client direkt anspricht. Allerdings führt dies auch zu einigen Performance- und Zugriffsrechtproblemen. 

Zunächst benötigt der Client Rechte auf alles, was er zugreift. Wenn jeder Client auf verschiedene andere Komponenten zugreift, eine Systemresourcen und eine Datenbank und es existieren Tausende von Clients wird die Verwaltung zu einem Alptraum. Weiterhin ist die gemeinsame Nutzung und Pooling von Resourcen begrenzt. Wenn die NT-integrierte Zugriffsrechtsverwaltung in Zusammenhang mit einer SQL SERVER-Datenbank benutzt wird und der Client in der Komponente impersonifiziert wird, ist 'Connection Pooling' unmöglich'. Jeder Client braucht jedes mal eine neue Verbindung. Dies führt zu einer Verschlechterung der Leistung.

Die Zugriffsrechtsverwaltung in MTS wird über Rollen durchgeführt. Wie bereits zuvor erwähnt, sind die Rollen als symbolische Namen für eine Auflistung von Gruppen/Benutzern mit bestimmten Zugriffsrechten zu sehen. Rollen werden auf Paketebene definiert und Komponenten innerhalb eines Pakets können zu einer oder mehreren Rollen zugewiesen werden. Das nachfolgende Bild zeigt ein Paket 'devcon1', welches 3 Rollen enthält. Nur die letzten beiden Komponenten enthalten eine Rollenmitgliedschaft.

Wenn man den Roles-Ordner weiter öffnet, sieht man eine Liste von NT Benutzern/Gruppen, die zu einer bestimmten Rolle zugeordnet sind. Um ein neue Rolle zu erstellen, geht man folgendermaßen vor :

  1. Klicken Sie auf den Roles Ordner.
  2. Wählen Sie NEW - ROLE aus dem Menü Action.
  3. Geben Sie einen Namen für die Rolle an.

Um neue Benutzer/Gruppen zu der Rolle hinzufügen, geht man folgendermaßen vor :

  1. Klicken Sie auf den Users-Ordner in der neuerstellten Rolle.
  2. Wählen Sie NEW - USER aus dem Menü Action.
  3. Wählen Sie die entsprechenden Benutzer/Gruppen von dem Dialog.

Die Zugriffsrechte innerhalb MTS können auf verschiedene Arten verwaltet werden. Das Sicherheitskonzept von MTS besteht aus deklarativer unf programmatischer Sicherheit. Entwickler können in Ihren Komponenten beide Arten verwenden, bevor sie sie in einer mit Windows NT gesicherten Domäne verteilen.

Man kann die Zugriffsrechte der Pakete innerhalb des MTS Explorers verwalten. Diese Form der deklarativen Sicherheit, die keinerlei Komponentenprogrammierung benötigt, basiert auf dem Standard NT Sicherheitskonzept. Dies kann über die Verwaltung der Zugriffsrechte auf Paket- oder Komponentenebene geschehen.

Setzen der System-Paket Identität

Vor allen anderen Maßnahmen in MTS, sollte man das System Paket konfigurieren, um die Verwaltung der Zugriffsrechte zu ermöglichen. Setzen Sie die System Paket Identity, bevor Sie ein neues Paket erzeugen.

  1. Erzeugen Sie eine neue lokale Windows NT Gruppe mit Namen “MTS Administratoren” und einen neuen lokalen Benutzer “MTS Administrator”.
  2. Fügen Sie den Benutzer “MTS Administrator” zu den “MTS Administratoren” und “Administratoren” hinzu.
  3. Setzen Sie die Identität des System-Pakets auf “MTS Administrator”. Bedenken Sie: Falls dies nicht funkionieren sollte, versuchen Sie den Benutzer “Administrator”, jedoch kann man die Identität eines Paketes nicht auf eine Gruppe setzen.
  4. Fahren Sie das System-Paket herunter, so daß es mit der neuen Identität gestartet wird. Dies kann durch die Auswahl von ‘Shut Down Server Process’ im Kontextmenü von ‘My Computer’ geschehen.

Hinzufügen von Zugriffsrechten zu einem MTS Paket

  1. Zunächst sollte man entscheiden, ob man auf alle Komponenten eines Paketes Zugriffsrechte vergeben will oder nur auf einzelne. Wählen Sie aus dem Kontextmenü des entsprechenden Paketes PROPERTIES – SECURITY. Aktivieren Sie das ENABLE AUTHORIZATION CHECKING-Kontrollkästchen. Um die Zugriffsrechte auf Komponentenebene zu definieren, führen Sie das gleiche mit der entsprechenden Komponente durch.
  2. Nachdem dies geschehen ist, erhalten Sie eine “Access is denied”-Fehlermeldung, falls Sie versuchen, auf die Komponente zuzugreifen. Man MUSS eine gültige Rolle für jede Komponente haben, auf die Zugriffsrechte vergeben worden sind.
  3. Wählen Sie NEW ROLE aus dem Kontextmenü der Rollen des Paketes. Geben Sie einen funktionellen Namen für die Rolle an wie Manager, Accountants. Die neue Rolle wird als Unterordner eingetragen. Danach kann man in dieser Rolle neue Benutzer hinzufügen.
  4. Definieren Sie, welche Rollen Zugriff auf die Komponente Haben sollen.

Bemerkung : Falls weiterhin eine “Access is denied”-Fehlermeldung erscheint, wenn Sie die Komponente aufrufen, gibt es weitere mögliche Lösungen :

  • Manchmal scheitert das Hinzufügen einer Gruppe zu einer Rolle. Aus diesem Grund sollte man einzelne Benutzer zu einer Rolle hinzufügen.
  • Die Benutzerrechte für diesen Benutzer sind nicht korrekt gesetzt. Stellen Sie sicher, daß der Benutzer für die Identitäten des System-Paketes und andere MTS Pakete das Windows NT-Recht “Log on as a service”. Dies kann mit dem Windows NT-Benutzermanager überprüfen:
  1. Wählen Sie POLICIES – USER RIGHTS -SHOW ADVANCED USER RIGHTS

Deklarative Sicherheit

Sicherheit auf Ebene von Paketen

Jedes Paket hat seine eigene Zugriffsrechtsverwaltung, welche in dem Paketeigenschhaften-Dialog gesetzt werden kann.

Standardmäßig ist das Kontrollkästchen für die Zugriffsrechtsverwaltung nicht markiert, so daß dies gesetzt werden muß, um die Zugriffsrechtsverwaltung einzuschalten. Falls die Zugriffsrechtsverwaltung für das Paket nicht aktiviert wird, die Rollen für die Komponenten werden von MTS nicht überprüft. Sobald die Zugriffsrechtsverwaltung auf Paketebene aktiviert ist, muß auch Zugriffsrechtsverwaltung auf Komponentenebene aktiviert sein, damit die Rollen überprüft werden.

Sicherheit auf der Ebene von Komponenten

Jede installierte Komponente kann ebenfalls ihre eigenen Einstellungen zur Zugriffsrechtsverwaltung haben. Genau wie bei einem Paket wird die Zugriffsrechtsverwaltung durch Setzen des Enable authorization checking Kontrollkästchens im Eigenschaftsdialog der Komponente gesetzt. Wenn die Zugriffsrechtsverwaltung auf beiden Ebenen aktiviert und ebenfalls Rollen definiert, muß eine Rollen in die Role Membership-Ordner der Komponenten eingefügt werden. Falls dies nicht geschieht, erhält man einen Access Denied-Fehler, falls man versucht, eine Methode/Eigenschaft der Komponente aufzurufen. Falls überhaupt keine Rollen vorhanden sind, tritt derselbe Fehler auf. Man kann zwar eine Instanz mit CREATEOBJECT() erzeugen, aber spätestens beim Aufruf einer Methode erhält den gleichen Fehler.

loContext = CREATEOBJECT("vfp_mts.mts1")

loContext.Hello() && erzeugt einen Access is denied Fehler

Wenn man den Zugriff zu einer bestimmten Komponente innerhalb eines Paketes begrenzen will, ist ein Verständnis der Aufrufe der Komponenten untereinander wichtig. Wenn eine Komponente von einem Base Client aufgerufen wird, überprüft MTS die Rollen für die Komponente. Wenn eine Komponente von einer anderen Komponente aufgerufen wird, wird keine Überprüfung vorgenommen. Die Komponenten glauben (trust) sich untereinander.

Nach einer Änderung der Einstellungen der Zugriffsrechte für eine bestimmte Komponente/Paket muß der Server heruntergefahren werden, bevor die Änderungen wirklich stattfinden. Diese Option ist in dem Menü ACTION verfügbar, sobald das Paket ausgewählt ist.

Programmatische Sicherheit

Man kann programmatisch bestimmte Zugriffsrechte abfragen. Die folgenden 3 Methoden/Eigenschaften geben Informationen zurück, die Zugriffsrechte für dieses Paket/Komponente betreffen.

Methoden/Eigenschaft Beschreibung

IsCallerInRole()

Gibt zurück, ob der direkte Aufrufer einer Komponente in einer bestimmten Rolle ist (entweder direkt oder als Bestandteil einer Gruppe)

IsSecurityEnabled()

Gibt zurück, ob die Zugriffsrechtsverwaltung aktiviert ist.

Security

Gibt eine Referenz auf das Security-Objekt des Kontext zurück.

Die nachfolgende Methode überprüft, ob der Aufrufer in einer bestimmten Rolle ist. Die IsCallerInRole()-Methode ist nützlich, sobald Rollen definiert sind, aber wenn der Code generisch sein soll und man nicht weiß, ob bestimmte Rollen einer Komponente zugeordnet sind, sollte man dies über eine Fehlerroutine machen.

PROCEDURE GetRole (tcRole)

 

LOCAL loMTX, loContext, llSecurity, lcRole, llHasRole

IF EMPTY(tcRole)

   RETURN "No Role"

ENDIF

 

loMtx = CREATEOBJECT(MTX_CLASS)

loContext = loMtx.GetObjectContext()

IF loContext.IsSecurityEnabled()

   THIS.SkipError=.T.

   llHasRole = loContext.IsCallerInRole(tcRole)

   THIS.SkipError=.F.

   DO CASE

      CASE THIS.HadError

         THIS.HadError = .F.

         lcRole="Bad Role"

      CASE lHasRole

         lcRole="Yep"

      OTHERWISE

         lcRole="Nope"

   ENDCASE

ELSE

   lcRole="No Security"

ENDIF

   loContext.SetComplete()

RETURN lcRole

 

ENDPROC

Erfahrene Benutzer können auf die Security-Eigenschaft des Kontextobjektes zugreifen, um mehr Informationen über den Benutzer zu erhalten. Die Security-Eigenschaft bietet die folgenden zusätzlichen Informationen :

Method Description

GetDirectCallerName

Gibt den Benutzernamen des externen Prozesses zurück, der die aktuell ausgeführte Methode aufgerufen hat.

GetDirectCreatorName

Gibt den Benutzernamen des externen Prozesses zurück, der das aktuelle Objekt erzeugt hat.

GetOriginalCallerName

Gibt den Benutzernamen des Prozesses zurück, der Aufrufreihenfolge verursacht hat, von der die aktuelle Methode aufgerufen wurde.

GetOriginalCreatorName

Gibt den Benutzernamen des Prozesses zurück, welcher die Aktivität initialisiert hat, in der das aktuelle Objekt ausgeführt wird.

Welche Art von Zugriffsrechtsverwaltung sollte man nun nutzen ? Programmatische Sicherheit bietet mehr Möglichkeiten, wenn man bestimmte Funktionalitäten für bestimmte Rollen definieren will. Man kann CASE-Strukturen aufbauen, die unterschiedliche Aufgaben in Abhängigkeit der Rolle des aufrufenden Komponente durchführen. Deklarative Sicherheit kann nur Zugriffsrechte auf Komponentenebene vergeben, nicht auf Methoden- oder Eigenschaftsebene. Änderungen der programmatischen Sicherheit erfordern eine Neukompilierung der Komponente, was manchmal nicht durchführbar ist. Die Möglichkeit über den MTS Explorer die Zugriffsrechte von Benutzern zu ändern, gibt dem Administrator größere Flexibilität. Die optimale Lösung ist eine Mischung aus der Benutzung deklarativer und programmatischer Sicherheit.

Tips für VFP Benutzer

Vieles in der Zugriffsrechtsverwaltung kann über die MTS Admin-Objekte per OLE-Automation durchgeführt werden. Dies kann erledigt werden im AfterBuild-Ereignis einer ProjektHook-Klasse, die mit dem Projekt verbunden ist, daß die MTS COM DLL erzeugt.

Verteilung

MTS bietet auch Werkzeuge zur Verteilung von sowohl client- als auch serverseitigen Setups. Setups werden auf Ebene ein Pakets durchgeführt. Aus diesem Grunde ist es sinnvoll, alle Komponenten für eine Anwendung ist einem Paket unterzubringen. Dieses Deployment-Paket enthält alle Einstellungen zur Konfiguration von DCOM, so daß keine Einstellungen in dem DCOM Konfigurationsdialog nötig sind. Ein Setup kann wie folgt erzeugt werden :

  1. Klicken Sie auf das Paket, für das Sie ein Setup machen will.
  2. Wählen Sie Export… vom Menü Action. Der Export Dialog wird dargestellt.

Wichtig:Es reicht nicht, nur einen Pfad einzugeben, sondern man muß den kompletten Pfad einschließlich des Namens der PAK angeben, wie oben dargestellt.

Man kann hierfür auch die Administration Objekte verwenden, um ein Script zu erzeugen, daß den Vorgang automatisiert.

Die Ausgabe des Exports besteht aus zwei Setups:

Server Setup

Dieses Setup, welches in dem Ordner abgespeichert wird, welcher im Export Dialog angegeben wurde, enthält die PAK Datei und alle COM DLL Server, die von diesem Paket benutzt werden.

 

Mit Visual FoxPro ist außerdem eine TLB-Datei (Type Library) enthalten. Man kann dieses Paket auf einem anderen Rechner installieren, indem man wie unten dargestellt die Option 'Install pre-built packages' von Paket-Assistenten verwendet.

[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]