govmomi: Holder-of-Key: govc: ns0:FailedCheck: Signature is invalid

When issuing a Holder-of-Key token, with delegated Bearer token identity via govc the following error occurs:

govc: ns0:FailedCheck: Signature is invalid

The command that is causing the error is as follows:

hokToken=$(govc session.login -cert user.crt -key user.key -issue -token "$bearerToken")

This error has started to occur since updating to vCenter Appliance 6.7 Update 3b (6.7.0.42000), but continues to work on vCenter Appliance 6.7 U2 6.7.0.30000.

Versions

  • govc v0.22.0 (also tested with a few older versions with the same issue)
  • vCenter Appliance 6.7 Update 3b 6.7.0.42000 (The one with the issue)
  • vCenter Appliance 6.7 U2 6.7.0.30000 (The one without the issues)

Replicating the Issue See below a set of scripts for testing this issue: govc-tests.zip

  • create-user.sh - creates a solution user
  • token-test.sh - gets a bearer token for a user, followed by a HOK token with the delegated bearer token identity and then tries to login with the HOK token and use it.
  • logs - folder containg the outputs of the scripts for the two versions of vCenter listed above

Findings At present I am a bit lost, as the release notes for VCSA lack the details needed. One difference I can see is a change of XML prefix for bearer tokens, changing from xs in 6.7 U2 to xsd in 6.7 U3b.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 15 (9 by maintainers)

Commits related to this issue

Most upvoted comments

No worries, diffing tools (Fork) did most of the brunt.

Keep up the hard work! The team and I are big fans of govmomi and govc!

@matthewmfrost the type prefix change you called out was indeed the problem. That was clear after I figured out the related logging (with debug enabled for dsig) is in a different location.

#1792 should work for you against 6.7u3 - but I also need to go back and adjust so it’ll work with older versions of vCenter too.

I didn’t make further changes, the bearer token in my case was that of Administrator@vsphere.local Didn’t realize you needed ActAs, in that case disregard the workaround attempt and I’ll continue to pursue the proper fix.

Indeed, OpenSAML update is the culprit, and something we’ll have to fix on the govmomi side. I’m looking at this now.

@matthewmfrost thank you for the details and scripts to reproduce. I will take a closer look early this week and at the very least we can start by adding some docs for the workaround you found.