2017-06-19 6 views
0

Ich benutze eine OpenIDIdentityProvider mit mappingMethod: claim, um Admin-Benutzer in der Openshift Admin-Konsole zu authentifizieren. Ich verwende den auth0-Dienst, um Benutzer zu authentifizieren. Die Admin-Benutzer werden bei der Bereitstellung in einem geeigneten Playbook definiert, wodurch die Admin-Benutzer effektiv codiert werden.OpenShift Open Identity Provider mit Lookup-Mapping-Methode

Ist es möglich, alle Server-Betreiber und Entwickler Benutzer mit den OpenIDIdentityProvider, ein lookup Mapping-Verfahren und das Hinzufügen von etwas wie extraScopes: [roles] vollständig zu verwalten durch die zusätzliche Berechtigungsrollen in die Authentifizierungsanforderung zu ziehen? Das würde es mir ermöglichen, Benutzer und Rollen getrennt von dem ansprechbaren Playbook zu verwalten. Bonuspunkte der nächsten Stufe für die Verwaltung von Berechtigungen auf der Seite des Authentifizierungsanbieters.

Die Openshift-Dokumentation enthält sehr wenig Details zur Authentifizierung/Autorisierung außerhalb der Standardeinstellungen mappingMethod: claim. die unten würde ausreichen, um für eine funktionierende Lookup-basierte Mapping-Verfahren mit Rollen von der Authentifizierungs-Provider zurück

{ 
    "items": [ 
    { 
     "name": "auth0", 
     "challenge": false, 
     "login": true, 
     "mappingMethod": "claim", 
     "kind": "OpenIDIdentityProvider", 
     "clientID": "supersecretsauce", 
     "clientSecret": "extrasupersecretsauce", 
     "extraScopes": ["email", "profile"], 
     "claims": { 
     "id": [ 
      "email" 
     ], 
     "preferredUsername": [ 
      "email" 
     ], 
     "name": [ 
      "name" 
     ], 
     "email": [ 
      "email" 
     ] 
     }, 
     "urls": { 
     "authorize": "https://fancypants.auth0.com/authorize", 
     "token": "https://fancypants.auth0.com/oauth/token", 
     "userInfo": "https://fancypants.auth0.com/userinfo" 
     } 
    } 
    ] 
} 

Zu meiner einfachen Sinn:

Unten ist mein Identitätsanbieter JSON-Datei für den Anspruch basierte Mapping-Methode:

{ 
    "items": [ 
    { 
     "name": "auth0", 
     "challenge": false, 
     "login": true, 
     "mappingMethod": "lookup", 
     "kind": "OpenIDIdentityProvider", 
     "clientID": "supersecretsauce", 
     "clientSecret": "extrasupersecretsauce", 
     "extraScopes": ["email", "profile", "roles"], 
     "claims": { 
     "id": [ 
      "email" 
     ], 
     "preferredUsername": [ 
      "email" 
     ], 
     "name": [ 
      "name" 
     ], 
     "email": [ 
      "email" 
     ], 
     "role": [ 
      "roles" 
     ] 
     }, 
     "urls": { 
     "authorize": "https://fancypants.auth0.com/authorize", 
     "token": "https://fancypants.auth0.com/oauth/token", 
     "userInfo": "https://fancypants.auth0.com/userinfo" 
     } 
    } 
    ] 
} 

ein Beispiel für eine funktionelle Rolle Wert würde cluster-admin sein.

Antwort

1

OpenID kann nur zur Authentifizierung verwendet werden. Sie versuchen, es sowohl für die Authentifizierung als auch für die Autorisierung zu verwenden. Dies ist nicht möglich, da Rollen und Bindungen von Openshift verwaltet werden - sie können nicht an einen externen Dienst delegiert werden.

+0

Vielen Dank für das Feedback, ich sammelte so viel, wenn ich über diese Feature-Anfrage https://trello.com/c/8olzeZH3 – Brown1

+0

@ Brown1 stolperte diese Karte immer noch nur mit Authentifizierung (Gruppenmitgliedschaft) beschäftigt. Sie müssten weiterhin Rollen an die Gruppen in OpenShift binden. – enj

+0

so OpenShift, wie es steht, hat keine Möglichkeit, Rollen im Authentifizierungstoken zurückgegeben akzeptieren? Wenn das Token beispielsweise Rollen und Gruppen enthält, die so benannt wurden, dass sie den Rollen und Gruppen in "openshift" entsprechen, würde openshift diese Rollen und Gruppen nicht akzeptieren. Da dies die Absicht war, verwenden Sie Rollen und Gruppen, die bereits in openshift definiert sind, fügen Sie sie den Benutzern auf der Seite des Authentifizierungsgateways hinzu und geben diese Rollen und Gruppen mit dem Token zurück. – Brown1

Verwandte Themen