Create support for username-password passing without tag value limitations

[walsw]

What feature do you want to see added?

Create support for username-password passing without tag value limitations.
Now the DOMAIN\username syntax, common for NetBIOS notation is impossible to store in secret manager as the username is stored as a tag value pair, preventing the use of backslash (''). If username was stored as secrets value, that would not be a limitation.
We currently cannot use the plugin to store our Checkmarx username-password as we mandate it is AD authenticated (We now have to create the Jenkins native username/password to allow our username to be prefixed with the domainname\ )

Upstream changes

No response

[chriskilding]

Depending on how your AD auth is set up, you may be able to use the new username@domain syntax for the username instead of the DOMAIN\username syntax.

I know this works for general sign-in if your organization uses Azure AD, so I think it should work for what you are trying to do with Checkmarx as well. (I don't know how traditional on-premise AD would behave if given a new-style username.)

Give this a go and let me know if it works

[walsw]

Had already tried the @Domain notation. That is allowed in tag value, but Checkmarx doesn't understand it. It probably verifies it against local database as an username looking like email address. In the windows world they often get treated as equivalents, but they are not. The DOMAIN\username is an (older) notation based of NetBios (which can be disabled). Where the username@fqdn domain notation is a UPN notation. Possible to map a user against multiple domains. regardless of this, it would be better to keep the username as a secret from a security perspective. Tags are unencrypted and less protected from prying eyes than secrets. Knowing a valid username is half the battle when you try to brute force access by guessing username-password combinations.

[chriskilding]

It sounds like the first port of call is to raise this with Checkmarx, to get a definitive answer on how Checkmarx handles user@domain usernames. They may well decide that there is a bug that needs fixing. Could you provide more details about which specific Checkmarx products or components you are using with your Jenkins job? (That will indicate whether we need to raise a GitHub Issue on the relevant repo, or send an email to Checkmarx support.)