[JIRA] (JENKINS-60736) Add posibility to obtain SAML assertion after login using SAML plugin

0 views
Skip to first unread message

habdank@gmail.com (JIRA)

unread,
Jan 10, 2020, 1:19:04 PM1/10/20
to jenkinsc...@googlegroups.com
Seweryn Habdank-Wojewodzki created an issue
 
Jenkins / New Feature JENKINS-60736
Add posibility to obtain SAML assertion after login using SAML plugin
Issue Type: New Feature New Feature
Assignee: Ivan Fernandez Calvo
Components: saml-plugin
Created: 2020-01-10 18:18
Environment: Linux RedHat, SAML Plugin 1.1.4, Jenkins 2.204.1.
Priority: Major Major
Reporter: Seweryn Habdank-Wojewodzki

Dears,

 

After login to Jenkins using SAML plugin user may perform some actions like preparing automatic deployment after build or calling some other tools over the REST APIs, but those actions (tools) require authentication (e.g. in form of valid SAML assertion).

The feature would be to give build tasks access to SAML assertion e.g. via temporary created environment variable, how it is done for build name or build ID and bunch of others.

How it would be possible to implement?
Perhaps we can provide some implementation proposal, but we shall agree on feature design.

 

Best regards,

Seweryn.

 

Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo

kuisathaverat@gmail.com (JIRA)

unread,
Jan 10, 2020, 5:12:03 PM1/10/20
to jenkinsc...@googlegroups.com
Ivan Fernandez Calvo commented on New Feature JENKINS-60736
 
Re: Add posibility to obtain SAML assertion after login using SAML plugin

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.

kuisathaverat@gmail.com (JIRA)

unread,
Jan 10, 2020, 5:12:03 PM1/10/20
to jenkinsc...@googlegroups.com
Ivan Fernandez Calvo closed an issue as Won't Do
 
Change By: Ivan Fernandez Calvo
Status: Open Closed
Resolution: Won't Do

habdank@gmail.com (JIRA)

unread,
Jan 10, 2020, 6:14:02 PM1/10/20
to jenkinsc...@googlegroups.com
Seweryn Habdank-Wojewodzki commented on New Feature JENKINS-60736
 
Re: Add posibility to obtain SAML assertion after login using SAML plugin

OK. I understand 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.
SVN plugin exposes SVN credentials in this ways as well - there is variable, which contains them.

habdank@gmail.com (JIRA)

unread,
Jan 10, 2020, 6:15:01 PM1/10/20
to jenkinsc...@googlegroups.com
OK. I understand 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.
SVN plugin exposes SVN credentials in this ways as well - there is variable, which contains them.

habdank@gmail.com (JIRA)

unread,
Jan 14, 2020, 1:12:06 PM1/14/20
to jenkinsc...@googlegroups.com
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.

kuisathaverat@gmail.com (JIRA)

unread,
Jan 15, 2020, 3:53:08 AM1/15/20
to jenkinsc...@googlegroups.com

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])"

habdank@gmail.com (JIRA)

unread,
Jan 15, 2020, 1:18:08 PM1/15/20
to jenkinsc...@googlegroups.com

Thank 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.

habdank@gmail.com (JIRA)

unread,
Jan 15, 2020, 1:18:08 PM1/15/20
to jenkinsc...@googlegroups.com
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.

habdank@gmail.com (JIRA)

unread,
Jan 15, 2020, 1:18:12 PM1/15/20
to jenkinsc...@googlegroups.com
Thank you for the answer.

First of all on Linux I can even more simplify the command to { color:red} { { env}} {color} to get all variables and to { color:red} { { set}} {color} 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.

kuisathaverat@gmail.com (JIRA)

unread,
Jan 15, 2020, 1:56:02 PM1/15/20
to jenkinsc...@googlegroups.com

>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.

kuisathaverat@gmail.com (JIRA)

unread,
Jan 15, 2020, 1:57:03 PM1/15/20
to jenkinsc...@googlegroups.com
>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 {code} * env {code} * and {code} * set {code} * 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.
Reply all
Reply to author
Forward
0 new messages