How to Use Gluu 4.X in Teleport
Use Gluu 4.x IAM as a single source of truth for controlling user access to infrastructure such as databases, vm’s and Kubernetes clusters in Teleport
In this article we will be dealing with a use case where organizations want to use one source of truth, which is their IAM system. The objective is giving users access dynamically inside Teleport to different resources based on their role, or perhaps group inside the IAM system without needing to map users inside Teleport manually. If the security admin was to modify the role of any user in the IAM system that would immediately take effect on the resources that user gets access to.
Gluu Identity and Access Management is an open source platform for web & mobile single sign-on (SSO), two-factor authentication (2FA) and API access management.
Teleport is an excellent tool for managing access of infrastructure in a secure and easy method without relying on long lived certs and keys when coupled with an oidc connector. At the time of this writing Teleport requires a license to use an oidc connector.
Getting Started
Follow instructions to install Teleport in HA mode. In our case at @GluuFederation, we used Teleport on GKE. We also installed Gluu in the same GKE cluster as specified in the Gluu docs. However, you may choose to install either services on a vm for demonstration purposes.
The Gluu Configuration
Open the domain used for Gluu and sign in using the admin credentials you entered during the setup.
Our objective is to associate a user with an organization, and give the user access based on which organization the user is associated with. Of course, this can get more detailed by also passing a role inside that organization, but for this articles purpose we will limit the scope to giving the user access based on which organization that user belongs to. An organization can also be teams.
We will start off by using an existing attribute inside Gluu called Organization . Click on Configuration → Attributes and you should see the following page:
Search for the attribute organization , open it, enable Multivalued and Include in SCIM extension , then click on Update at the bottom left of the page. Enabling this option will allow us to pass several organizations to a single user as you will see later.
We will be passing the above attribute in the profile scope which Teleport will parse and get through the oidc client. Under OpenID Connect in the left main navigational menu press Scopes:
Search for the scope profile, open it, click on Add Claim and choose the Organization attribute. At the bottom left of the page click on Update.
In order to register an auth connector in Teleport we need to create an oidc client in Gluu. Under OpenID Connect in the left navigational menu press Clients:
Create a new client by clicking on + Add Client , and fill the information as attached below in order for Teleport to parse the user info ,and dynamically create the user and its association with the resources using labels. You will mainly need to change TELEPORT_FQDN according to your setup.
OPENID CONNECT CLIENTS DETAILS
— — — — — — — — — — — — — — —
- **Name:** teleport
- **Description:** Used to login users dynamically inside Teleport
- **Client ID:** f410691c-xxxx-xxxx–xxxx–xxxxxxxxxxxx
- **Subject Type:** pairwise
- **ClientSecret:** XXXXXXXXXXX
- **Application Type:** web
- **Persist Client Authorizations:** true
- **Pre-Authorization:** true
- **Authentication method for the Token Endpoint:** client_secret_basic
- **Logout Session Required:** false
- **Include Claims In Id Token:** false
- **Disabled:** false
- **Login Redirect URIs:** [https://TELEPORT_FQDN/v1/webapi/oidc/callback]
- **Scopes:** [profile, openid, email, user_name]
- **Grant types:** [authorization_code]
- **Response types:** [code]
The above information was made available to easily create the client. The page after creating the oidc client will look like this :
Teleport oidc client
Let’s create a dummy user in Gluu so we use this later as a demo. On the left main navigational menu click on Users → Add person . Notice below we are passing in the Organizations siwa and sso . Hence, the user demo should have access to all resources labeled with organization: siwa and organization: sso in our infrastructure .
We are now ready to complete our configuration in Teleport. Take note of the client id and client secret that was generated as it will be used in the next section to create the auth connector.
The Teleport Configuration
Login the Teleport UI using the user created during the Teleport setup instructions with editor access.
Under Team, click on Roles then on the top right of the page click CREATE NEW ROLE
We will be creating a dynamic role called dynamic-organiation-role that maps to the external attribute o that is passed by Gluu. This will be parsed so it reads for example organization: sso. For a user that belongs to the organization sso the following will be true:
- Allows access to applications with label
organization: sso. - Allows access to databases with label
organization: sso. - Allows access to Kubernetes clusters with label
organization: sso. - Allows access to nodes with label
organization: ssowith userubuntu.
You may copy and use the below yaml to create the role swiftly.
kind: role
metadata:
name: dynamic-organization-role
spec:
allow:
app_labels:
organization: '{{external.o}}'
db_labels:
organization: '{{external.o}}'
kubernetes_labels:
organization: '{{external.o}}'
logins:
- ubuntu
node_labels:
organization: '{{external.o}}'
deny: {}
options:
cert_format: standard
desktop_clipboard: true
enhanced_recording:
- command
- network
forward_agent: false
max_session_ttl: 8h0m0s
port_forwarding: true
record_session:
desktop: true
version: v5
Its time to create the auth connector that Teleport will use to parse the user claims. Under Team, click on Auth Connectors then on the top right of the page click NEW AUTH CONNECTOR → OIDC CONNECTOR
OIDC auth connector
kind: oidc
metadata:
name: gluu_dynamic_oidc
spec:
claims_to_roles:
- claim: o
roles:
- dynamic-organization-role
value: '*'
client_id: f410691c-xxxx-xxxx-xxxx-xxxxxxxxxxxx
client_secret: xxxxxxxxxxxxxxxxxxxx
display: Gluu
issuer_url: https://GLUU_FQDN
redirect_url: https://TELEPORT_FQDN/v1/webapi/oidc/callback
scope:
- profile
version: v2
We will map the claim o with the dynamic role we created previously passing in the profile scope. In the above yaml please pass in the client_id , client_secret , the GLUU_FQDN, the TELEPORT_FQDN and then create the connector.
Demonstration
Lets try to use the demo user now to see what resources we get access to. Head to https://TELEPORT_FQDN and click on the auth connector created Gluu . You should be redirected to the Gluu IAM login page.
Gluu IAM login
After a successful login you should be redirected back to Teleport.
Notice how the user demo has access to two nodes that are labeled with organization: siwa and organization: sso . Notice that this user was created automatically in Teleport, and that the organizations that were passed by the dynamic role were mapped dynamically correctly. In other words, if the user demo would later change in Gluu IAM platform to add a new organization or remove one, that user will automatically be granted access to new resources or restricted from one place, the IAM platform.
In Conclusion
Security is one of the most important aspects a company or organization can easily get lost with. Managing resources and infrastructure in an effective secure manner is absolutely critical. Having the security team manage access to different resources on different clouds or on premise is a night mare that awaits one small mistake such as a forgotten pem file for an off boarded employee. Having one source of truth to manage all the resources of an organization via the users profile and role eases and better secures the company from misuse, illegal entry and complies with security standards.
This article presented a method in which the Gluu IAM platform was used as the source of user role dynamically mapped to roles on infrastructure.