JSF Zugriff für Helpdesk-Mitarbeiter

Diskutiere Zugriff für Helpdesk-Mitarbeiter im Web Tier Forum; Hallo allerseits Wir habe eine Web-Applikation, die mit JSF realisiert wurde und sich seit einigen Monaten im Einsatz befindet. Zurzeit haben...

  1. rmacher
    rmacher Neues Mitglied
    Hallo allerseits

    Wir habe eine Web-Applikation, die mit JSF realisiert wurde und sich seit einigen Monaten im Einsatz befindet. Zurzeit haben wir ca. 600 Benutzer. Da wir in der Einführungsphase sind, wurde ein Helpdesk eingerichtet, um User, die Mühe bei der Arbeit mit der Applikation haben, zu unterstützen. Dies wäre manchmal um einiges einfacher, wenn der Helpdesk-Mitarbeiter die gleiche Sicht wie der User hätte, der angerufen hat. Und, diese Möglichkeit soll jetzt auch zur Verfügung gestellt werden.

    Wie könnte man so etwas (konzeptionell) implementieren?

    Folgende Anforderungen sollten dabei erfüllt sein:
    • Der Helpdesk-Mitarbeiter sollte die Identität des Users, der Hilfe braucht, übernehmen bzw. in seine Rolle schlüpfen können.
    • Der User, der Hilfe braucht, sollte sein Passwort weder bekanntgeben noch zurücksetzen müssen.
    • Der User, der Hilfe braucht, muss die Nutzung seiner Identität explizit zulassen.
    • Wenn die Helpdesk-Arbeit erledigt ist, muss die Session beendet werden, die temporär ausgeliehene Identität wird dem Helpdesk-Benutzer entzogen
    • Es muss sicher und vertrauenswürdig sein: Es soll nicht der Eindruck entstehen, dass Helpdesk da etwas verdächtiges mach.

    Wie kann man so etwas sinnvoll und mit einem "vertretbaren Aufwand" realisieren?

    Vielen Dank für jeden Tipp.
     
  2. Vielleicht hilft dir das kostenlose Training weiter --> (hier klicken)
  3. CptSocket
    CptSocket Mitglied
    Hallo

    Spanndende Aufgabe :)

    Wie wird ermittelt, welche Sicht ein Benutzer annehmen kann? (Und wie unterscheiden sich die Sichten der verschiedenen Benutzer - nur in den Daten oder auch Funktionalität?) Ich gehe davon aus, dass mittels Context.getCallerPrincipal() der eingeloggte Benutzer und dessen Berechtigungen ermittelt werden?
    Wird der eingeloggte Benutzer weiterverwendet (z.B. für Security Propagation beim Zugriff auf weitere Systeme)?

    Ich könnte mir folgendes Konzept vorstellen:
    (Etwas ähnliches kenne ich von einer produktiv eingesetzten Applikation mit einer ähnlich grossen Anzahl Benutzern. Da geht es zwar nicht um die Identität des Benutzers, sondern eher um dessen Benutzergruppe, das Konzept sollte aber übernehmbar sein)


    • Der Webclient ermittelt mit des Servicecalls getMoeglicheIdentitäten() die Identitäten, mit welchen der eingeloggte Benutzer arbeiten darf. Dies ist normalerweise nur eine Identität (die des eingeloggten Benutzers), im Fall Helpdesk können es aber mehrere sein.
    • Wenn mehr als eine Identität möglich ist, muss der Benutzer wählen, welche er verwenden möchte.
    • Bei jedem Servicecall (bei welchem die Identität eine Rolle spielt) muss die gewählte Identität mit übergeben werden
    • Der Service muss prüfen, ob der eingeloggte Benutzer berechtigt ist, die angegebene Identität zu verwenden.
    • Der Zugriff auf die Daten oder Funktionalität wird nicht aufgrund Context.getCallerPrincipal() sondern der übergebenen Identität gesteuert. (Was nicht funktioniert, wenn mit dem eingeloggten Benutzer auf weitere Systeme zugegriffen werden muss. Gibt es in der Applikation diesen Fall?)

    Zu den zusätzlichen Anforderungen (explizites freigeben, Identität zurückgeben, ...):
    • Die genannten Anforderungen machen das System kompliziert. Sind die Anforderungen so wirklich notwendig? Falls die Daten in der Applikation nicht extrem kritisch / schützenswert sind, würde ich versuchen, die Anforderungen zu entschärfen:
      • Jedesmal, wenn jemand eine 'fremde' Identität übernimmt, wird diese Aktion geloggt.
      • Wenn sich jemand einloggt, wird ihm angezeigt, wer im letzten Monat (?) wann seine Identität übernommen hat / welche Aktionen mit seiner Identität ausgelöst wurden.
      • Pro Helpdesk Mitarbeiter könnte ein Reporting erstellt werden, welches zeigt, welche Identitäten er übernommen hat / was er mit den Identitäten angestellt hat.
      • Die Berechtigung, fremde Identitäten übernehmen zu können sollte nur möglichst wenigen Personen erteilt werden.
    • Ansonsten:
      • Der Benutzer hat in der Applikation die Möglichkeit, seine Identität 'freizugeben'
        (Die Identität könnte auch für eine bestimmte Person freigegeben werden)
      • Dieses Freigeben wird irgendwo festgehalten (DB-Tabelle?)
      • Wenn sich ein Helpdesk-Mitarbeiter einloggt, wird aufgrund dieser Tabelle geprüft, welche Identitäten freigegeben sind.
      • Wenn der Helpdesk-Mitarbeiter die Identität zurückgibt, wird sie aus der Tabelle wieder entfernt. Oder der Benutzer kann die Freigabe wiederrufen. Beim nächsten Servicecall durch den Helpdesk-Mitarbeiter merkt der Service, dass die Identität nicht mehr freigegeben ist und wirft einen entsprechenden Fehler.


    Trifft das so in etwa deine Vorstellungen?


    Freundliche Grüsse
    CptSocket
     
  4. Gucky
    Gucky Aktives Mitglied
    Mal ne ganz doofe Lösung: TeamViewer?

    Ansonsten könnte man mit temporären Passwörtern arbeiten. Die Nutzer können einen Button temporäres Passwort erzeugen klicken, woraufhin in einem Fenster, Textfeld usw. das temporäre Passwort erscheint. Dieses ist generiert und nur für einmaliges Einloggen verwendbar (auch praktisch für Admins, falls jemand seine Nutzerdaten vergessen hat).
    Das Passwort erlaubt aber nur eine Art abgespeckten Zugriff (kritische Operationen sind nicht möglich, Änderungen sind nicht möglich, Datenfelder werden mit Beispieldaten gefüllt, etc. Da gibt es genug Möglichkeiten)
    Hat sich jemand mit einem temporären Passwort eingelggt, so wird der Button ausloggen durch temporäre Sitzung beenden o.Ä. ersetzt, damit der Hauptnutzer nicht rausgeschmissen wird. Das Einloggen mit temporären Passwörtern wird aufgezeichnet und alles, was während dieser temporären Sitzung getan wurde, auch. Außerdem taucht irgendwo ein Lämpchen Temporäre Sitzung aktiv auf. Die temporäre Sitzung kann vom Hauptnutzer beendet werden.

    Das ist jetzt sehr chaotisch aber so könnte ich mir die Umsetzung vorstellen ;)
     
  5. Thallius
    Thallius Bekanntes Mitglied
    Ich denke so etwas selbst zu programmieren ist sehr aufwendig und es gibt eben schon genug Tools die das bieten. Erst Wahl für Firmen wäre z.B. WebEx.

    Gruß

    Claus
     
  6. rmacher
    rmacher Neues Mitglied
    @CptSocket

    Zuerst einmal vielen Dank.

    An sich sollte der Helpdesk-Mitarbeiter (HDM) die Rolle des Benutzers übernehmen und im Grunde alles machen können, was der Benutzer selbst machen kann. Der Benutzer soll dies auch verfolgen können. Wenn der HDM etwas ändern würde (ein Schreibzugriff), würde der Benutzer nach einem Refresch die getätigte Änderung auch sehen etc. Aus diesem Grund wäre ideall, wenn der HDM sich quasi als Benutzer anmelden könnte.

    Nein. Aus der Applikation ist kein Zugriff auf weitere Systeme möglich.

    Wir haben teilweise kritische Daten und möchten nicht den Eindruck vermitteln, dass die HDM die Identität von einem beliebigen Benutzer nach Lust und Laune übernemen kann.

    Hier habe ich noch etwas Mühe:
    Was ist jetzt unter "Freigabe der Identität" zu verstehen?

    Ich stelle es mir so vor, dass sich der HDM als Benutzer anmeldet. Dazu müsste er das Passwort des Benutzers haben. Da alle Passwörter verschlüsselt verwaltet werden, habe ich keinen Zugriff auf das Passwort im Klartext.

    Heisst, der Benutzer müsste in einem passenden Help-Formular noch sein Passwort eingeben. Das Passwort würde ich in einer Tabelle vorübergehend ablegen. Der HDM klickt auf "Als username anmelden": Das vorübergehend abgelegte Passwort wird geholt und der HDM als Benutzer angemeldet. Wenn sich der HDM angemeldet hat, könnte ich das vorübergehend abgelegte Passwort sofort löschen.

    Aber, schon die Tatsache, dass man das Passwort eingeben muss, wird keine Freude auslösen.

    Oder, meinst du mit der "Freigabe der Identität" etwas anderes?

    Ich verwalte in der Benutzer-Session seinen Benutzernamen und seine Rolle, mit der er angemeldet ist und auf diese könnten ich noch zugreifen.
     
    Zuletzt bearbeitet: 29. Nov. 2014
  7. rmacher
    rmacher Neues Mitglied
    @Gucky

    Wäre natürlich ideall, aber unsere Benutzer wären damit überfordert. Wir stellen leider fest, dass die Hinweise, die mehr als klar geschrieben und mit passenden Screen-Abbildungen angereichert sind, auch nicht helfen: Die Anweisungen werden entweder nicht gelesen oder nicht verstanden. Etwas ältere Benutzer sind eben die kritische Gruppe.

    Die Idee mit temporären Passwörtern sieht aber interessant aus: Da liesse sich was machen.

    Vielen Dank,

    rm
     
    Zuletzt bearbeitet: 29. Nov. 2014
  8. rmacher
    rmacher Neues Mitglied
    @Thallius

    Vielen Dank für den Tipp.

    Ich kenne WebEx nicht und müsste es zuerst anschauen.

    Gruss,

    rmacher
     
  9. Gucky
    Gucky Aktives Mitglied
    Also sooooooooo kompliziert finde ich den TeamViewer nicht. Und der ist auch schnell erklärt. Der HDM könnte das auch schnell am Telefon erklären und du müsstest dich nicht mit komplizierten Mechanismen rumschlagen. Du müsstest nur dafür sorgen, dass sämtliche Versionen auf allen Rechnern zu jeder zeit exakt dieselben sind.
    Der HDM könnte den PC übernehmen und direkt Dinge zeigen, da er den PC steuern kann. Trotzdem kann die Person, der der PC gehört jederzeit die TeamViewer-Sitzung beenden.
    Das Dumme am TeamViewer ist nur, dass der etwas kostet aber da muss man gucken, was teurer ist: Jemand, der alles programmiert oder der TeamViewer.
    Jetzt, wo ich länger darüber nachdenke, wäre das sogar die beste Lösung, die mir einfiele. Ein temporäres Passwort wäre natürlich cool aber dann kann man nicht oder nur mit immensem programmiertechnischen Aufwand Dinge direkt zeigen.
    Und es müsste noch eine Funktion "Kick all temps" oder so Ähnlich geben (ich weiß nicht, welcher Nationalität die Mitarbeiter sind:))


    Alternativ ginge auch noch ShowMyPC.
     
  10. JavaMeister
    JavaMeister Gesperrter Benutzer
    Ich habe glaube ich das Problem nicht verstanden.

    Wieso muss ich irgendwas mit Passwörtern hin und her schubsen?

    Meine Webanwendung hat eine Session. Da drin steht, welcher Principal (User) aktuell eingeloggt ist. (e.g. ID)

    Wenn ich Admin bin, dann muss ich diese ID nur durch den User, den ich inpersonaten möchte austauschen... Und schwubs, sehe ich genau die gleiche Anwendung, wie der User. Muss mich dann noch ggf. zu dem Anwendungsfall hinklicken, aber mehr auch nicht.

    Wann ich nun diese ID übernehmen kann, kann man frei sich ausdenken. Z.b. über eine vorherige Einladung durch den User. Das ist dann aber nur ein Element in der Tabelle oder in der AppSession transient zu verwalten..
     
  11. rmacher
    rmacher Neues Mitglied
    @Gucky

    Nun, die Kosten sind das eine Problem. Das andere Problem könnte unsere IT sein: Ich bin mir nicht sicher, ob die IT den TeamViewer-Zugriff auf Systeme, die von der IT installiert und gewartet werden, zulassen würde. Das müsste ich auch zuerst abklären.

    Danke und Gruss,

    rmacher
     
    Zuletzt bearbeitet: 29. Nov. 2014
  12. rmacher
    rmacher Neues Mitglied
    Hm, das klingt vielversprechend.

    Könntest du es evtl. etwas genauer erläutern, wie dies laufen sollte?

    - Die Einladnung des Benutzers sollte mir die Principal-Id (aus seiner Session) zur Verfügung stellen.
    - Wenn ich diese habe (wie auch immer), gehe ich in meine Session, hole die Principal-Id und ersetzte sie mit der Principal-Id, die mir bei der Einladung zur Verfügung gestellt wurde.

    Oder, habe ich da was verwechselt?

    Ergänzung:
    Ich bekomme jetzt immer null, wenn ich Principal holen versuche und habe in einem Forum gesehen, dass dies nur dann funktioniere, wenn man mit Realm (Tomcat) arbeitet:

    retrieve current authenticated user name (JSF forum at JavaRanch)

    Code (Java):

    // Principal holen
    Principal p = FacesContext.getCurrentInstance().getExternalContext().getUserPrincipal();
     
    Wir arbeiten mit Tomcat, nutzen aber die "container managed authentication" nicht.

    Vielen Dank,

    rmacher
     
    Zuletzt bearbeitet: 29. Nov. 2014
  13. stg
    stg Bekanntes Mitglied
    Eine weitere Alternative, und (vermutlich) weit weniger problematisch, wäre z.b. Lync (Microsoft Office)
     
  14. rmacher
    rmacher Neues Mitglied
    Danke für den Tipp.
     
  15. CptSocket
    CptSocket Mitglied
    Hallo

    Sehr wahrscheinlich ist momentan in der Applikation folgendes Konzept implementiert:

    Eingeloggter Benutzer ---ist-berechtigt-für--> Funktionalität/Daten

    Wenn ein HDM die Funktionalität/Daten eines Benutzers sehen will, muss er sich also als Ziel-Benutzer ins System einloggen -> er muss die Logindaten kennen (entweder die 'richtigen' Logindaten oder ein temporäres Passwort). Das Konzept von meiner vorherigen Antwort fügt eine Indirektion ein:

    Eingeloggter Benutzer ---ist-berechtigt-für--> Identität ---erlaubt-Zugriff-auf--> Funktionalität/Daten

    Bei diesem Modell muss sich der HDM nicht mehr als Ziel-Benutzer einloggen, er muss lediglich die Berechtigung haben, die Identität des Ziel-Benutzers zu verwenden.
    In der einfachsten Implementierung von diesem Konzept sind die HDM berechtigt für das Übernehmen von allen Identitäten.

    Wenn dies nicht möglich ist, wäre z.B. folgende Erweiterung möglich:

    • Es gibt eine DB Tabelle freigegebene_identitäten.
    • Wenn ein Benutzer seine Identität freigeben möchte, wird sein Login in diese Tabelle eingetragen.
    • Wenn ein HDM eine fremde Identität übernehmen möchte, kann er aus allen Identitäten auswählen, welche in der Tabelle freigegebene_identitäten eingetragen sind.
    • Wenn ein Benutzer eine Aktivität auslöst, wird geprüft, ob er mit der gewählten Identität arbeiten darf (dies wäre z.B. dann der Fall, wenn es sich um seine eigene Identität handelt, oder er mit fremden Identitäten arbeiten darf und die Identität in der Tabelle eingetragen ist).
    • Wenn der HDM die Identität nicht mehr benötigt oder der richtige Benutzer die Freigabe entziehen will, wird die Identität wieder aus der Tabelle gelöscht.

    So ein Konzept ist aber relativ aufwändig und sollte (wie auch in den anderen Beiträgen erwähnt) nur dann implementiert werden, wenn eine Lösung mit z.B. Remote Desktop nicht möglich ist. Falls das Konzept implementiert wird wäre es auf jeden Fall wichtig, dass auch ein Audit-Log geführt wird (Wer hat seine Identität wann freigegeben, wer hat sie übernommen, was wurde mit der fremden Identität angestellt, ...)


    Freundliche Grüsse
    CptSocket
     
  16. JavaMeister
    JavaMeister Gesperrter Benutzer
    Du musst schon wissen, wie deine Anwendung funktioniert.
     
  17. rmacher
    rmacher Neues Mitglied
    Alles klar: Jetzt sehe ich, wie dies gemeint ist.

    Vielen Dank für diese ausführliche Erläuterung und Gruss,

    rmacher
     
  18. Schau dir jetzt hier den Kurs an und lerne Java zu programmieren: --> Hier klicken, um mehr zu erfahren (Klick)
Die Seite wird geladen...

Zugriff für Helpdesk-Mitarbeiter - Ähnliche Themen

einfaches Demo-Programm für Datenbankzugriff
einfaches Demo-Programm für Datenbankzugriff im Forum C/C++
Das richtige Format für den SOAP Zugriff
Das richtige Format für den SOAP Zugriff im Forum Java Basics - Anfänger-Themen
Applet : keine Recht für Zugriff auf Clipboard (trotz Zertifikat)
Applet : keine Recht für Zugriff auf Clipboard (trotz Zertifikat) im Forum Java Basics - Anfänger-Themen
suche Erstanschub für DB-Zugriff
suche Erstanschub für DB-Zugriff im Forum Datenbankprogrammierung
VPN-Verbindung für Datenbankzugriff
VPN-Verbindung für Datenbankzugriff im Forum Netzwerkprogrammierung
Thema: Zugriff für Helpdesk-Mitarbeiter