Score:0

How to get Gravitee to do recursive group lookups

ru flag

I have set up Gravitee APIM 3x (gateway, rest-api, console and portal). This work fine. When trying to replace the memory authentication with LDAP (FreeIPA) authentication, I am able to get the service to log users in, but they are not given a role.

The reason for this is that is, it is using the full DN of the user in the memberUid field, which only has a username in it.

A comment from @abbra made me realize, I had forgotten how my groups are organized. We have a set of base groups, call them roles, these roles are members of different groups. So when looking up the member field in cn=groups,cn=accounts,dc=somedomain,dc=com for the Gravitee groups, it will refer to another group which contains member fields with the complete user dn.

So the question now becomes, how can I make the group lookup recursive in Gravitee? Is it possible, or do I have to add each member explisitly to the group instead?

How can I resolve this? I leave the original question striked through.

Feb 04 16:27:46 somehost.somedomain.com gravitee[22030]: 16:27:46.646 [gravitee-listener-44] DEBUG o.s.s.l.u.DefaultLdapAuthoritiesPopulator - Searching for roles for user 'my_user', DN = 'uid=my_user,cn=users,cn=accounts,dc=somedomain,dc=com', with filter (&(objectClass=posixGroup)(memberUid={0})) in search base 'cn=groups,cn=compat'
Feb 04 16:27:46 somehost.somedomain.com gravitee[22030]: 16:27:46.647 [gravitee-listener-44] DEBUG o.s.s.l.SpringSecurityLdapTemplate - Using filter: (&(objectClass=posixGroup)(memberUid=uid=my_user,cn=users,cn=accounts,dc=somedomain,dc=com))
Feb 04 16:27:46 somehost.somedomain.com gravitee[22030]: 16:27:46.713 [gravitee-listener-44] DEBUG o.s.s.l.u.DefaultLdapAuthoritiesPopulator - Roles from search: []

I have created 4 groups in IPA, which correspond to users, admins, publishers and consumers roles. Each of these groups have members and I can do manual search using ldapsearch to confirm this should be working if Gravitee had used the uid instead of the whole DN.

security:
  # When using an authentication providers, use trustAll mode for TLS connections
  trustAll: true
  providers:  # authentication providers
    - type: ldap
      context:
        username: ""
        password: ""
        url: "ldaps://<LDAP_SERVER_HOSTNAME>:<LDAP_PORT>/dc=somedomain,dc=com"
        base: "dc=somedomain,dc=com"
      authentication:
        user:
          # Search base for user authentication. Defaults to "". Only used with user filter.
          # It should be relative to the Base DN. If the whole DN is o=user accounts,c=io,o=gravitee then the base should be like this:
          base: "cn=users,cn=accounts"
          # The LDAP filter used to search for user during authentication. For example "(uid={0})". The substituted parameter is the user's login name.
          filter: "(&(objectClass=posixAccount)(uid={0}))"
          # Specifies the attribute name which contains the user photo (URL or binary)
          #photo-attribute: "jpegPhoto"
        group:
          # Search base for groups searches. Defaults to "". Only used with group filter.
          # It should be relative to the Base DN. If the whole DN is o=authorization groups,c=io,o=gravitee then the base should be like this:
          base: "cn=groups,cn=compat"
          filter: "(&(objectClass=posixGroup)(memberUid={0}))"
          role:
            attribute: "cn"
            mapper: {
              gt_consumer: API_CONSUMER,
              gt_publisher: API_PUBLISHER,
              gt_admins: ADMIN,
              gt_users: USER
            }
      lookup:
        # allow search results to display the user email. Be careful, It may be contrary to the user privacy.
        allow-email-in-search-results: true
        user:
          # Search base for user searches. Defaults to "". Only used with user filter.
          # It should be relative to the Base DN. If the whole DN is o=user accounts,c=io,o=gravitee then the base should be like this:
          base: "cn=users,cn=accounts"
          # The LDAP filter used to search for user during authentication. For example "(uid={0})". The substituted parameter is the user's login name.
          filter: "(&(objectClass=posixAccount)(uid={0}))"
Score:0
ng flag

memberUid attribute by definition only contains the uid itself. If you need a full DN, you should be using member attribute in the group entry and memberOf in the user entry.

I would suggest to avoid using compat tree if possible. Definitely do not mix both compat and normal subtrees. Use cn=accounts,dc=somedomain,dc=com as a base DN and then use cn=groups for groups base, cn=users for users' base.

Mogget avatar
ru flag
I have been looking into what you wrote and I realized that what you wrote is correct and the groups (not compat) has member fields, but in our case the field is "recursive" in that it refers to another group because we try to be role based instead of adding users directly into each and every group. So the question is now, how can I get the group section to look up the member field, and when it find another group, look in that to check if the user is a member. I will update the question to reflect this.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.