Die Konfiguration

Passwort-Komplexitätskriterien

Ab der Version 2.1.2.001 der DLE ist es möglich Passwort-Komplexitätskriterien für Passwörter die durch die DLE verwaltet werden, festzulegen.

Die Einstellungen können als Property am Security-Service in der DLESessionConfig.xml-Datei festgelegt werden.

Folgende Einstellungen sind möglich:

<Service name="SecurityService" class="at.visionflow.dle.engine.security.DLESecurityService">
			<Properties>
				<Property name="ByConflictForbidden" value="True" />
				<Property name="NotDefinedRightsAllowed" value="False" />
				<Property name="WithoutSecurity" value="False" />
				<Property name="PublishDLEEnvironment" value="True" />
				<Property name="PasswordMinLength" value="8" />
				<Property name="PasswordMinCapital" value="2"/>
				<Property name="PasswordMinNumber" value="2"/>
				<Property name="PasswordMinSymbol" value="2"/>
				<Property name="PasswordNoUsername" value="true" />
			</Properties>
		</Service>

LDAP Anbindung der DLE

Es besteht die Möglichkeit die DLE an ein LDAP-fähiges Verzeichnis für die Benutzerauthentifizierung zu verbinden.
Hierzu muss folgende Property am SecurityService gesetzt werden:

<Property name="UseLdapService" value="ldapService@vision-flow.at" />

Es können in dieser Property auch mehere LdapServices angegeben werden. Diese müssen mit Strichpunkt(;) getrennt werden. Der Nutzer kann sich dann unter Angabe des Domain-Postfix an einer anderen Dömane authentifizieren. Z.b. thgr@xpert-log.at Zusätzlich kann dann auch folgende Properties gesetzt werden:

<Property name="DefaultLdapDomain" value="vision-flow.at" />
<Property name="LdapFallbackToDleUser" value="True" />

DefaultLdapDomain: Legt fest mit welchen LDAP-Service authentifiziert wird, falls keine Domain-Suffix im Benutzernamen angegeben wird.

LdapFallbackToDleUser: Falls auf true wird die Standard-DLE-Authentifzierung angewandt, falls die LDAP Authentifizierung fehl schlägt.

Es muss hierzu auch ein LdapService definiert werden.

<Service name="LdapService@vision-flow.at" class="at.visionflow.dle.engine.security.DLELDAPService">
          <Properties>
            <Property name="Url" value="ldap://vfdc01.vision-flow.at:389"/>
            <Property name="UserDN" value="OU=users,OU=VF,DC=vision-flow,DC=at"/>
            <Property name="Query" value="(objectClass=Person)"/>
            <Property name="Authentication" value="simple" />
            <Property name="Referral" value="follow" />
            <Property name="DomainPostfix" value="@vision-flow.at" />
            <Property name="Sync_CreateMissingDLEUsers" value="add" />
            <Property name="Sync_FirstnameAttribute" value="givenName" />
            <Property name="Sync_LastnameAttribute" value="sn" />
            <Property name="Sync_EmailAttribute" value="mail" />
            <Property name="Sync_DefaultUserGroupIdc" value="TEST:1" />
            <Property name="UsernameAttribute" value="userPrincipalName" />
            <Property name="Sync_AutoAssignUserGroups" value="synchronize" />
            <Property name="Sync_AutoAssignOrgUnits" value="add" />
         </Properties>
</Service>

Das LdapService verbindet sich zum Verzeichnisserver und ermittelt im angegebenen UserDN ob es einen Eintrag gibt, der ein Attribut "userPrincipalName" bestehend aus angegebenem Username sowie dem "DomainPostfix" besitzt.

Erklärung der Properties des Service:

Url: Der LDAP Url zum Server. Empfohlen wird, auf den Server mittels SSL (ldaps://) zuzugreifen.

UserDN: Der Distinguished Name (DN) des Verzeichnisses in dem die Benutzer vorliegen. Es werden auch Unterverzeichnisse durchsucht.

Query: (optional) Zusätzliche Einschränkung zur Suche des Users

Authentication: (optional) Authentifizierungsmechanismus entsprechend der Ldap Implementierung. Mögliche Werte: none, simple, strong. Standardwert: simple

Referral: (optional) Soll Verweisen gefolgt werden? Mögliche Werte sind follow, ignore, throw.

DomainPostfix: Der domänenspezifische Teil des Usernamens im LDAP Verzeichnis

Sync_CreateMissingDLEUsers: (optional) True(=add) oder False. Bestimmt, ob Benutzer, die im LDAP-Verzeichnis vorhanden sind, aber nicht an der DLE, angelegt werden sollen.

Sync_FirstnameAttribute: (optional) Attribut am LDAP-Objekt, das bei der DLE-Benutzer-Anlage als Vorname gesetzt wird

Sync_LastnameAttribute: (optional) Attribut am LDAP-Objekt, das bei der DLE-Benutzer-Anlage als Nachname gesetzt wird

Sync_EmailAttribute: (optional) Attribut am LDAP-Objekt, das bei der DLE-Benutzer-Anlage als E-Mail-Adresse gesetzt wird

Sync_DefaultUserGroupIdc: (optional) Standard Benutzergruppe, die bei der automatisierten Benutzeranlage dem Benutzer zugewiesen wird. Inkl. des Mandanten-Postfix, üblicherweise :1

UsernameAttribute: (optional) Das Attribut im LDAP Verzeichnis, gegen das der Benutzername geprüft wird. Standard ist userPrincipalName. Alternativ oft üblich sAMAaccountName.

Sync_AutoAssignUserGroups: (optional) add oder synchronize. Aktiviert den Abgleich der LDAP Benutzergruppen mit der DLE. Ist nur add gewählt, dann werden evtl. vorhandene Gruppen hinzugefügt, aber keine wieder entfernt. Ist synchronize aktiv, dann werden alle im LDAP nicht vorhandenen Gruppen auch in der DLE dem Benutzer entzogen. Der Name der Gruppe muss dem Namen im LDAP entsprechen. Die Ermittlung im LDAP erfolgt über das memberOf Attribut.

Sync_AutoAssignOrgUnits: (optional) add oder synchronize. Aktiviert den Abgleich der LDAP Benutzergruppen mit der Org.-Einheiten DLE. Ist nur add gewählt, dann werden evtl. vorhandene Gruppen hinzugefügt, aber keine wieder entfernt. Ist synchronize aktiv, dann werden alle im LDAP nicht vorhandenen Gruppen auch in der DLE dem Benutzer entzogen. Der Name der Org.-Einheit muss dem Namen im LDAP entsprechen. Die Ermittlung im LDAP erfolgt über das memberOf Attribut.

UseManagedReferralControl: (optional) Kann auf true gesetzt werden. Aktiviert bei LDAPv3 Servern die Auflösung von Referrals durch den Server. Wird von Windows Active Directory nicht unterstützt.

AllowAllServerCertificates: (optional, ab Version 2.1.0.003) Kann auf true gesetzt werden. Es wird bei der Verwendung von SSL-LDAP-Verbindungen die Zertifikatskette nicht geprüft. Somit können auch selbst-signierte Zertifikate vom LDAP-Server genutzt werden, ohne dass diese im TrustStore gepflegt werden müssen.

Anmerkung: Die Verbindung zum LDAP-Server funktioniert nicht, wenn ausschließlich eine GSS-API Authentifizierung möglich ist. SSL/TLS Verbindungen sind möglich.

Der Standardport für LDAP Anfragen ist 389.
Der Standardport für LDAPS Anfragen ist 636.
Bei großen Domain Forests empfiehlt es sich u.U. den Port 3268 (LDAP) bzw. 3269 (LDAPS) im Windows Active Directory Umgebungen zu verwenden, um Probleme mit Referrals zu vermeiden.

Authentication Service

Es besteht die Möglichkeit, ein so genanntes AuthService im Securityservice anzugeben. Dies ermöglicht dann, die Benutzerauthentifizierung über dieses AuthService abzuwickeln sowie Passwortänderungen ebenfalls an dieses Service umzuleiten.

Die Aktivierung eines solchen Service erfolgt über die Service-Property UseAuthService.

<Property name="UseAuthService" value="logOAuthService" />
<Property name="AuthFallbackToDleUser" value="true" />

Der Wert in Value der Property UseAuthService gibt den Namen des in der SessionConfig zu konfigurierenden Services an.

Falls die Property namens AuthFallbackToDleUser auf true gestellt ist, dann wird nach einem erfolglosen Anmeldeversuch am AuthService, die Anmeldung an die DLE-Datenbank weitergeleitet und dort versucht.

Log-O Authentication Service

Da DLE-Installationen oft im Zusammenspiel mit Log-O Software eingesetzt werden, gibt es die Möglichkeit ein Log-O Authentication Service einzubinden. Dies erfolgt mittels Definition in der DLESessionConfig.xml-Datei. Das Service muss, wie weiter oben beschrieben, im SecurityService angeführt werden.

Sinn dieses Log-O Authentication Services ist, die Anmeldung an der DLE über die susr_user Tabelle in der Log-O Datenbank abzuwickeln. Es müssen die Benutzer aber trotzdem im DLE-System angelegt sein. Es besteht hier auch die Möglichkeit die Synchronisation zwischen den beiden DLE-Tabellen über einen DLE-Brick abzuwickeln, der in Log-O beim Speichern des Benutzers aufgerufen wird.

Wird in einem DLE-System das Passwort eines Log-O Benutzers zurückgesetzt, so wird dieses in der Log-O Datenbank geändert, d.h. die Passwortänderung hat Auswirkung auf beide Software-Systeme.

Folgend die Standardkonfiguration des Log-O Authentication Services.

<Service name="logOAuthService" class="at.visionflow.dle.engine.security.DLELogOAuthService">
	<Properties>
		<Property name="DatabaseConnector" value="defaultConnector" />				
	</Properties>
</Service>

Die Property DatabaseConnector definiert, über welchen Datenbankkonnektor die susr_user Tabelle gesucht wird.

Bricks in der IDE

Folgende Bricks werden benötigt: User nach dem Speichern und User Speichern

In Log-O

In Log-o unter Konfigurationen > DLE > KUNDENAUSGAENGE bei DLE-AUSGANG-USERSPEICHERN und DLE-AUSGANG-USER-NACH-SPEICHERN muss bei KON(Konzern) der Schalter auf "Ein" gesetzt werden

Open ID Connect (OIDC)

Ab DLE Version 2.2.1 kann die Anmeldung an das DLE-IDE mittels Open Id Connect (OIDC) Single-Sign-On erfolgen.

Es muss dafür für jeden OIDC-Anbieter ein OIDC-Service in der DLESessionConfig.xml angelegt werden.

<Service name="OIDCVisionFlowAzure" class="at.visionflow.dle.engine.security.DLEOpenIdConnectService">
    <Properties>
        <Property name="ClientId" value="a2fac99a-8e12-4c8b-81c8-a59aa31ef67e" />
        <Property name="EncryptedClientSecret" value="@D1@./ouaW6f9yenVZgD8S9Z/OEvIb5lhcSvNuW6kfMuD1R3plFDQoVDc+pgoyWRbAh+rjBYO04Atokg=.08KdIyoC2d9JTb+cwyAdTg==" />
        <Property name="OidcProviderUrl" value="https://login.microsoftonline.com/2f782989-5c96-45b9-a5b2-7a7bd1bb671b/v2.0/.well-known/openid-configuration" />
        <Property name="DisplayName" value="Vision-Flow Azure" />
        <Property name="AddMissingUsers" value="true" />
        <Property name="ClaimsToRequest" value="AssignedRoles, given_name" />
    </Properties>
</Service>

Aktuell werden nur Client/Secret OIDC-Services unterstützt. Eine Zertifikatsauthentifizierung ist noch nicht möglich.
Weiters muss am OIDC Server der "Implicit Flow" für den DLE-Client aktiviert werden.

Dieses Service muss dann im SecurityService referenziert werden. Dafür muss eine Property namens UseOidcService verwendet werden, die als Wert den OIDC-Service-Namen enthält

<Property name="UseOidcService" value="OIDCVisionFlowAzure"/>

Mehrere OIDC-Services können mit Semikolon getrennt angegeben werden.

Bei jeder OIDC-Anmeldung wird der Brickordner OIDCLogin im DLE-Basis-Paket aufgerufen. Wird kein Brick in diesem Ordner zur Ausführung gefunden, dann wird die Anmeldung durchgeführt. Wird ein passender Brick gefunden, dann kann dieser dazu verwendet werden, Rechte oder ähnliches dem Benutzer zuzuweisen. Als Datenübergabe ist hierfür das Datenobjekt DLE:OidcLogin eingeführt worden. Damit können auch Informationen aus dem ID-Token oder bei einer Neuanlage des Benutzers aus der UserInfo des OIDC-Providers zu diesem Benutzer verarbeitet werden.

Folgender Brickordner wird bei der Anmeldung aufgerufen: Paket: DLE Basis (DLE), Ordner: OIDCLogin
Brickschlüsselattribut: DLE:OidcLogin.OIDCServiceName Attributwert: Name des Oidc-Services
Als Benutzername für die Brickausführung wird die Emailadresse des Benutzers verwendet.

Felder des OIDCLogin-Datenobjekts:

ACHTUNG: Tritt im Brickaufruf ein Fehler auf, so wird zwar die Anmeldung dem Benutzer verwehrt, allerdings wurde der Benutzer bereits im System angelegt