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:
The Python API:
An Auth example with Python is here:
The session object is defined here:
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):
I think the flow for this plugin would be:
- 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.
- If the ID Extractor has a cache miss, it runs the middleware
- The middleware assumes the request is a SAML envelope and processes it
- If valid, the middleware crafts a Session Object based on the assertions (Access control, rate limit, quota) and returns it
- The ID extractor, if configured, will store this session object in the session store on your behalf
- 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).