SAML plugin does not manage anything on builds, it only makes the authentication and authorization part, that's it. The token provided by the IdP is in the browser of the user, expose it directly as an environment variable is a security issue. So the only implementation for your use case is a plugin that grabs the token from the browser and creates a credential in the user namespace with the value, then you can select this credential as a parameter for your jobs, thus this something that does not fit on the SAML plugin.

OK. I see your opinion, but I do not understand it.

We saw all tokens in logs on the server, so I am not sure, why it cannot be visible in form of environment variable. And also it means that SAML assertions have not only scope in the browser, but they are really existing on the server in scope of build job.

Every build job exposes some bunch of temporal/local data in form of environment variable.
Also SVN plugin exposes SVN credentials in this ways as well - there is variable, which contains them.

I would be very thankful, if you can elaborate why it is security issue.

I do not want to enter on details, I will give you a code to leak any environment variable you have on your jobs, this will workaround the mask on the logs and expose any sensitive information you have in an environment variable by putting a whitespace between characters ('123456' -> '1 2 3 4 5 6'), not think if it could be a security issue in your organization or not, in many it is.

python -c "print ' '.join('${ENV_VAR}'[::1])"

Thank you for the answer.

First of all on Linux I can even more simplify the command to env to get all variables and to set on Window.
There are exactly all variables in the scope of the build. There is no SAML assertion.

Could you consider option (checkbox), which would allow to export SAML assertion into set of environment variables,
so the Jenkisn administrator would decide to present variables or in other companies not.
I agree, that default value would be not to expose assertion as environment variable.

>First of all on Linux I can even more simplify the command to env to get all variables and to set on Window.

I would expect at least you use credentials to define those secrets as environment variables if you do in that way env and set would not expose those env vars https://support.cloudbees.com/hc/en-us/articles/203802500-Injecting-Secrets-into-Jenkins-Build-Jobs

>Could you consider option (checkbox), which would allow to export SAML assertion into set of environment variables,
so the Jenkisn administrator would decide to present variables or in other companies not.

Inject environment variables on jobs it is completely out of the scope of this plugin, if you want you can create a new plugin that makes only this, inject the SAML assertion in builds.