Mit Okta meldet sich dein Team über den gewohnten Firmen-Login bei 1-CP an. Die Anbindung läuft über OpenID Connect und lässt sich in zwei Stufen betreiben: nur Authentifizierung oder Authentifizierung plus Profildaten. Die Grundeinrichtung ist in beiden Fällen identisch.
Die Verantwortung ist geteilt. 1-CP liefert die Integrationsdaten, dein Okta-Administrator legt die App-Integration an und bleibt deren Eigentümer.
Sign-in Redirect URI: Du bekommst sie von uns, je Umgebung eine eigene (Produktion und Staging). Trage sie exakt so ein, wie wir sie schicken. Redirect URIs sind case-sensitive, und Nutzer sehen eine Fehlermeldung, wenn die aufgerufene URI nicht registriert ist.
App-Typ: OIDC - OpenID Connect, Application type Web Application
Grant type: Authorization Code. Bei Web-Apps ist das in Okta fest gesetzt.
Scopes: openid, profile, email
Gehe in der Admin Console zu Applications and Resources, dann Applications, und klicke auf Create App Integration.
Wähle als Sign-in method OIDC - OpenID Connect und als Application type Web Application.
Vergib einen App integration name, zum Beispiel 1-CP SSO.
Trage unter Sign-in redirect URIs die URI ein, die du von 1-CP erhalten hast.
Lege unter Assignments fest, wer Zugriff auf die App bekommt.
Öffne nach dem Speichern den Reiter General. Unter Client Credentials findest du die Client ID. Wähle als Client authentication die Option Client secret und erzeuge das Secret.
Dein Team meldet sich per SSO an, 1-CP synchronisiert keine Profildaten. Dafür genügen die OIDC-Standardscopes openid, profile und email.
Wichtig: 1-CP identifiziert Nutzer über die E-Mail-Adresse. Stelle sicher, dass die betroffenen Konten in Okta eine gepflegte E-Mail-Adresse haben.
Zusätzlich zum Login übernimmt 1-CP Stammdaten aus deinem Okta-Verzeichnis in das Nutzerprofil. Das spart die manuelle Pflege in 1-CP und hält Namen und Kontaktdaten aktuell.
Voraussetzung: Die Attribute, die übernommen werden sollen, müssen im Okta-Nutzerprofil gepflegt sein, insbesondere Vorname, Nachname und E-Mail-Adresse. Fehlt ein Attribut, bleibt das entsprechende Feld im 1-CP-Profil leer.
Je nach gewünschtem Umfang kann ein zusätzlicher Scope oder ein angepasster Claim in Okta nötig sein. Welche Felder in deinem Setup übernommen werden und was dafür konfiguriert werden muss, stimmen wir im Onboarding gemeinsam ab. Melde dich dazu über das Hilfe-Widget, wir legen ein Ticket an und klären es mit dir.
clientId – die Client ID aus dem Reiter General deiner App-Integration
clientSecret – das erzeugte Client Secret
domain – die Domain eures Okta-Tenants, zum Beispiel example.okta.com. Wenn ihr eine Custom URL Domain nutzt, gib die Domain an, die im Issuer der App steht.
authorizationServerId – die ID des Authorization Servers, den 1-CP ansprechen soll (siehe nächster Abschnitt)
Das Client Secret ist ein vertrauliches Zugangsdatum. Bitte übermittle es nicht per E-Mail, sondern über einen vorher vereinbarten sicheren Kanal.
Okta kennt zwei Typen. Der Org Authorization Server ist in jeder Okta-Org vorhanden und laut Okta für reines SSO ausreichend. Custom Authorization Server erlauben eigene Scopes, Claims und Access Policies.
Ein Custom Authorization Server mit der ID default ist vorkonfiguriert, wenn eure Org das Okta-Produkt API Access Management nutzt. In Produktionsumgebungen ist das ein kostenpflichtiges Add-on, es ist also nicht in jeder Org vorhanden. Welche Server bei euch existieren, siehst du in der Admin Console unter Security, API.
In den meisten Fällen ist default die richtige Angabe. Nutzt ihr einen eigenen Server, gib dessen ID im Format aus... an. Wenn du unsicher bist, welcher Server bei euch passt, melde dich über das Hilfe-Widget. Wir legen ein Ticket an und prüfen das gemeinsam, bevor du etwas umstellst.
Produktion und Staging trennen. Lege je Umgebung eine eigene App-Integration mit eigenem Secret an. So kompromittiert ein Staging-Secret nie die Produktion und beide Umgebungen lassen sich unabhängig abschalten.
Zugriff über Gruppen steuern. Weise die App gezielt den Gruppen zu, die 1-CP nutzen sollen, statt allen Nutzern der Org.
Rotation ohne Ausfall planen. Okta unterstützt ein zweites Client Secret. Damit kannst du rotieren, ohne dass der Login zwischendurch bricht.
Keine Wildcards in Redirect URIs. Okta rät davon ab, weil Tokens dadurch an unerwartete Seiten gehen können. Unsere URIs sind absolut, Wildcards sind nicht nötig.
Mit Stufe 1 starten. Erst den Login sauber testen, danach bei Bedarf auf Profildaten erweitern. Das grenzt Fehlerquellen ein.
Kommst du an einer Stelle nicht weiter oder hast du eine Anforderung, die hier nicht beschrieben ist? Melde dich über das Hilfe-Widget, wir legen ein Ticket an und begleiten die Einrichtung.
