add dynamic group mapping for AD provider

[rshlin]

Description

implemented dynamic group mapping for AD provider.

Related Issue

https://support.tyk.io/hc/requests/11700
https://tyktech.atlassian.net/browse/TT-2400

Motivation and Context

After deserializing ldap response with user info previous implementation of ADProvider was grabbing the first element from user attribute with type array and hence all valuable group membership information was cutted off.

• fixed ADProvider
• added handler for []string array of AD groups @ tyk_handler.go:groupStringer function
• minor code style improvements

How This Has Been Tested

Ran TIB as standalone, AD, dashboard. Used the following profile for test:

[
  {
    "ActionType": "GenerateOrLoginUserProfile",
    "ID": "1",
    "OrgID": "5f48ae5f62a1be5a74f39377",
    "IdentityHandlerConfig": {
      "DashboardCredential": ""
    },
    "ProviderConfig": {
      "LDAPUseSSL": false,
      "FailureRedirect": "{{ failure redirect }}",
      "LDAPPort": "389",
      "LDAPServer": "{{ server address }}",
      "LDAPAdminUser": "{{ DN of admin user }}",
      "LDAPAdminPassword": "{{ admin password }}",
      "LDAPSearchScope": 2,
      "LDAPFilter": "(&(objectcategory=user)(sAMAccountName=*USERNAME*))",
      "LDAPEmailAttribute": "mail",
      "LDAPFirstNameAttribute": "givenName",
      "LDAPLastNameAttribute": "sn",
      "LDAPGroupMembershipAttribute": "memberOf",
      "LDAPUserDN": "{{ base directory }}"
    },
    "DefaultUserGroupID": "5f48b17462a1be7845a7a448",
    "CustomUserGroupField": "memberOf",
    "UserGroupMapping": {
      "{{ DN of group }}": "5f48b19262a1be7845a7a449"
    },
    "ProviderName": "ADProvider",
    "ReturnURL": "{{ return URL }}",
    "Type": "passthrough"
  }
]

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Refactoring or add test (improvements in base code or adds test coverage to functionality)

Checklist

• Make sure you are requesting to pull a topic/feature/bugfix branch (right side). If pulling from your own
  fork, don't request your master!
• Make sure you are making a pull request against the master branch (left side). Also, you should start
  your branch off our latest master.
• My change requires a change to the documentation.
  • If you've changed APIs, describe what needs to be updated in the documentation.
  • If new config option added, ensure that it can be set via ENV variable
• I have updated the documentation accordingly.
• Modules and vendor dependencies have been updated; run go mod tidy && go mod vendor
• When updating library version must provide reason/explanation for this update.
• I have added tests to cover my changes.
• All new and existing tests passed.
• Check your code additions will not fail linting checks:
  • go fmt -s
  • go vet

[tbuchaillot]

@rshlin left some comments! otherwise, it looks good!

[tbuchaillot]

@rshlin what do you think if here, instead of adding a new config field (s.config.LDAPGroupMembershipAttribute) we just use s.profile.CustomUserGroupField ?

[gregdelhon]

@rshlin we are thinking of implementing this using the suggestion made by @tbuchaillot -- Any objections? Thanks a lot for this!

[rshlin]

I had concerns on using s.profile.CustomUserGroupField because this field had different semantics(see GetGroupId): providers collect relevant identity attributes into a single container and at the end SSOAccessData is uniformly assembled. I wanted to leave these layers(i.e. adapter & core logic) low coupled and introduce a minimum amount of changes(preferably incremental) to make AD mapping work.

Anyway, required design decisions produce insignificant effects at this stage, and I agree with @tbuchaillot suggestion.

[sredxny]

lgtm

[tbuchaillot]

thanks a lot @rshlin for your contribution! We are going to notify you when this is released :)