0

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}))"

1 Answer 1

0

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.

1
  • 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.
    – Mogget
    Feb 14, 2022 at 10:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .