2017-06-19 5 views
0

J'utilise un OpenIDIdentityProvider avec mappingMethod: claim pour authentifier les utilisateurs admin dans la console d'administration Openshift. J'utilise le service auth0 pour authentifier les utilisateurs. Les utilisateurs admin sont définis dans un playbook ansible sur le déploiement, ce qui rend les utilisateurs admin codés en dur.Openshift Open Identité Fournisseur d'identité avec méthode de mappage de recherche

Est-il possible de gérer complètement tous les utilisateurs admin et développeurs utilisant le OpenIDIdentityProvider, une méthode de cartographie lookup et en ajoutant quelque chose comme extraScopes: [roles] à tirer à travers les rôles d'autorisation supplémentaires dans la demande d'authentification? Cela me permettrait de gérer complètement les utilisateurs et les rôles séparément du playbook ansible. Points de bonus de niveau suivant pour la gestion des autorisations du côté du fournisseur d'authentification.

La documentation de Openshift est très légère sur les détails de l'authentification/autorisation en dehors de la valeur par défaut mappingMethod: claim.

Ci-dessous est mon fichier fournisseur de JSON d'identité pour la méthode de cartographie basé sur le fondement:

{ 
    "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" 
     } 
    } 
    ] 
} 

A mon avis, simple, le ci-dessous suffirait pour une méthode de cartographie recherche-travail avec des rôles renvoyés par le fournisseur d'authentification:

{ 
    "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" 
     } 
    } 
    ] 
} 

un exemple d'une valeur de rôle fonctionnel serait cluster-admin. OpenID ne peut être utilisé que pour l'authentification.

Répondre

1

Vous essayez de l'utiliser à la fois pour l'authentification et l'autorisation. Cela n'est pas possible car les rôles et les liaisons sont gérés par Openshift - ils ne peuvent pas être délégués à un service externe.

+0

Merci pour les commentaires, j'ai rassemblé autant quand j'ai trébuché sur cette demande de fonctionnalité https://trello.com/c/8olzeZH3 – Brown1

+0

@ Brown1 cette carte ne traite toujours que l'authentification (appartenance à un groupe). Vous devez toujours associer des rôles aux groupes dans Openshift. – enj

+0

Ainsi, openshift, tel qu'il est, n'a aucun moyen d'accepter les rôles retournés dans le jeton d'authentification? Par exemple, si le jeton inclut des rôles et des groupes nommés pour correspondre aux rôles et groupes dans openshift, openshift n'acceptera pas ces rôles et groupes. Parce que c'était l'intention, utilisez les rôles et les groupes déjà définis dans openshift, ajoutez-les aux utilisateurs du côté de la passerelle d'authentification et renvoyez ces rôles et groupes avec le jeton. – Brown1