MFA on org level

[seymen]

Hi guys

I got feedback from one customer saying that the plugin doesn't work if mfa is enabled for the whole org.

Do you have any test cases for that? Support can enable MFA for an entire org for you.

[Beads1980]

We are seeing different behaviour if MFA is enabled at the personal account level, and at the org level.

Even though my Apigee account has MFA enabled, I can deploy via the maven plugin without providing any MFA token (or hitting the management APIs directly).

However, if MFA is enabled at the org level, deployments, understandably, fail without providing the token.

Not providing MFA tokens suits us, as we have bigger issues if we need to provide tokens for deployments. I will list them in a seperate message for clarity.

[Beads1980]

If we each individually enable MFA on our accounts, it does not stop people being able to deploy. However, if we enable at the Org level (via an Apigee request ticket), then a MFA token is required for Maven to perform the deployment. This poses us a few issues:

• The tokens are short lived. The deployment could easily fail as the token expires. The plugin does limit the likelihood of this happening by utilising the validate phase, but it can still happen.

• We can use another tool and process for generating tokens. However, this requires knowing the seed/shared secret value. This effectively defeats the purpose of MFA and it becomes another password. If we want to go down this route, it has 2 more issues:

1. Have a global deployment user that everyone uses for deployments, and use a few different libraries for generating the MFA token and plug into Maven/Jenkins. We lose auditing of who did the actual promotion this way, and we would have a shared password for the deployment user.
2. Use the new libraries for generating tokens, and people deploy as themselves. Everyone would need to remember their 16 digit seed value that doesn’t expire, effectively it becomes another password and because it is long everyone would write their own one down.

• While the Maven plugin does support MFA, but it wasn’t working for us (it was connecting to MFA service, but was receiving a 501). I suspect this is an internal proxy server issue and headers are being stripped out, needs more investigation on our side.

[ssvaidyanathan]

@Beads1980 - Thanks for the info. Sorry for getting back late. Not sure if the issue is resolved

If the org is not enabled with MFA but the user has enabled, the user can still continue to use basic auth with the plugin as that still works but when MFA is enabled at the org level, then the basic auth will not work which forces you to use the OAuth flow with the plugin.

Since the MFA token expires before, the best thing to do is to generate the OAuth access token initially using the API or using get_token utility.

Once you have the OAuth access/refresh tokens, you can pass them as arguments to the maven plugin as mentioned here. These tokens have a ttl of 30 mins which I assume should be long enough for the job. If you need more than that, then the refresh token is used by the plugin to generate another token to continue with the Mgmt API calls.

With this token, Mgmt server knows whose calling the API and all of that gets audited as usual. So you can know who did the deployment in this case.

You can probably have a separate job that generates the token for you first and then pass that to the actual deployment job

Please try this (if not already) and let me know if you need any info.

NOTE: Please use the latest version (1.1.5)

Apologize again for the delayed response.

[msadasivam]

a) human like; privileged account; manually triggered deployments Configure an app like Google authenticator to support MFA. A developer picks the code from the app and feeds it to deploy.

b) bot like; deployment account; automated deployments The deployment account is generic so the MFA's shared secret does behave like a password. The idea is to use an account with lower privileges and use it only for deployments. You can use the "Description" tag in the bundle xml to capture the SCM user to increase audit info. The plugin populates this field with interesting info when it is not present. PackageConfigurer.java