Skip to content

Introducing Ververica’s New Brand Identity!

Read more

Setting up Role-based Access Control (RBAC) with UAA & LDAP in Ververica Platform


User Account and Authentication (UAA) from Cloud Foundry is a free, open source, and enterprise scale identity management and authorization service. Its primary role is as an OAuth2 provider, issuing tokens for client applications to use when they act on behalf of end users. Ververica Platform can be configured to authenticate against UAA thanks to its support of the OpenID Connect (OIDC) protocol. UAA can also be a bridge to other sources of truth about users and their groups, such as Lightweight Directory Access Protocol (LDAP) services. Role-based Access Control (RBAC) in Ververica Platform allows you to control the platform access based on roles that can be bound to entities such as users or groups. In this article, we walk you through the steps to set up Ververica Platform RBAC with UAA integrated with LDAP such that an authenticated user is assigned a specified role automatically based on his/her groups in LDAP.


Before you continue, make sure you have the following setup in place:

The Big Picture

Authentication and authorization is available in Ververica Platform Stream Edition or above. Once authenticated, a user is assigned the role admin, owner, editor or viewer based on the configured role bindings, the username, and the user’s group. These roles are associated with a Ververica Platform Namespace. Different roles have different privileges in that namespace. For example, an editor has read and write access to all resources within a namespace except Deployment Targets and API Tokens.

When the authentication and authorization against UAA and LDAP is configured, Ververica Platform can assign correct roles to users as it can get usernames and groups from LDAP via UAA. Here is the big picture showing the interactions between Ververica Platform, UAA and LDAP:


interactions between Ververica Platform, UAA and LDAP, Apache Flink, big data, Role based access control, RBAC


  1. When authentication is enabled, the Ververica Platform Web UI is password-protected. Users who try to access the Web UI are redirected to the configured OIDC provider’s (here UAA’s) login page.

  2. Once UAA receives a username and a password from a user, it searches the user’s Distinguished Name (DN) in the LDAP server based on the configured mapping (explained in a later section of this article). Then it attempts an LDAP bind with the user’s DN and the provided password.

  3. When the authentication succeeds, UAA retrieves the LDAP user and group information.

  4. UAA encodes the user and group information into tokens which are then returned to Ververica Platform.


LDAP Users and Groups

To setup authentication and authorization, users and groups have to be configured in LDAP. For demonstration purposes in this article, we are going to use the following setup:

LDAP, Ververica Platform, RBAC, Apache Flink, big data, Role based access control

Here we have four users: user1, user2, user3 and vvpadmin. user1, user2, and user3 are members of the group default.editors. user1 is also a member of the group devops.viewers. We use the objectClass groupOfNames to define LDAP groups. vvpadmin will be used as the administrator of Ververica Platform. The passwords of all users are password. We run our OpenLDAP server locally at ldap://localhost:389.

important-clipart-general-information-1If you are setting up a local testing OpenLDAP server for trying out the steps described in this article, you can bootstrap the users and the groups with the attached ldap-data.ldif.


Integrate UAA with LDAP

To connect UAA to LDAP, append the following configuration into the UAA configuration file uaa.yml. If you started your UAA with ./gradlew run, this is ./scripts/cargo/uaa.yml. Otherwise, consult your UAA administrator for the location of the file. It should be specified by one of ${UAA_CONFIG_URL}, file:${UAA_CONFIG_FILE}, file:${UAA_CONFIG_PATH}/uaa.yml.

spring_profiles: ldap,default
    file: ldap/ldap-search-and-bind.xml
    url: 'ldap://localhost:389/'
    userDn: 'cn=admin,dc=example,dc=com'
    password: 'secret'
    searchBase: 'ou=people,dc=example,dc=com'
    searchFilter: 'cn={0}'
    referral: follow
    file: 'ldap/ldap-groups-map-to-scopes.xml'
    searchBase: 'ou=people,dc=example,dc=com'
    searchSubtree: true
    groupSearchFilter: 'member={0}'
    maxSearchDepth: 10
    autoAdd: true
      - roles
    - '*'

In the configuration above, ldap.profile and ldap.base specify how UAA maps a username to a user DN in LDAP. The LDAP server is specified via ldap.base.url. You need to adjust the url according to your setup. ldap.groups specifies how UAA retrieves the group information for a given user DN. The configuration member={0} here is specific to the objectClass groupOfNames. If you use another objectClass to define LDAP groups, you need to adjust this accordingly. For more detailed explanations on ldap.base and ldap.groups, you can reference to the UAA and LDAP integration documentation. The purpose of attributeMappings and externalGroupsWhitelist here is to let UAA add the group information into the roles claim of the returned ID token.


Generate a JWS Key Pair

As Ververica Platform expects a signed JSON Web Token (JWT), we run the following command to generate a signing key:

openssl genrsa -out signing-key.pem 2048

then add the content of the key into uaa.yml:

    signing-key: |
      <content of signing-key.pem>

Use a Correct IP Address and Port

If your UAA runs remotely and binds to an IP address and a port, you can (re-)start your UAA server now. You can skip the rest of this section and substitute with your UAA IP address and port in the rest of the article.

If you run UAA locally on your computer, we need to bind UAA to an IP address which is reachable from Ververica Platform. This is because when Ververica Platform runs in a Kubernetes environment (e.g., Minikube), localhost is defined in the scope of the Ververica Platform pod, not the machine where you installed UAA. The solution here is to use the Minikube bridge IP, which is in our case. By default, UAA binds to two ports: 8080 and 8081. If any of the ports is occupied on your computer, you need to change the UAA ports. For example, to bind UAA to, change issuer.uri in uaa.yml:


Now, we (re-)start our local UAA:

./gradlew -Pport=18080 run

UAA will then bind to 18080, and 18081. 

important-clipart-general-information-1Check ./uaa/build/reports/tests/uaa-server.log to confirm that UAA has started correctly


Create a Client in UAA

Now that UAA has started, run the following commands to create a client vvp in UAA. Make sure to include roles in the scope because we will get the group information via the roles claim. Ververica Platform will use the client vvp to get tokens from UAA.

uaac target
uaac token client get admin -s adminsecret
uaac client add vvp --name VVP --secret vvpsecret \
  --scope openid,roles \
  --authorized_grant_types authorization_code,refresh_token,client_credentials,password \
  --authorities uaa.resource \
  --redirect_uri http://localhost:8080/login/oauth2/code/vvp

The password included in --authorized_grant_types above is optional. We use it only in the following verification:

uaac token owner get vvp user1 -s vvpsecret -p password
uaac context
uaac token decode <id_token from the command `uaac context`>

If authenticated correctly, we should be able to see the following roles claim in the ID token:

roles: default.editors devops.viewers

Integrate Ververica Platform with UAA

To use UAA for authentication and authorization in Ververica Platform, add the following configuration into the Helm values file values.yaml. Make sure to request the roles scope and set groupsClaim to roles in order to retrieve group information via the roles claim when a user is authenticated. Note that provider.issuerUri and endSessionEndpoint reference to the IP address and the port where UAA binds.

      enabled: true
        groupsClaim: roles
        registrationId: vvp
          clientId: vvp
          clientSecret: vvpsecret
          redirectUriTemplate: "{baseUrl}/{action}/oauth2/code/{registrationId}"
          clientAuthenticationMethod: basic
          authorizationGrantType: authorization_code
          - openid
          - roles
          userNameAttribute: email

Now we can start or upgrade Ververica Platform with the created values.yaml above. Do not forget to add your license into values.yaml if you are using Ververica Platform 2.1 or above before you start.

When Ververica Platform starts, it has a namespace default. In the namespace default, any authenticated user (system:authenticated) is assigned the owner role by default. We can now login to Ververica Platform as vvpadmin, remove the default role binding and add a new role binding to assign all users in the group default.editors the role editor (see the screenshot below). Open a Private Window or a Incognito Window from your browser, login to Ververica Platform with user1, you will be able to tell you have editor role in the namespace default, e.g., you can create secret values but cannot create API tokens (the menu item is grayed out).

Ververica Platform, Role Based Access Control, RBAC, Flink, Apache Flink, stream processingIf you have another Ververica Platform namespace (e.g., devops), you can group your users into different LDAP groups (e.g., devops.editors, devops.viewers) and setup the role bindings in that namespace accordingly. This way, users will get their specified roles automatically once they login.

important-clipart-general-information-1If you change the group membership of a user in LDAP after the user login to Ververica Platform, the new group membership assignment will be effective when the user logs out and logs in again.



In this article, we set up the Role-based Access Control in Ververica Platform by integrating it with UAA and LDAP such that usernames and user groups are passed from LDAP to Ververica Platform via the UAA’s ID token. When the group-based role binding is set up in Ververica Platform, users are automatically assigned their roles based on their LDAP group membership once they login.

Role-based Access Control is an important feature in Ververica Platform to support Multitenancy in large enterprise environments. You can request your free Enterprise trial of Ververica Platform Stream Edition or contact our team for any questions.


Jun Qin
Article by:

Jun Qin

Find me on:


Our Latest Blogs

Introducing Ververica’s New Brand Identity featured image
by Alexander Walden June 21, 2022

Introducing Ververica’s New Brand Identity

Today we are extremely excited to introduce our new visual brand identity for Ververica and our products, such as Ververica Platform! This has been in the works for many months, and a project we...
Read More
Monitoring Large-Scale Apache Flink Applications, Part 2: Metrics for Troubleshooting featured image
by Nico Kruber May 31, 2022

Monitoring Large-Scale Apache Flink Applications, Part 2: Metrics for Troubleshooting

The previous article in this series focused on continuous application monitoring and presented the most useful metrics from our point of view. However, Flink’s metrics system offers a lot more, and...
Read More
Monitoring Large-Scale Apache Flink Applications, Part 1: Concepts & Continuous Monitoring featured image
by Nico Kruber May 24, 2022

Monitoring Large-Scale Apache Flink Applications, Part 1: Concepts & Continuous Monitoring

As the original creators of Apache Flink, we are often asked for best practices around monitoring Flink applications and people want to know which metrics they should monitor for their applications...
Read More