Tyk Identity Broker (TIB) is a solution for integrating various Identity Management Systems (such as LDAP, Social OAuth, Okta) with your Tyk installation.With TIB, you gain the flexibility to connect your existing user directories to Tyk Dashboard or Developer Portal, streamlining access management and enhancing security. Whether you’re looking to implement SSO, leverage social logins, or integrate with enterprise identity providers, TIB provides the tools and configurations to make it happen.This page introduces general features of Tyk Identity Broker (TIB) and how to configure them. If you are looking for global configurations of the TIB deployment refer this config file.We will delve into the following key topics:
Introduction to Tyk Identity Broker: Explore key concepts, configuration options, and implementation steps for TIB. You’ll learn how to set up profiles for different identity providers, understand the flow of authentication requests, and customize the integration to fit your specific needs.
Single Sign On with Tyk: We will learn how to implement seamless SSO experiences for Tyk Dashboard and Developer Portal.
Tyk Identity Broker (TIB) is a component providing a bridge between various Identity Management Systems such as LDAP, Social OAuth (e.g. GPlus, Twitter, GitHub) or Basic Authentication providers, to your Tyk installation.TIB can act as a bridge between the API Gateway, Tyk Portal or even the Tyk Dashboard, and makes it easy to integrate custom IDMs to your system.Starting from Tyk v3.0 TIB has been added as a built-in feature of the Tyk Dashboard. You no longer have to setup a separated instance of the service to make it work with the Dashboard. You now have two options:
Internal TIB: Embedded in dashboard. Easy configuration and set up. Share the same port as the dashboard
External TIB: Installation of TIB as a different component for advanced use cases. Requires changes to the config files and separate port.
What can you do with the Tyk Identity Broker (TIB)?By using the identity broker in conjunction with an IDP you have the ability to perform actions such as:
Enabling easy access via social logins to the developer portal (e.g. GitHub login)
Enabling internal access to the dashboard (e.g. via LDAP/ActiveDirectory)
Enabling easy token generation from a third party for things such as mobile apps and webapps without complex configuration
Identity providers can be anything, as long as they implement the tap.TAProvider interface. Bundled with TIB at the moment you have four provider types:
Social - this provides OAuth handlers for many popular social logins (such as Google, Github and Bitbucket)
LDAP - a simple LDAP protocol binder that can validate a username and password against an LDAP server (tested against OpenLDAP)
Proxy - a generic proxy handler that will forward a request to a third party and provides multiple “validators” to identify whether a response is successful or not (e.g. status code, content match and regex)
SAML - provides a way to authenticate against a SAML IDP.
An identity handler will perform a predefined set of actions once a provider has validated an identity. These actions are defined as a set of action types:
GenerateOrLoginUserProfile - this will log a user into the Tyk Dashboard (this does not create a user, it only creates a temporary session for the user to have access). This flow is defined as next:
GenerateOrLoginDeveloperProfile - this will create or login a user to the Tyk Developer Portal. The flow is similar to GenerateOrLoginUserProfile but in this case if the developer doesn’t exist then it will be created.
GenerateOAuthTokenForClient - this will act as a client ID delegate and grant an Tyk provided OAuth token for a user using a fragment in the redirect URL (standard flow). The flow is defined as:
TIB takes as input one or many profiles that are stored in mongo or a file (it depends on the type of installation), a profile is a configuration that outlines of how to match a identity provider with a handler and what action to perform (Example: enable Dashboard SSO using OpenID and Microsoft Azure as IDP). The Dashboard adds a user interface to manage the profiles.
Each profile is outlined by a series of attributes that will describe: action to perform, IDP to connect, URL’s to redirect on success and failure, etc.
In order to know and understand each of the attributes, implications as well as configure your own profile please consult the profile structure below:
Name of the claim associated with the email value stored in the IDP (Identity Provider).
No
CustomUserIDField
Name of the claim associated with the User ID value stored in the IDP (Identity Provider).
No
IdentityHandlerConfig.DashboardCredential
API Key that will be used to consume the dashboard API to issue nonce codes and validate user data
yes
ReturnURL
Where to redirect and send the claims from the IDP on login. For dashboard SSO it would be http://dashboard-host/tap. For classic portal SSO it would be http://{portal-host}/sso
yes
DefaultUserGroup
When mapping groups, if a group is not found, specify which group to fallback to.
No
CustomUserGroupField
Name of the claim associated with the Group ID values stored in the Identity Provider
No
UserGroupMapping
Map that contains the matching between Tyk groups and IDP group.
No
UserGroupSeparator
The IDP might send the groups to which the user belongs to as a single string separated by any symbol or empty spaces, with this field you can set which symbol to use to split as an array
No
SSOOnlyForRegisteredUsers
A boolean value to restrict the SSO only to users that already exists in the database. Users that do not exist in the database and successfully logins in the IDP will not have access to tyk
This is an integer represents the HTTP status code that represents a successful response from the target service. If the response code matches this value the identity broker treats it as a successful interaction.
No. But one of OKCode, OKResponse, or OKRegex should be filled
OKResponse
This field specifies a particular string that should match with the response body to be considered successful.
No. But one of OKCode, OKResponse, or OKRegex should be filled
OKRegex
Is used to validate the content of the response beyond just the HTTP status code. If the response body contains data that matches this regular expression, it is considered a successful response.
No. But one of OKCode, OKResponse, or OKRegex should be filled
ResponseIsJson
This parameter helps the identity broker understand how to interpret the response body from the target service. If ResponseIsJson is set to true, the broker will expect the response to be in JSON format and will process it accordingly. This includes parsing JSON data to extract relevant information. This is a boolean field.
No
AccessTokenField
The name of the field that contains the access token.
No
UsernameField
The name of the field that contains the username.
No
ExrtactUserNameFromBasicAuthHeader
A boolean value that, when set to true, instructs TIB to gather the user and password from the Authorization header when handling the request.
Name of the provider to be used. Valid values: gplus, github, twitter, linkedin, dropbox, digitalocean, bitbucket, salesforce, openid-connect
Yes
UseProviders.Key
Oauth Client key
yes
UseProviders.Secret
Oauth Client Secret
yes
UseProviders.DiscoverURL
used to dynamically retrieve the OpenID Provider’s configuration metadata, including endpoints and supported features, in JSON format from /.well-known/openid-configuration.
Only required when using openid-connect
UseProviders.Scopes
Specifies the level of access or permissions a client is requesting from the user and the authorization server, for example [“openid”,“email”].
No, however when using openID the scope ‘openid’ should be added
UseProviders.SkipUserInfoRequest
Determines whether to bypass the UserInfo endpoint request, improving performance by relying on the ID token alone for user details.
No
JWE.Enabled
When set to true, JWE will be enabled, allowing Tyk to decrypt the ID token received from the IdP. If set to false, the ID token will not be decrypted.
No
JWE.PrivateKeyLocation
Specifies the path or identifier (certid) for the certificate that contains the private key used to decrypt the ID token when JWE is enabled. This certificate must be in PEM format and include both the public certificate and the private key.
This is a URL, e.g. https://login.microsoftonline.com/your-tenant-id/federationmetadata/2007-06/federationmetadata.xml, that links to XML metadata containing information necessary for interaction with SAML-enabled identity or service providers. The document contains example URLs of endpoints, information about supported bindings, identifiers and public keys. Once you create your TIB profile you can find the SP metadata file under {Dashboard HOST}/auth/{TIB Profile Name}/saml/metadata
Yes
CertLocation
An X.509 certificate and the private key for signing your requests to the IDP. The value for CertLocation should be the path to a single file with the cert and key concatenated, e.g. /etc/ssl/certs/example_cert.pem. When used in an embedded TIB instance in the dashboard then the CertLocation value can be the certId from the certificate manager. For further details please refer to SSO with SAML
Yes
SAMLBaseURL
The host of TIB, e.g. http://tyk-dashboard:3000/, that will be used in the metadata document for the Service Provider. This will form part of the metadata URL used as the Entity ID by the IDP. The redirects configured in the IDP must match the expected Host and URI configured in the metadata document made available by Tyk Identity Broker.
Yes
ForceAuthentication
Ignore any session held by the IDP and force re-login every request. Defaults to false
URL to redirect the user if the login is not successful
Yes
EntityId
It is used to distinguish between different entities (IDP & SP) and ensure proper routing and validation of SAML assertions and requests. Defaults to the value set in the field IDPMetadataURL
Embedded TIB: Starting from Tyk Dashboard v3.0 TIB is built-in to the dashboard, in this case TIB will store the profiles in the same mongo database configured for dashboard
Standalone TIB: Deployed as a seperate entity. In the standalone TIB, the profiles will be stored in file indicated when the app is started
Pre-requisitesBelow are the prerequisites of TIB:
Tyk Gateway v1.9.1+
Redis
Tyk Dashboard v0.9.7.1+ (Only if you want to do SSO to Tyk Dashboard UI or Tyk Developer Portal)
For the embedded TIB you don’t have to do anything, only ensure that in the Dashboard’s config file identity_broker is not pointing to an external service, and identity_broker.enabled is set to true. For example:
Copy
Ask AI
"identity_broker": { "enabled": true,},
This settings behaves as follows:
If enabled = false then neither the external or internal TIB will be loaded
If enabled = true and the tib host is not present the internal TIB will be loaded
If enabled = true and the tib host is set, then external TIB will be loaded
Linux Packages:You can install via packages (deb or rpm).
Helm Chart for Kubernetes:Tyk Helm Chart does not support installing TIB as separate application. If you want to enable embedded TIB in Dashboard, you can do so by updating tib.enabled to true in tyk-dashboard chart. If you are using an umbrella chart from us (e.g. tyk-stack and tyk-control-plane), you can do so by updating tyk-dashboard.tib.enabled to true.
To secure session cookies within Tyk Identity Broker (TIB) when integrating with social providers, setting the TYK_IB_SESSION_SECRET environment variable is crucial. This variable plays a pivotal role in hashing session cookies, thereby enhancing security. By default, if this variable isn’t explicitly set, TIB falls back to using the Tyk Dashboard’s admin_secret when it’s embedded in the dashboard.For a seamless and secure setup, start by generating a strong, unique secret string. It is recommended to use a string with 32 or 64 bytes to ensure optimal security, this string will be your session secret. In a Linux, Unix, or MacOS environment, you can set this variable by running the command export TYK_IB_SESSION_SECRET='your_secret'.
No command line arguments are needed, but if you are running TIB from another directory or during startup, you will need to set the absolute paths to the profile and config files:
Copy
Ask AI
Usage of ./tyk-auth-proxy: -c=string Path to the config file (default "tib.conf") -p#=string Path to the profiles file (default "profiles.json")
SSO gives users the ability to log in to multiple applications without the need to enter their password more than once.
Authentication protocols such as OpenID Connect and SAML enable an application to verify the identity of users from an organization without the need to self store and manage them, and without doing the identification process and exposing their passwords to that application. Their lists of users and passwords are kept safe in one single place, in the IDP that the organization has chosen to use. The Authorization server of the IdP identify the users for a pre-registered and approved application (client in OAuth and OIDC terminology).
SSO is sometimes complicated to understand or set up but can be easily accomplished by using the built-in Tyk Identity Broker (TIB).Using our Tyk-Identity-Broker (TIB), you can do both - use your existing users directory to login to the Dashboard or Developer Portal and have an SSO. TIB, among other options, supports four methods for login to Tyk’s UI:
SSO is sometimes complicated to understand or set up but once you get it and learn to use our Tyk-Identity-Broker it becomes an easy task.In short, all you need is as follow:
Access the Identity Manager under System Management in the Tyk Dashboard
Create a profile for your preferred IDP
Get the client_id + secret that are defined on your IDP
Set the Callback URL generated by Tyk on your IDP
Provide your SSO profile in Tyk with the Discover URL (well known endpoint)
Visit the Login URL after saving your profile to initialize the login
The SSO API allows you to implement custom authentication schemes for the Dashboard and Portal. You can access the API by both admin and dashboard APIs.
Our Tyk Identity Broker (TIB) internally also uses these APIs.
which allow you to generate a temporary authentication token, valid for 60 seconds. They make same thing you can select one of them and use it.
However, the admin API requires admin-auth header which should be same with admin-secret parameter in tyk_analytics.conf, the regular API requires authorization header which should be same with the user authentication token.
Once you have issued a token you can login to the dashboard using the /tap url, or to the portal using the <portal-url>/sso URL, and provide an authentication token via the nonce query param.
If nonce is valid, Tyk will create a temporary user and log them in.If you want to re-use existing dashboard users, instead of creating temporary ones, you can set "sso_enable_user_lookup": true variable in the Dashboard config file (tyk_analytics.conf). This way you can set individual permissions for users logged via SSO.
Set up default permissions for the dashboard
If you use the token with dashboard scope, and would like to avoid login in as admin user (which is the default permissions), you can add the sso_permission_defaults configuration option to the Dashboard config file (tyk_analytics.conf) to specify SSO user permissions in the following format:
As alternative, you can set sso_default_group_id to specify User Group ID assigned to SSO users.In order to set individual user permissions, you should first create this users in the dashboard first, set needed permissions, enable sso_enable_user_lookup to true inside dashboard config. If SSO user with the same email will be found in Dashboard users, it will re-use his permissions.
Sample Login Request
Copy
Ask AI
GET /tap?nonce=YTNiOGUzZjctYWZkYi00OTNhLTYwODItZTAzMDI3MjM0OTEw HTTP/1.1Host: localhost:3000
The social provider for the Tyk Identity Broker is a thin wrapper around the excellent goth social auth library, modified slightly to work with a multi-tenant structure. The social provider should provide seamless integration with:
Bitbucket
Digital Ocean
Dropbox
GitHub
Google+
Linkedin
Twitter
Salesforce
The social provider is ideal for SSO-style logins for the Dashboard or for the Portal. For certain providers (mainly Google+), where email addresses are returned as part of the user data, a constraint can be added to validate the users domain. This is useful for Google For Business Apps users that want to grant access to their domain users for the Dashboard.For more social provider examples see the Tyk Identity Broker (TIB) v0.2 Repo Readme.
A common use case for Tyk Gateway users is to enable users to log into a web app or mobile app using a social provider such as Google, but have that user use a token in the app that is time-delimited and issued by their own API (or in this case, Tyk).Tyk can act as an OAuth provider, but requires some glue code to work, in particular, generating a token based on the authentication of a third party, which needs to run on a server hosted by the owner of the application. This is not ideal in many scenarios where authentication has been delegated to a third-party provider (such as Google or Github).In this case, we can enable this flow with Tyk Gateway by Using TIB.What the broker will do is essentially the final leg of the authentication process without any new code, simply sending the user via TIB to the provider will suffice for them to be granted an OAuth token once they have authenticated in a standard, expected OAuth pattern.Assuming we have created a client ID and secret in Google Apps to grant ourselves access to the users data, we need those details, and some additional ones from Tyk itself.
Register a new OAuth client. Let’s call it WebApp 1 (Select “New Credentials -> OAuth Client ID”)
Select Web App
Add the following URL (modify for your domain) to the “Authorized redirect URIs” section: http://tib-hostname:TIB-PORT/auth/{PROFILE-ID}/gplus/callback
TIB will use the OAuth credentials for GPlus to access and authenticate the user, it will then use another set of client credentials to make the request to Tyk to generate a token response and redirect the user, this means we need to create an OAuth client in Tyk Dashboard before we can proceed.One quirk with the Tyk API is that requests for tokens go via the base APIs listen path ({listen_path}/toauth/authorize), so we will need to know the listen path and ID of this API so TIB can make the correct API calls on your behalf.
There’s a few new things here we need to take into account:
APIListenPath: This is the listen path of your API, TIB uses this to generate the OAuth token.
BaseAPIID: The base API ID for the listen path mentioned earlier, this forms the basic access grant for the token (this will be superseded by the MatchedPolicyID, but is required for token generation).
ClientId: The client ID for this profile within Tyk Gateway.
Secret: The client secret for this profile in Tyk Gateway.
RedirectURI: The Redirect URL set for this profile in the Tyk Gateway.
ResponseType: This can be token or authorization_code, the first will generate a token directly, the second will generate an auth code for follow up access. For SPWA and Mobile Apps it is recommended to just use token.
When TIB successfully authorizes the user, and generates the token using the relevant OAuth credentials, it will redirect the user to the relevant redirect with their token or auth code as a fragment in the URL for the app to decode and use as needed.There is a simplified flow, which does not require a corresponding OAuth client in Tyk Gateway, and can just generate a standard token with the same flow.
Similarly to logging into an app using Tyk, OAuth and Google Plus, if we have our callback URL and client IDs set up with Google, we can use the following profile setup to access our Dashboard using a social provider:
The login to the Dashboard makes use of a one-time nonce to log the user in to the session. The nonce is only accessible for a few seconds. It is recommended that in production use, all of these transactions happen over SSL connections to avoid MITM snooping.Domain constraint ensures that only users from yourdomain.com domain-based email accounts are allowed to login.
Replace it with correct domain or remove this section if you don’t want to set this constraint.When TIB successfully authorizes the user, and generates the token using the relevant OAuth credentials, it will redirect the user to the relevant redirect with their token or auth code as a fragment in the URL for the app to decode and use as needed.There is a simplified flow, which does not require a corresponding OAuth client in Tyk Gateway, and can just generate a standard token with the same flow.
This is an end-to-end worked example of how you can use AzureAD and our Tyk Identity Broker (TIB) to log in to your Dashboard.
This guide assumes the following:You already have authorized access to Tyk’s Dashboard. If you haven’t, get the authorization key by following this guide.
Access your Azure Portal and navigate to the Azure Active Directory page.
Go to app registrations and create or access an application you want to use for Dashboard access.
If you are creating an application, give it a name and register it
Add a redirect URL to your application as callback to TIB in your Azure application:
In your app, either via the Authentication menu or the redirect URL shortcut navigate to and add the redirect to TIB in the Web category i.e. http://localhost:3000/auth/{PROFILE-NAME-IN-TIB}/openid-connect/callback.
Go to Overview and add a secret in Client Credentials. Don’t forget to copy the secret value, not the secretID.
Once it’s working you can also add more enhancements such as automatic user group mapping from your AzureAD security groups or users groups to Tyk Dashboards groups.
User group mapping
Group mapping can be managed from Advanced Settings section of the Profile Configuration screen.As illustrated in the screen below the following information must be provided:
Identity provider role
Tyk User Group: This can be created from the User Groups section of the dashboard (reference a link to a page in tyk docs here to show how to create a user group). When creating your User Group, one can also select and adjust the permissions for each group.
For more information on how to set and change user permissions, head to this guideYou can select the scopes you would like your request to include. By default, Tyk will provide the connectid scope, anything additional must be requested.
For debugging purposes, you can find an example we created using the OpenID Connect playground.
Add the redirect url found on the OpenID Connect site to the redirect urls found under the Web section
Copy the OpenID Connect endpoint from the Azure site
On the OpenID Connect site select Edit. In the Server Template dropdown menu select the Custom option and paste the endpoint in the Discovery Document URL.
Press the Use Discovery Document button and this will autofill Authorization Token Endpoint, Token Endpoint, and Token Keys Endpoint
Copy and paste the Client ID and Client Secret from the Azure site to your ConnectID. Scope is autofilled for you and save the configuration.
Press start at the bottom of the Request window and if done correctly, this should prompt you to sign in to your Azure account.
You should then be redirected back to OpenID Connect where you’ll be shown the Exchange Code. This needs to be turned into an access token. Press the exchange button under the request and then press Next.
We can then verify this by pressing the verify button. We can also view the information or scope of what is being returned by heading to jwt.io and viewing the payload: data there.
We are given an object with key, value pairs and we can pass in the key ie. name to our Custom User Group and the value of to our Identity Provider Role in our Tyk dashboard as shown in the example above.
Create a developer account on the Okta Developer site.
You’ll get a domain such as https://<okta-org>.okta.com/.well-known/openid-configuration
Login and create a Web Application as follows:
Under Application, click Add Application
Choose Web
Change the name of the app
Tick Authorization Code
Click Done
Note: These instruction are for the new Okta’s Developer Console, for the Classic UI instructions are slightly different.
Add a callback to TIB in your application:
Under General, click Edit and update the Login redirect URIs field with the endpoint on TIB http://localhost:3010/auth/{PROFILE-NAME-IN-TIB}/openid-connect/callback.
{PROFILE-NAME-IN-TIB} - this can be any string you choose, as long as you use the same one for the profile in TIB.
Permissions to login via Okta:
Under the Assignments tab, make sure group assignments is set to everyone (for now, you will change this later!).
Start TIB by running the binary (profiles.json is in the same CWD)
See Install TIB for detailed instructions on how to install TIB
Test that it works:
From the broswer call http://localhost:3010/auth/{PROFILE-NAME-IN-TIB}/openid-connect
If it’s working you’ll be redirected to Okta’s web page and will be asked to enter your Okta user name and password.
If you were successfully authenticated by Okta then you’ll be redirected to the Tyk Dashboard and login into it without going through the login page. Job’s done!
If you need to update your profile then you can use TIB’s REST API as follows:
Once it’s working you can also add two more enhancements - SSO and MFA
SSO login into the Dashboard via a login page
You will need to:
set up a web server with a login page and a form for user and password
Update tyk_analytics.conf to redirect logins to that url
Explicit details are in steps 6-7
Multi-Factor-Authentication (MFA) Support
MFA works out-of-the-box in Tyk since luckily Okta supports it. you would need to add it to the configuration of the account holder. Under Security --> Multifactor --> Factor types you can choose the types you want. For instance I chose Google Authenticator.
While trying to login to the Dashboard, Okta enforced the MFA and asked me to use the Google Authenticator:
I had to download the Google Authenticator and identify with the generated code
I successfully authenticated with Google Authenticator
If you get a 400 Bad Request it means the profile name in the login endpoint is not identical to the profile name in the callback that you set up on Okta’s app:
On Okta’s app - Login redirect URIs:http://localhost:3010/auth/{PROFILE-NAME-IN-TIB}/openid-connect/callback.
The endpoint to test - http://localhost:3010/auth/{PROFILE-NAME-IN-TIB}/openid-connect
This will walk you through securing access to your Tyk Dashboard using OpenID Connect (OIDC) identity tokens with Auth0. We also have the following video that will walk you through the process.Prerequisites
Our Tyk Identity Broker (TIB). You can use the internal version included with a Tyk Self-Managed installation and Tyk Cloud, or an external version. See Tyk Identity Broker for more details.
Create an Identity Management profile in your Dashboard
Log in to your Tyk Dashboard as an Admin user.
Select Identity Management from the System Management menu.
Click Create Profile.
In the Profile action section enter a name for your profile and make sure the Login to Tyk Dashboard option is selected.
Click Next. In the Provider type section, select OpenID Connect.
Click Next. Copy the Client ID value from your Auth0 application > Basic Information and paste it in the Client ID / Key field.
Copy the Client Secret value from your Auth0 application > Basic Information and paste it in the Secret field.
You need to add a Discover URL (well known endpoint). Use the following URL, replacing <<your-auth0-domain>> with the Domain value from your Auth0 application > Basic Information.https://<<your-auth0-domain>>/.well-known/openid-configuration
Copy the Callback URL and paste it into the Allowed Callback URLs field in your Auth0 application > Basic Information.
Click Save Changes to update your Auth0 Application.
Click Create Profile to save your Identity profile in your Tyk Dashboard.
This is a walk-through of how you can use Keycloak and our (internal/embedded) Tyk Identity Broker (TIB) to log in to your Dashboard. This guide assumes you have existing Keycloak and Tyk Pro Environments.
In your desired Realm, create a client of OpenID Connect type, and set your desired Client ID.
Enable client authentication, then save the client.
Retrieve the Secret (from the credentials tab) of the Client you just created. You will need the Client ID and Secret in later steps.
Retrieve the discovery endpoint of the realm, https://<your-keycloak-host-and-realm>/.well-known/openid-configuration.This is accessible from “Realm Settings” > “General” Tab > OpenID Endpoint Configuration. You will need it in later steps.
Log in to your Dashboard and select Identity Management, located under System Management
Create a profile, give it a name and select “Login to Tyk Dashboard”
Set the provider type as “OpenID Connect”
Fill in the Client ID, Client Secret and Discovery URL/endpoint from Keycloak (from steps 3 and 4 in Keycloak’s Side)
Copy the callback URL from Tyk and then you can click “Create Profile” to save the profile.
Go to Keycloak, and paste the callback URL you just copied to “Valid redirect URIs” in the Keycloak Client, and then save the client.This can be accessed by selecting the “Settings” tab when viewing a Keycloak client.
SAML authentication is a way for a service provider, such as the Tyk Dashboard or Portal, to assert the Identity of a User via a third party.Tyk Identity Broker can act as the go-between for the Tyk Dashboard and Portal and a third party identity provider. Tyk Identity broker can also interpret and pass along information about the user who is logging in such as Name, Email and group or role metadata for enforcing role based access control in the Tyk Dashboard.The provider config for SAML has the following values that can be configured in a Profile:SAMLBaseURL - The host of TIB that will be used in the metadata document for the Service Provider. This will form part of the metadata URL used as the Entity ID by the IDP. The redirects configured in the IDP must match the expected Host and URI configured in the metadata document made available by Tyk Identity Broker.FailureRedirect - Where to redirect failed login requests.IDPMetaDataURL - The metadata URL of your IDP which will provide Tyk Identity Broker with information about the IDP such as EntityID, Endpoints (Single Sign On Service Endpoint, Single Logout Service Endpoint), its public X.509 cert, NameId Format, Organization info and Contact info.This metadata XML can be signed providing a public X.509 cert and the private key.CertLocation: An X.509 certificate and the private key for signing your requests to the IDP, this should be one single file with the cert and key concatenated. When using internal identity broker, this value should be the id of the certificate uploaded via certificate manager in dashboard, otherwise it should be a path where the certificate is placed.ForceAuthentication - Ignore any session held by the IDP and force re-login every request.SAMLEmailClaim - Key for looking up the email claim in the SAML assertion form the IDP. Defaults to: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddressSAMLForenameClaim - Key for looking up the forename claim in the SAML assertion form the IDP. Defaults to: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/forenameSAMLSurnameClaim - Key for looking up the surname claim in the SAML assertion form the IDP. Defaults to: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surnameExample profile configuration:
This is an end to end worked example of how you can use LDAP and our Tyk Identity Broker (TIB) to log in to your Dashboard.The Tyk Dashboard is the command and control center of your Tyk installation. It allows users to manage APIs, policies, keys, etc. All of this data is stored in the Dashboard’s MonogDB database, including the user accounts. This works well in a lot of situations as it allows Tyk to be self-contained, but if you already have a centralised system for managing users then you may prefer to use that instead of a separate Tyk-specific database.The Tyk Identity Broker (TIB) is an open-source project which can be used to integrate Tyk authentication with 3rd party identity providers (IDPs). You can use this to enable your Dashboard to authenticate users with your LDAP-powered identity providers such as Active Directory. TIB has been designed as a glue-code solution, so it can integrate with almost any identity provider (IDP). See Tyk Identity Broker Configuration for details on configuring the TIB.
This guide assumes you already have a Tyk environment set up, with a Gateway and Dashboard. If you don’t, please follow the Tyk Self-Managed getting started guide.The environment used for this guide is, for simplicity’s sake, all contained on a single host running Ubuntu 14.04. The hostname my-tyk-instance.com has been set to point at 127.0.0.1. For production environments it is recommended that each component is hosted separately and appropriate security measures are used such as HTTPS to secure connections.All commands shown are run from inside the Tyk host environment.
Download TIBYou can download TIB from the releases page of the TIB repository on GitHub. The release names contain the architecture and version i.e. tib-linux-<architecture>-<version>.tar.gz. This example uses amd64 and 0.2.1 for all the commands, but you should update them to use the latest version and relevant architecture for your platform.First step is to download TIB onto the environment:
Extract and store TIBAs the other Tyk components are installed in your /opt directory, we recommend you install TIB there too:
Copy
Ask AI
tar -xvzf tib-linux-amd64-0.2.1.tar.gz
TIB will now be extracted to the directory tib-0.2.1, let’s move this to /opt and change to that directory:
Copy
Ask AI
sudo mv tib-0.2.1 /optcd /opt/tib-0.2.1
Configure TIBThere are two configuration files for TIB:
tib.conf for the main application configuration settings
profiles.json to configure the profiles which TIB will attempt to authenticate against
Out of the box you don’t need to change much, but there are several attributes you should check to make sure they are correct for your environment:
Secret: The REST API secret used when configuring TIB remotely
TykAPISettings.GatewayConfig.Endpoint: The URL through which TIB can communicate with your Tyk Gateway
TykAPISettings.GatewayConfig.Port: The port through which TIB can communicate with your Tyk Gateway
TykAPISettings.GatewayConfig.AdminSecret: The secret required for TIB to communicate with your Tyk Gateway REST API - must match the secret property in your Gateway’s tyk.conf
TykAPISettings.DashboardConfig.Endpoint: The URL through which TIB can communicate with your Tyk Dashboard
TykAPISettings.DashboardConfig.Port: The port through which TIB can communicate with your Tyk Dashboard
TykAPISettings.DashboardConfig.AdminSecret: The secret required for TIB to communicate with your Tyk Dashboard Admin REST API - must match the admin_secret property in your Dashboard’s tyk_analytics.conf
The tib.conf for this example is as follows (yours might require different values):
Set up the LDAP profileTIB ships with a default profiles.json file which contains many example configuration for different scenarios. This guide is focused on LDAP authentication for the Dashboard, so we will update profiles.json to contain a single profile for this purpose.The key attributes for LDAP profile are:
ID: The ID by which we will activate the profile by calling the appropriate TIB endpoint
OrgId: The organization id which the profile is connected to - make sure this is the correct id for your organization (see the Dashboard Admin API documentation for details on how to retrieve this)
IdentityHandlerConfig.DashboardCredential: The Dashboard API Access credential which is used as authorization header
ProviderConfig.FailureRedirect: The URL which TIB will redirect to if the authentication fails
ProviderConfig.LDAPPort: The port through which TIB can communicate with your LDAP server
ProviderConfig.LDAPServer: The URL through which TIB can communicate with your LDAP server
ProviderConfig.LDAPUserDN: The distinguished name which TIB will use to identify the user - this should be updated to match your LDAP installation and must retain the *USERNAME* token as this is replaced by the actual username at runtime
ReturnURL: The URL which TIB will redirect to if the authentication succeeds - this should be the /tap endpoint of your Tyk Dashboard
The profiles.json for this example is as follows (again, update values for your environment):
Notice that this is a JSON array object with a single element; an LDAP profile. The LDAP server referenced by this profile is the freely-available service provided forumsys.com. See their documentation for more information. You can use any OpenLDAP compatible server.
Start TIBStart TIB by executing the TIB binary. This will produce an output log into the console which you can use to watch TIB process requests. Since TIB looks for the config file in the local directory, you should execute the application from there too.
Copy
Ask AI
cd /opt/tib-0.2.1./tib
If all is well you should see TIB output a few messages when it starts:
Copy
Ask AI
toth/tothic: no SESSION_SECRET environment variable is set. The default cookie store is not available and any calls will fail. Ignore this warning if you are using a different store.INFO[0000] Tyk Identity Broker v0.2INFO[0000] Copyright Martin Buhr 2016DEBU[0000] [MAIN] Settings Struct: {{http://localhost 8080 352d20ee67be67f6340b4c0605b044b7} {http://localhost 3000 12345}}INFO[0000] [MAIN] Initialising Profile Configuration StoreINFO[0000] [IN-MEMORY STORE] InitialisedINFO[0000] [MAIN] Initialising Identity CacheINFO[0000] [REDIS STORE] InitialisedINFO[0000] [FILE LOADER] Loaded: 1 profiles from profiles.jsonINFO[0000] [MAIN] Broker Listening on :3010
Start a new shell session to carry on with the remaining process.
Create a login pageTIB works by having credentials sent to it, so a login page must be made in order to fulfill this requirement. For this example we will create a basic login form hosted by Nginx. We can’t just place the login page in our Dashboard directory as the Dashboard is not a standard web server, it only serves the pages which it has been compiled to serve. Any non-compiled page will produce a 404 response.Install Nginx and start it:
Copy
Ask AI
sudo apt-get install nginxsudo service nginx start
Nginx will now serve pages out of the default web root directory /usr/share/nginx/www. We now need to create a web page there. This command will pipe the echoed text into a file called login.html which is stored in the web root:
The login form contains two inputs named username and password. TIB looks for these exact parameter names when processing the request, so if you are creating your own login page you must use these input names.Please make sure you are using POST method in the form, to avoid browser caching.The form action http://my-tyk-instance.com:3010/auth/1/ldap is the TIB endpoint which will start the authentication process. The URL can be broken down as follows:
http://my-tyk-instance.com: The method and hostname used to connect to TIB - you should use HTTPS to prevent confidential data from being exposed
3010: The default port for TIB
auth: The special TIB endpoint which accepts authentication requests
1: The number of the profile which we are using - matches against the ID property of the profile in profiles.json
ldap: We need to add a string to the end of the request, so we have used ldap here
Update the Dashboard configUpdate the Dashboard config so that any unauthenticated requests are redirected to your custom login page. We do this by updating the sso_custom_login_url property of the Dashboard’s tyk_analytics.conf file, which by default is located in the /opt/tyk-dashboard directory. For example (ommitting all other lines in the config file and trailing comma):
Since the Dashboard runs on port 3000 by default, this URL will use the default HTTP port of 80 which will be handled by Nginx.
Test that it worksNow that we have TIB installed and configured, Nginx installed and hosting our custom login page, and the Dashboard configured to redirect to that login page we can now test the solution. Remember that this example is using the LDAP provided at forumsys.com, so if you are using your own LDAP then substitute the username and password with appropriate values from your system.
Open a web browser (if you’re already logged in to the Dashboard, logout now) and attempt to access the Dashboard - http://my-tyk-instance.com:3000
This should be redirected to the custom login page - http://my-tyk-instance.com/login.html
The LDAP Identity Provider gives you functionality to bind a user to an LDAP server based on a username and password configuration. The LDAP provider currently does not extract user data from the server to populate a user object, but will provide enough defaults to work with all handlers.
The only step necessary to perform this is to send a POST request to the LDAP URL.TIB can pull a username and password out of a request in two ways:
Two form fields called “username” and “password”
A basic auth header using the Basic Authentication standard form
By default, TIB will look for the two form fields. To enable Basic Auth header extraction, add "GetAuthFromBAHeader": true to the ProviderConfig section.The request should be a POST.If you make this request with a valid user that can bind to the LDAP server, Tyk will redirect the user to the dashboard with a valid session. There’s no more to it, this mechanism is pass-through and is transparent to the user, with TIB acting as a direct client to the LDAP provider.
The LDAPUserDN field MUST contain the special *USERNAME* marker in order to construct the users DN properly.
The configuration below will take a request that is posted to TIB, authenticate it against LDAP, if the request is valid, it will redirect to the Tyk Gateway OAuth clients’ Redirect URI with the token as a URL fragment:
LDAP requires little configuration, we can use the same provider configuration that we used to log into the Dashboard to target the Portal instead - notice the change in the handler configuration and the return URL:
In some cases validation of a user CN is not enough, and it requires verifying if a user match some specific rules, like internal team ID. In this case TIB provides support for doing additional LDAP search check, and if result of this search returns only 1 record, it will pass the user.To make it work you need to specify 3 additional attributes in profile configuration file:
LDAPBaseDN - base DN used for doing LDAP search, for example cn=dashboard,ou=Group
LDAPFilter - filter applied to the search, should include the *USERNAME*variable. For example: ((objectCategory=person)(objectClass=user)(cn=*USERNAME*))
LDAPSearchScope - This specifies the portion of the target subtree that should be considered. Supported search scope values include: 0 - baseObject (often referred to as “base”), 1 - singleLevel (often referred to as “one”), 2 - wholeSubtree (often referred to as “sub”)
For additional information about LDAP search protocolExample profile using LDAP search filters:
The proxy identity provider is a generic solution to more legacy problems, as well as a way to handle flows such as basic auth access with third party providers or OAuth password grants where the request can just be passed through to the providing endpoint to return a direct response.The proxy provider will take a request, proxy it to an upstream host, capture the response, and analyze it for triggers of “success”, if the triggers come out as true, then the provider will treat the request as authenticated and hand over to the Identity Handler to perform whatever action is required with the user data.Success can be triggered using three methods:
Response code: e.g. if this is an API request, a simple 200 response would suffice to act as a successful authentication.
Response body exact match: You can have a base64 encoded body that you would expect as a successful match, if the two bodies are the same, then the request will be deemed successful.
Regex: Most likely, the response might be dynamic (and return a response code, timestamp or other often changing parameter), in which case you may want to just match the response to a regex.
These can be used in conjunction as gates, e.g. a response must be 200 OK and match the regex in order to be marked as successful.
The Proxy provider can do some clever things, such as extract JSON data from the response and decode it, as well as pull username data from the Basic Auth header (for example, if your identity provider supports dynamic basic auth).
The configuration below will proxy a request to http://{TARGET-HOSTNAME}:{PORT}/ and evaluate the response status code, if the status code returned is 200 then TIB will assume the response is JSON ("ResponseIsJson": true) to extract an access token (e.g. if this is an OAuth pass-through request) and try and find an identity to bind the Dashboard user to in the user_name JSON field of the response object ("UsernameField": "user_name"):
Load the certificate with the private key into Tyk:
For embedded TIB in Dashboard: Use Tyk Dashboard’s certificate manager. In the below image you can see the module in dashboard that allows to upload certificates:
For standalone TIB: Store the certificate as a file accessible to Tyk
Load the public key into your IdP for ID token encryption (process varies by IdP)
Configure the Identity Provider
Create a new client in your IdP for Tyk Identity Broker
While setting up JWE with Tyk Identity Broker, you may encounter some challenges. This section outlines common issues and their solutions to help you navigate the implementation process smoothly.
oauth2: error decoding JWT token: jws: invalid token received, not all parts available it means that JWE is not enabled in the profile and the IDP is already using JWE.
JWE Private Key not loaded Tyk encountered some issues while loading the certificate with the private key. Ensure that the path or certId are correct.
As illustrated in the screen below the following information must be provided:
You can select the scopes you would like your request to include. By default, Tyk will provide the connectid scope, anything additional must be requested.
