You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Here are some key observations to aid the review process:
⏱️ Estimated effort to review: 4 🔵🔵🔵🔵⚪
🧪 No relevant tests
🔒 Security concerns
Sensitive information exposure: The documentation includes example secrets, tokens, and configuration values that resemble real credentials. While these are likely for demonstration, they should be clearly marked as placeholders to prevent accidental use in production. Additionally, the use of HTTP in example URLs for authentication endpoints may encourage insecure deployments; HTTPS should be strongly recommended for all authentication flows.
There are several typographical errors in tags and descriptions (e.g., "SS0" instead of "SSO", "Profies" instead of "Profiles", "Provder" instead of "Provider", "MonogDB" instead of "MongoDB", "ommitting" instead of "omitting"). These could impact searchability, user comprehension, and professionalism of the documentation.
title: "Single Sign On (SS0) with LDAP"
date: 2025-01-10
tags: ["Tyk Identity Broker", "TIB", "Identity Provider", "Identity Handler", "SSO", "Custom Authentication", "Custom Proxy Provder", "SAML", "OIDC", "OpenID Connect", "Profies", "IDPs", "Social Provider" ,"LDAP"]
description: "Learn how to integrate external services with Tyk API Gateway. Discover how to use middleware plugins, webhooks, and service discovery to extend your API functionality and connect with third-party systems."
keywords: ["Tyk Identity Broker", "TIB", "Identity Provider", "Identity Handler", "SSO", "Custom Authentication", "Custom Proxy Provder", "SAML", "OIDC", "OpenID Connect", "Profies", "IDPs", "Social Provider" ,"LDAP"]
Example configurations and instructions use real-looking credentials, secrets, and endpoints (e.g., "352d20ee67be67f6340b4c0605b044b7", "bb5735026be4400e67ed9801c2f1e2f9", "12345"). These should be clearly marked as placeholders or replaced with obvious dummy values to avoid accidental reuse in production.
"Secret": "352d20ee67be67f6340b4c0605b044b7", "HttpServerOptions": { "UseSSL": false, "CertFile": "./certs/server.pem", "KeyFile": "./certs/server.key" }, "BackEnd": { "Name": "in_memory", "ProfileBackendSettings": {}, "IdentityBackendSettings": { "Hosts" : { "localhost": "6379" }, "Password": "", "Database": 0, "EnableCluster": false, "MaxIdle": 1000, "MaxActive": 2000 } }, "TykAPISettings": { "GatewayConfig": { "Endpoint": "http://localhost", "Port": "8080", "AdminSecret": "352d20ee67be67f6340b4c0605b044b7" }, "DashboardConfig": { "Endpoint": "http://localhost", "Port": "3000", "AdminSecret": "12345" } }}```#### Create Profile1.**Set up the LDAP profile**
TIB 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]({{< ref "api-management/dashboard-configuration#organizations-api" >}}) 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):
```{.copyWrapper} [ { "ActionType": "GenerateOrLoginUserProfile", "ID": "1", "OrgID": "59bfdf5b56c02c065d24638e", "IdentityHandlerConfig": { "DashboardCredential": "bb5735026be4400e67ed9801c2f1e2f9" },
The documentation recommends using SSL for production but provides HTTP URLs in examples and does not emphasize the importance of securing sensitive endpoints (e.g., login forms, callback URLs). This could lead to insecure deployments if users follow the examples verbatim.
4. Add the following URL (modify for your domain) to the "Authorized redirect URIs" section: `http://tib-hostname:TIB-PORT/auth/{PROFILE-ID}/gplus/callback`#### Create an OAuth Client in Tyk Dashboard
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.
```{.copyWrapper}{ "ActionType": "GenerateOAuthTokenForClient", "ID": "3", "IdentityHandlerConfig": { "DashboardCredential": "{DASHBOARD-API-ID}", "DisableOneTokenPerAPI": false, "OAuth": { "APIListenPath": "{API-LISTEN-PATH}", "BaseAPIID": "{BASE-API-ID}", "ClientId": "{TYK-OAUTH-CLIENT-ID}", "RedirectURI": "http://{APP-DOMAIN}:{PORT}/{AUTH-SUCCESS-PATH}", "ResponseType": "token", "Secret": "{TYK-OAUTH-CLIENT-SECRET}" } }, "MatchedPolicyID": "567a86f630c55e3256000003", "OrgID": "53ac07777cbb8c2d53000002", "ProviderConfig": { "CallbackBaseURL": "http://{TIB-DOMAIN}:{TIB-PORT}", "FailureRedirect": "http://{PORTAL-DOMAIN}:{PORTAL-PORT}/portal/login/?fail=true", "UseProviders": [{ "Key": "GOOGLE-OAUTH-CLIENT-KEY", "Name": "gplus", "Secret": "GOOGLE-OAUTH-CLIENT-SECRET" }] }, "ProviderConstraints": { "Domain": "", "Group": "" }, "ProviderName": "SocialProvider", "ReturnURL": "", "Type": "redirect"}
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.
Log into Dashboard with Google
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:
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
sharadregoti
changed the title
User description
Preview Link
Checklist
New Contributors
master.PR Type
Documentation
Description
Adds comprehensive SSO documentation for LDAP, OIDC, SAML, and Social IDPs.
Introduces new dedicated SSO documentation pages for each provider.
Updates navigation menu to organize SSO options under Identity Management.
Provides step-by-step guides and configuration examples for each SSO method.
Changes walkthrough 📝
single-sign-on-ldap.md
Add detailed SSO with LDAP documentation and guidestyk-docs/content/api-management/single-sign-on-ldap.md
troubleshooting.
single-sign-on-oidc.md
Add comprehensive SSO with OIDC documentationtyk-docs/content/api-management/single-sign-on-oidc.md
(OIDC).
single-sign-on-saml.md
Add SSO with SAML documentation and configuration guidetyk-docs/content/api-management/single-sign-on-saml.md
single-sign-on-social-idp.md
Add SSO with Social Identity Providers documentationtyk-docs/content/api-management/single-sign-on-social-idp.md
menu.yaml
Update menu to include new SSO documentation sectionstyk-docs/data/menu.yaml
Management.