Legitimation Portal-Kundenkonto

Es ist möglich, im Kundenportal bestimmte Informationsbereiche, Vertragsdaten und Aktionen nur vollständig legitimierten Portalbenutzern anzubieten, um so vor einem Missbrauch zu schützen.

Voraussetzungen und Konfiguration

Für TINA müssen die Servicearten der Anlagen, deren zugehörige Vertragskonten legitimiert werden können, in der Skriptbibliotheksmethode SC12ITCUtils.getServiceTypeListForLegitimationContrAccTINA() hinterlegt werden.

Legitimation prüfen

Bei der Anmeldung des Portal-Benutzers wird im Service ag.itc.getCustomer geprüft, ob der zugehörige Portal-Login-Datensatz den Account Status (AccountStatus.C12PORTALLOG) LEGITIMIERT besitzt.

Ist dies der Fall, werden die Vertragsdaten zurückgeliefert. Ist dies nicht der Fall, werden die Vertragsdaten nicht geliefert. Die Ansicht entspricht hier dem Zustand vor der Legitimation.

Legitimationsprozess starten

Der Portal-Benutzer startet im eingeloggten Bereich des Portals die Legitimation. Dabei muss er folgende Angaben machen, die an TINA übermittelt werden

Vertragskontonummer Einspeiseanlage (Vertragskonto zu einer Einspeiseanlage) (ODER Zählernummer (Zähler zu Bezugsanlage))

UND Vorname

UND Nachname

weiterhin wird beim Start der Legitimation der Login-Name vom Portal an TINA übermittelt.

In TINA wird anhand der Vertragskontonummer geprüft, ob es sich bei der zugehörigen Anlage (Installation) um eine Einspeiseanlage handelt (Relationen: Vertragskonto - Anlagenkonto - Anlage).

Wurde statt der Vertragskontonummer eine Zählernummer übergeben, wird für diese geprüft, ob es sich um eine Bestandsanlage handelt (Relationen: Messeinrichtung – Anlage (MeLo) – per Anlagenverknüpfung Anlage (MaLo) - Anlagenkonto - Vertragskonto).

In beiden Fällen wird das zugehörige Vertragskonto (ContractAccount) und der darin enthaltene Geschäftspartner ermittelt.

Fehlermeldungen und mögliche Ursachen

Wurde in TINA kein passendes Vertragskonto bzw. bei übergebener Zählernummer keine passende Messeinrichtung (MeasuringDevice) inklusive zugehörigem Vertragskonto ermittelt, wird ein entsprechender Fehler von TINA an das Portal zurückgegeben.

Eingabeparameter Portal	Vorhandene Daten in TINA	Fehlermeldung TINA an Portal
Vertragskontonummer (contractAccountNo)	Vertragskonto zur Vertragskontonummer, inkl. Anlagenkonto mit SEIN-Anlage	Keine, Legitimation ist möglich
Vertragskontonummer (contractAccountNo)	Vertragskonto zur Vertragskontonummer, inkl. Anlagenkonto aber keine SEIN-Anlage (ISU_AnlArt.Installation ist nicht in getServiceTypeListForLegitimationContrAcc() hinterlegt)	Anlage hat nicht die passende Anlagenart
Vertragskontonummer (contractAccountNo)	In TINA wurde kein Vertragskonto mit der übergebenen Vertragskontonummer gefunden	Datensatz ContractAccount nicht gefunden
Zählernummer (meterNo)	Zähler (Messeinrichtung) kann anhand der übergebenen Zählernummer gefunden werden, für diesen existiert jedoch (noch) kein Vertragskonto	Datensatz ContractAccount für Zählernummer nicht gefunden
Zählernummer (meterNo)	Zähler (Messeinrichtung) kann anhand der übergebenen Zählernummer in TINA nicht gefunden werden	Datensatz MeasuringDevice nicht gefunden
Zählernummer (meterNo)	Zähler (Messeinrichtung) kann anhand der übergebenen Zählernummer gefunden werden, für diesen existiert zudem ein Vertragskonto	Keine, Legitimation ist möglich

In TINA wird geprüft, ob der aus dem Portal übermittelte Vorname und Nachname mit dem Vor- und Nachnamen des im Vertragskonto hinterlegten Geschäftspartners (CustomerPk.ContractAccount) übereinstimmt.

Ist dies nicht der Fall, wird von TINA eine Fehlermeldung an das Portal geliefert.

Dort wird dem Portal-Anwender nicht im Detail ausgegeben, welcher der Parameter nicht passt, sondern lediglich, dass mindestens EIN Parameter nicht passt.

Stimmen Vor- und Nachname überein, wird geprüft, ob an dem Geschäftspartner aus dem Vertragskonto bereits ein Portal-Login-Datensatz (C12PORTALLOG) existiert.
Des Weiteren wird anhand des übermittelten Login-Namens geprüft, ob bereits ein Login-Datensatz existiert.

Geschäftspartner Portal-Login und Vertragskonto identisch

Sind der Geschäftspartner aus dem Portal-Login und dem Vertragskonto identisch, wird der Legitimationscode erzeugt und am Portal-Login-Datensatz (LegitimateCode.C12POTRALLOG) gespeichert.

Die Anzahl der verbleibenden Versuche auf dem Portal-Login wird auf den Standardwert gesetzt. Das Gültigkeitsdatum des Codes wird auf den Standardwert gesetzt.

Geschäftspartner Portal-Login und Vertragskonto weichen ab

Stimmen der Geschäftspartner aus dem Vertragskonto und dem Portal-Login nicht überein, wird ein neuer Portal-Login-Datensatz erzeugt.

In diesem wird der übergebene Login-Name hinterlegt und der Geschäftspartner (und dessen Standard-Ansprechpartner) aus dem Vertragskonto auf dem Portal-Login-Datensatz hinterlegt.

Der Legitimationscode wird erzeugt und an diesem Login-Datensatz gespeichert. Die Anzahl der Versuche auf dem Portal-Login wird auf den Standardwert gesetzt. Das Gültigkeitsdatum des Codes wird auf den Standardwert gesetzt.

Portal-Login ohne Geschäftspartner

Wird bei der Prüfung festgestellt, dass für den Login-Namen, unter dem die Legitimation ausgelöst wird, zwar einen Login-Datensatz gibt, dieser aber keinen Geschäftspartner enthält, wird in den gefundenen Login-Datensatz der Geschäftspartner (und dessen Standard-Ansprechpartner) aus dem Vertragskonto übernommen.

Der Legitimationscode wird erzeugt und an diesem Login-Datensatz gespeichert. Die Anzahl der Versuche auf dem Portal-Login wird auf den Standardwert gesetzt. Das Gültigkeitsdatum des Codes wird auf den Standardwert gesetzt.

Abweichender Login für Geschäftspartner vorhanden

Wird bei der Prüfung festgestellt, dass für den Geschäftspartner aus dem Vertragskonto bereits ein weiterer Portal-Login mit abweichendem Login-Namen existiert, als derjenige, unter dem er versucht, die Legitimation auszuführen, wird ein Fehler aus TINA an das Portal übermittelt.

Es ist keine Registrierung desselben Geschäftspartners mit unterschiedlichen Portal-Logins möglich. Es können jedoch für denselben Login-Namen mehrere Portal-Login-Datensätze mit unterschiedlichen Geschäftspartnern erzeugt werden. Die Verknüpfung eines weiteren Kunden zu einem Portal-Account wird über die Legitimation abgebildet. Dort wird entweder ein vorhandener Portal-Login angereichert oder einen neuer Datensatz erzeugt. Das Portal ruft vor jedem Login den Service registrationState auf und verknüpft ggfs. neue Kunden mit dem bestehenden Account, sofern ein neuer Portal-Login geliefert wird. Technisch gesehen werden hier jedoch immer neue Portal-Login-Datensätze mit demselben Login-Namen aber abweichenden Geschäftspartnern erzeugt.

Laufende Legitimation abbrechen

Eine gestartete Legitimation kann in TINA durch berechtigte Anwenderinnen und Anwender abgebrochen werden. Die Aktion steht in der Aktionsbox eines Portal-Logins zur Verfügung. Sie ist aktiv, wenn der Account Status nicht LEGITIMIERT ist und das Gültigkeitsdatum nicht leer ist.

Vor Abbruch des Legitimationsprozesses erfolgt eine Sicherheitsabfrage. Wird diese bejaht, werden die für die Legitimation relevanten Felder (Legitimationscode, Gültigkeitsdatum, Anzahl verbleibender Versuche) werden geleert. Die Legitimation kann bei Bedarf vom Kunden im Portal neu angestoßen werden.

Das Kundenportal erkennt anhand der im Objekt customerProfile übergebenen Informationen (codeValidUntil, codeRetryCount), ob ein Legitimationsprozess aktiv ist oder nicht.

Der Kunde kann eine laufende Legitimation nicht selbstständig über das Kundenportal abbrechen. Er kann sich entweder an den Kundenservice wenden, der die oben beschriebene Aktion in TINA ausführt oder warten, bis das Gültigkeitsdatum abgelaufen ist.

Legitimierung abschließen

Der Portal-Benutzer muss den Legitimationscode, den er per Post erhalten hat, im Portal eingeben. Zusätzlich ist eine Vertragskontonummer (oder Zählernummer) anzugeben, für die der Geschäftspartner im Vertragskonto (CustomerPk.ContractAccount) hinterlegt ist. Es kann sich dabei um eine beliebige Vertragskontonummer handeln, ausschlaggebend ist, dass ein Vertragskonto mit der eingegebenen Vertragskontonummer über das Feld CustomerPk.ContractAccount mit dem Geschäftspartner aus dem Portal-Login-Datensatz vorhanden ist.

Der eingegebene Code wird gegen den im zum Login-Namen zugehörigen Portal-Login-Datensatz geprüft.

Legitimierung ist erfolgreich

Ist der eingegebene Code gültig und stimmt zudem mit dem Legitimationscode auf dem Portal-Login-Datensatz überein, wird der Account Status (AccountStatus.C12PORTALLOG) des Portal-Login-Datensatzes auf LEGITIMIERT gesetzt. Die Legitimation ist damit erfolgreich abgeschlossen.

Legitimierung schlägt fehl

Ist der Code ungültig, wird die Legitimation durch das Portal abgelehnt.

Stimmt der eingegebene Code nicht mit dem Legitimationscode auf dem Portal-Login überein, wird dem Portal-Benutzer eine Fehlermeldung angezeigt. Auf dem Portal-Login-Datensatz wird die Anzahl der Versuche um 1 reduziert. Erreicht die Anzahl der verbleibenden Versuche 0, wird der Code ungültig.

Wird ein Legitimationscode aufgrund der Anzahl der Falscheingaben ungültig, wird in TINA eine Protokollaktivität erzeugt und mit dem Geschäftspartner (CustomerPk.ContractAccount) aus dem Vertragskonto, für das die Legitimation gestartet wurde, verknüpft. Das Ablaufen des Gültigkeitszeitraums erzeugt keine Protokollaktivität.

Betreff	Legitimation für Kundenportal ist fehlgeschlagen Sprachvariable: <tbd>
Text	Die Legitimation für das Kundenportal für das Vertragskonto <Vertragskontonummer> ist fehlgeschlagen. Ursache: Der Legitimationscode wurde <x> mal falsch eingegeben. Sprachvariable: <tbd>
Art	PROTOKOLL
Beginn/Ende	NOW
Status	E
Priorität	B
Delegiert von/an	<PORTAL-Benutzer> Aktueller Benutzer, der den Service ausführt

Mit erneutem Initiieren der Legitimation wird ein neuer Legitimationscode generiert und auf den Portal-Login geschrieben. Das Gültigkeitsdatum sowie die Anzahl der verbleibenden Versuche werden anhand der Standardwerte erneut gesetzt.

Konfigurations- und Übersteuerungsmöglichkeiten

Die folgenden Methoden der Skriptklasse SC12ITCUtils bieten Möglichkeiten zur Anpassung der Logiken

`getServiceTypeListForLegitimationContrAccTINA`	Die Servicearten der Anlagen, deren zugehörige Vertragskonten legitimiert werden können, sind hier konfigurierbar. Beispiel `@BpmScript @Released @Override` `private` `List getServiceTypeListForLegitimationContrAccTINA()` `{List<ILookup> tinaList = new` `ArrayList();` `tinaList.add(LookupUtils.toLookup("pj58lh1i4j77dvtS_Keytab"));` `return` `tinaList;}`
`getLegitimationRetryCount`	Der Wert für die Anzahl der Eingabeversuche kann hier angepasst werden. Der Standardwert beträgt 3.
`getLegitimationValidyDuration`	Der Wert für das Gültigkeitsdatum eines Legitimationscodes kann hier angepasst werden. Im Standard wird das aktuelle Datum + 28 Tage verwendet.
`generateLegitimationCode`	Die Regeln für die Generierung des Legitimationscodes können hier angepasst werden. Beispielsweise kann die Anzahl der Zeichen sowie per allowedCharacters die erlaubten Zeichen verändert werden. Der Standardwert verwendet A-Z, a-z, 0-9 und nutzt 8 Stellen.