0

Ich versuche, eine Micro-Services-Umgebung zum Laufen zu bringen. Ich habe bereits den Config-Server, den Eureka-Server, den Zuul-Server und den Service eingerichtet. Um die Sicherheit zu gewährleisten, habe ich einen UAA-Server von Cloud Foundry installiert und läuft.Arbeiten Ldap-Gruppen als Scopes für Cloud-Foundry unter anderem authorisation_code-Grant-Typ?

Nach den Dokumenten zur Einrichtung des UAA-Servers gibt es die Option Ldap Groups as Scopes, die ich habe und ich kann sehen, wie sie in den UAA Server-Logs erstellt werden, aber sie nicht in das JWT-Token bekommen. Zuul kommuniziert korrekt mit dem UAA-Server, ich führe den Authentifizierungsprozess auf UAA durch und erhalte das JWT-Token auf Zuul, und dann fügt zuul Proxys dem dahinter liegenden Dienst hinzu, aber ohne die Gruppen/Bereiche des angemeldeten Benutzers nur den openid-Bereich auf der Client-Konfiguration. Fehle ich etwas? Oder so funktionieren die Dinge und ich muss eine Umgehung implementieren, die den Benutzernamen des Benutzers aus dem Token bezieht und seine Zugriffsrechte für jede Anfrage für jeden Dienst erhält?

Hier ist meine uaa.yml:

spring_profiles: ldap,mysql 

disableInternalUserManagement: true 

zones: 
    internal: 
    hostnames: 
     - sso.example.com 

oauth: 
    user: 
    authorities: 
     - openid 
     - scim.me 
     - password.write 
     - scim.userids 
     - uaa.user 
     - approvals.me 
     - oauth.approvals 
    clients: 
    sso: 
     secret: changeme! 
     authorized-grant-types: authorization_code, refresh_token 
     # How do I add the user groups as scopes? 
     # Is it possible with this grant type? 
     scope: openid 
     authorities: uaa.resource 

ldap: 
    profile: 
    file: ldap/ldap-search-and-bind.xml 
    base: 
    url: ldap://ldap.example.com:389 
    mailAttributeName: mail 
    mailSubstitute: '{0}@example.com' 
    mailSubstituteOverridesLdap: true 
    userDn: 'CN=Example User,OU=Admins,DC=example,DC=com' 
    password: 'changeme!' 
    searchBase: 'dc=example,dc=com' 
    searchFilter: 'sAMAccountName={0}' 
    groups: 
    file: ldap/ldap-groups-as-scopes.xml 
    searchBase: 'dc=example,dc=com' 
    groupRoleAttribute: cn 
    searchSubtree: true 
    groupSearchFilter: 'member={0}' 
    maxSearchDepth: 1 
    autoAdd: true 
    attributeMappings: 
    first_name: 'givenName' 
    last_name: 'sn' 

smtp: 
    host: mail.example.com 
    port: 25 

database: 
    url: jdbc:mysql://mysql.example.com/uaa 
    username: uaa 
    password: changeme! 

jwt: 
    token: 
    verification-key: | 
     -----BEGIN PUBLIC KEY----- 
     -----END PUBLIC KEY----- 
    signing-key: | 
     -----BEGIN RSA PRIVATE KEY----- 
     -----END RSA PRIVATE KEY----- 

login: 
    url: https://sso.example.com/uaa/login 
    branding: 
    companyName: 'Example Company' 

Antwort

0

Ihr Problem aus den Bereichen ergibt sich nicht auf dem Client konfiguriert werden. Nur Bereiche in der Bereichsliste dieses Clients können auf der Benutzer-JWT vorhanden sein. Das Hinzufügen von Bereichen zu dieser Liste ermöglicht es einem Benutzer nicht, Bereiche zu erhalten, die nicht vorhanden sind, noch führt dies dazu, dass diese Bereiche auf dem Clientanmeldeinformationen-Token für den Client vorhanden sind.

Wenn Sie Gruppen als Bereiche konfiguriert haben, muss Ihr Client jeden Bereich, den Sie erwarten, in der Liste der zulässigen Bereiche konfiguriert verwenden.