Here at Tyk we’re committed to your needs. We consider every suggestion you throw at us, validate feedback we receive from a business and technology standpoint, and then add the feasible, necessary and exciting onto our product roadmap.
Identity, Security and Single-Sign-On (SSO) was one such feature. We were asked about implementing SSO with Tyk a few times in quick succession, so it swiftly became something to address ASAP, and for all our users.
Whether it’s our Enterprise Multi-Data-Centre API Management or the open source API Gateway, we wanted our SSO feature to be available to all who using Tyk – so we got speaking to a whole load of you!
After getting in touch with a cross-section of our community using different set-ups and requirements, we identified 3 main themes: you wanted SSO, you wanted Role-Based-Access Control (RBAC), and you wanted Multi-factor Authentication (MFA).
We got to work!
Requirements gathering and research
At Tyk this phase is never simple, though always enjoyable! We have 3 versions of our API management platform (Cloud, Hybrid, and On-Premises), which all have different customisation levels and typical users. We believe in creating as many API management features as we can for all our users where possible, not just limiting features to subset, so this means our requirements gathering and research stage is always wide-ranging and complex.
As expected we found a mixture of insights, use cases, and requirements from you all…
- Some use a pure LDAP (with different implementations like Active Directory and OpenLDAP)
- Some use third-party Identity providers (IDPs) such as Ping, Okta, KeyCloak, Gluu, and Auth0
- Some use a mix of the above
- Some have regulations against using anything in the Cloud, so rely on everything being On-Prem
- Some of you want to use your permission groups on corporate directories when logging into the Dashboard i.e. role-based-access-control (RBAC)
- Some want to be able to enable MFA for the Dashboard and Developer Portal.
As you can see, the requirements were wide and complex: to come up a with solution that could meet the needs of all in the first iteration would be a challenge. For this reason, we worked as a team to define a roadmap that would intend to meet all requirements in an iterative and practical way.
Our roadmap for bringing SSO to Tyk
Step 1: Bringing you an MVP of SSO and permissions (released in v2.4)
Our first task was to define what would be our minimum viable product (MVP) for SSO and setting permission levels on login, a precursor to RBAC.
We wanted to get something out to you super-speedily, and our SSO MVP, outlined below, would enable you to configure SSO via LDAP, do a custom login page redirect, and set permissions for users logging in via config file.
It was far from the complete package, but this MVP would enable a large proportion of you to start configuring SSO, quickly and easily. From here we could iterate to provide more functionality in the future.
Our MVP was:
-
- Add support for LDAP search – this enables customers to not only log users by login and password, but first filter their search scope by any given filter – allowing to filter by team, its permissions and etc.
- Ability to add a custom login page – to enable the SSO to work you must set up a custom login page to direct the user authorisation through TIB. We added this to our Dashboard in v2.4 release.
- Set permissions for users logging in via SSO – In true open source fashion, one of our users contributed the code to make this work. We are very grateful for this and always welcome pull requests 🙂
With the above, you could set up basic SSO and permissions for login to the Tyk Dashboard and Developer Portal, via an endpoint in TIB (Tyk-Identity-Broker) using LDAP. You can view the guides for setting this up here in our docs.
Step 2: Integrate IDPs with Tyk (released in v2.5)
From our research we also knew that many of you were using third-party IDPs such as Okta, Ping, Centrify, Auth0, Azure AD, Gluu, and KeyCloak, to take care of all of your identity management across your software. Many were also using multiple third-party IDPs within the same organisation.
Our goal to was to support as many as possible of these, which would in turn enable our users to add SSO and MFA on Tyk (if the IDP supported these).
Our task here was:
- Add support for any OpenID Connect (OpenID) provider to integrate with TIB to setup SSO – This would enable our customers to integrate any IDP (that supports OpenID) with Tyk, using OpenID.
This update to Tyk Identity Broker (TIB) is live now, so you can start setting up your integration (check our guide to Tyk API Management with Okta and Tyk API Management with Google login).
Step 3: Expand on SSO with the Dashboard Admin API (released in v2.5)
Tyk Identity Broker (TIB) internally uses a special Tyk Dashboard Admin API, which was never actually documented. When we realised this missing piece and added the documentation, we saw a wave of creative direct integrations with our SSO API, such as integrations using the SAML provider using nginx, and some lua scripting. In addition some of you came up with great suggestions on how to improve it, like solving role-based access, including this user suggestion.
View the documentation for Tyk Dashboard Admin API
Step 4: Add support for SAML (in progress)
SAML is a standard that is used by lots of large corporations, that also came up during our customer research. As such we will look to support this as part of the roadmap of SSO.
View and track the progress of SAML Authorisation ticket on GitHub
Step 5: Role-access control functionality – configure RBAC via API (coming in 2.6)
In addition to SSO, the ability to create/link roles with permission levels is something that a huge number of you have told us that you want in the Dashboard and Developer Portal.
This feature is helpful when you have large teams and you want to control access to the Tyk Dashboard, or display different API catalogues and actions to developers on the Developer Portal.
Our planned roadmap for this feature is to roll out a simple role-based-access control system where users can create and assign roles, with the permissions you see now in the Dashboard.
A further iteration to this will be the ability to add more granular permission levels, such as API ownership and ability to view API definitions, but not edit them.
We are interested to build out more requirements on this, so please follow the progress and contribute to this feature on our backlog.
We can’t improve Tyk without you
We want to thank everyone that has helped us during the requirements gathering phase, there will be lots more to come!
Speaking of, have you joined our Research panel? Sign up to our research panel to be involved in future activities, and win rewards for getting involved.
Hopefully this post has given you some insight into our product development at Tyk. We would always welcome more feedback around SSO, MFA and RBAC, so if this is something you want to help shape going forward, or you have some requirements that are missing, please comment on the epic or learn more about Tyk’s API management platform.
