Support for SAML 2.0?

Hi all,

We need to integrate with an IDP which today only supports stateful sessions via SAML2.

Any ideas if this is (going to be) supported?

Many thanks – Robin

Hi Robin,

This has been on the roadmap for a very long time, but no date has been set yet for work to start.

However, instead of waiting for us to create a middleware, it might be faster to use oir Rich Plugins functionality to create a custom auth middleware plugin to validate a SAML envelope?

Cc @matiasb (our resident plugin expert!)

Hi Martin,

That sounds like a solution – just missing some background knowledge about “session management” in Tyk to fully understand the direction you are pointing me into…

With SAML 2.0 the SP (API gateway here) retrieved upon initial request the SAML envelope with assertions. Based on the assertions a “session” (?) needs to be created on the SP to identify subsequent requests as being authenticated.

What does Tyk set (a session cookie??) in order to identify these subsequent requests and how does it handle then session replication to other Tyk instances here?

Feel free to refer me to the docs with an RTFM remark :wink:

Best – Robin

Hi Robin,

The gateway only needs a Session Object to reference for the lifetime of the request (and future ones).

I think SAML works in a similar way to OIDC, as in the endpoint receives a SAML envelope with assertions, those assertions are validated with an IDP, and then the assertions are granted access.

(The docs for this are in a bit of state, we are in the process of cleanup as we speak)

So the relevant things to note here are, you will need, the middleware docs:

https://tyk.io/tyk-documentation/customise-tyk/plugins/rich-plugins/rich-plugins-work/
https://tyk.io/tyk-documentation/customise-tyk/plugins/rich-plugins/python/tutorial-add-demo-plugin-api/

The Python API:

https://tyk.io/tyk-documentation/customise-tyk/plugins/rich-plugins/python/tyk-python-api-methods/

An Auth example with Python is here:

The session object is defined here:

https://tyk.io/tyk-documentation/tyk-rest-api/tyk-session-objects-details/

We have a very handy feature called the ID Extractor, which is executed before the auth middleware (in Go), it will try to find a unique identifier for the user in the request (this can be defined by you as a header, form element, xpath or regex), this then becomes the base for a unique session token for this user (it is generative as a property of the request, so no configuration or change needs to be made by you):

https://tyk.io/tyk-documentation/customise-tyk/plugins/auth-plugins/

I think the flow for this plugin would be:

  1. ID Extractor looks for a header token or some other form-data (I don’t think we have a cookie check yet) to find a unique identifier for this user, if it finds one, it tries to see if there is already a session object in place for this user and processes that.
  2. If the ID Extractor has a cache miss, it runs the middleware
  3. The middleware assumes the request is a SAML envelope and processes it
  4. If valid, the middleware crafts a Session Object based on the assertions (Access control, rate limit, quota) and returns it
  5. The ID extractor, if configured, will store this session object in the session store on your behalf
  6. Next time a request like this comes around, the ID Extractor will bypass the validator unless the session object has expired and been deleted.

I think it should be totally feasible, and we’d be keen to work together on getting a SAML middleware set up (please note you are not bound to Python here, you could also use one of the gRPC bindings).

Wow – thanks Martin! This should answer my question (more complete then hoped for).

Thanks!

1 Like