search

vmware / open-vm-tools

Official repository of VMware open-vm-tools project
http://sourceforge.net/projects/open-vm-tools/
2.24k stars 426 forks source link

VGAuthService SAML xml Schema bug #623

Open altinsoft opened 1 year ago

altinsoft commented 1 year ago

Describe the bug

Vcenter version : 7 or 8

Vmware tool Running, version : 12320

Vm GuestOS : Windows Server 2022

With the SAML token that I received through the STSService service We use the StartProgramInGuest function.

But there is an error in the vmware tools VGAuthService service log records.

[2022-11-09T10:29:27.536Z] [ message] [VGAuthService] requestType: 10(VALIDATE_SAML_BEARER_TOKEN REQ) [2022-11-09T10:29:27.536Z] [ message] [VGAuthService] username 'Administrator' [2022-11-09T10:29:27.536Z] [ message] [VGAuthService] validate Only 'FALSE' [2022-11-09T10:29:27.536Z] [ warning] [VGAuthService] XML Error: Element '{urn:oasis:names:tc:SAML:2.0:assertion}Condition', attribute '{http://www.w3.org/2001/XMLSchema-instance}type': The QName value '{http://www.rsa.com/names/2009/12/std-ext/SAML2.0}RenewRestrictionType' of the xsi:type attribute does not resolve to a type definition. [2022-11-09T10:29:27.536Z] [ warning] [VGAuthService] XML Error: Element '{urn:oasis:names:tc:SAML:2.0:assertion}Condition': The type definition is abstract. [2022-11-09T10:29:27.536Z] [ warning] [VGAuthService] Failed to validate token against schema [2022-11-09T10:29:27.536Z] [ message] [VGAuthService] Returning error message '<?xml version="1.0" encoding="UTF-8" ?><reply><sequenceNumber>1</sequenceNumber><errorCode>12</errorCode><errorMsg>validateSamlToken failed</errorMsg></reply>' [2022-11-09T10:29:27.536Z] [ message] [VGAuthService] ServiceProtoDispatchRequest: processed reqType 10(VALIDATE_SAML_BEARER_TOKEN REQ), returning 0 on connection 3

resim

Reproduction steps

1. 2. 3. ...

Expected behavior

fixed.

Additional context

Same problem from linux, (Ubuntu 20)

resim

lemke1458 commented 1 year ago

VGAuthService thinks the token doesn't match the official schema.

Where did this token come from? Did anything modify it long the way? We've seen issues where code tries to take the token as a string coming from an SSO server and converts it to an language-specific XML datastructure, and when its converted back to a string, the metadata is changed. The unmodified string from the SSO server is what should be used in the GuestAuthentication.

We haven't tested much against anything but the VMware SSO server or our test SAML tokens, but those should work fine.

altinsoft commented 1 year ago

VGAuthService thinks the token doesn't match the official schema.

Where did this token come from? Did anything modify it long the way? We've seen issues where code tries to take the token as a string coming from an SSO server and converts it to an language-specific XML datastructure, and when its converted back to a string, the metadata is changed. The unmodified string from the SSO server is what should be used in the GuestAuthentication.

We haven't tested much against anything but the VMware SSO server or our test SAML tokens, but those should work fine.

Saml token comes directly from SSO server. What is the error here? Please help me. @lemke1458

resim

resim

altinsoft commented 1 year ago

Example Token : @lemke1458

<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="_ae30af86-d683-40c1-bff2-242df60b4d52" IssueInstant="2022-11-11T07:07:44.492Z" Version="2.0"><saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://10.0.0.2/websso/SAML2/Metadata/vsphere.local</saml2:Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" /><ds:Reference URI="#_ae30af86-d683-40c1-bff2-242df60b4d52"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="xsd xsi" /></ds:Transform></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" /><ds:DigestValue>ZKsZ4+ZG4riFMDfXBn3EOnmtqeU462ewiC8ttgWVL54=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>K/8piqVtuZ9gUrq2y7eJa5ikfOQS5HMJp9/XEjl1p/Ag5YKD2+Qx+ThGo3VqG3Ugpc+c5GdC1aYYa4woj9zoyhYJhNRZoe0CAWH9KH3cYmqyyLAO6sDNk/ch6oCPvjMC4/RHI/F1niRbR7J1WSIlYP01+XTZYRuijMBip+7nX6HnFNjGPRxSynET8w7bpxd02INw2M114tKCVBON+nC7Be6BUkY0rSTNCLx7u3gVod/D5qcAEeGKCBZN31ybbl+BLK+M2kb/3btmGUg6sYAMydl/aPRRgZm7KYvI/VAeeIN+NyscOWxJ6/5zWe4Vuj6pj3MvjLNe62Huw86pIDPC8w==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIIEKTCCAxGgAwIBAgIJAO5fSSoaEAYrMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQDDAJDQTEXMBUGCgmSJomT8ixkARkWB3ZzcGhlcmUxFTATBgoJkiaJk/IsZAEZFgVsb2NhbDELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExEjAQBgNVBAoMCWxvY2FsaG9zdDEbMBkGA1UECwwSVk13YXJlIEVuZ2luZWVyaW5nMB4XDTIyMDcxNDE5NTMzMloXDTI0MDcxMzE5NTMzMlowXzEMMAoGA1UEAwwDU1RTMQswCQYDVQQGEwJEUzEPMA0GA1UECAwGVk13YXJlMQ8wDQYDVQQHDAZWTXdhcmUxDzANBgNVBAoMBlZNd2FyZTEPMA0GA1UECwwGVk13YXJlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoaIfC20Ov94494UisDFnDcOsdY3+gAgtdf+b95lLz0Qm0gpQoYc/fVY11zbxygehGuOoQ8dId2eCRC0rvdalXAgZnY+N1SXN0MKP1VdskogDmGRMVW36BLMCYG76hWBhTCleBO5cJ5bn7U+G3VSVgjeGHQLQbI4plnDfSDxd4G8pZk6AUbbzl9TeqAdXQvcjHBlyBfxd6/6qTIesYwlqonvAL9HnM6/bq/30J8e9H6XERCWRKQDrnCE6pYSPI/1Z+xsJ/wXjMmTxN/HsryWvu9pyo/TnwGxMIK0F1x2ZuxhfTOGbGLgXLAtcHiN0Pnre6tgofPWJpZJtfnJVfN1MMQIDAQABo4G1MIGyMAsGA1UdDwQEAwIF4DApBgNVHREEIjAggQ5lbWFpbEBhY21lLmNvbYcECgAAW4IIMTAuMC4wLjIwHQYDVR0OBBYEFM3lLEXC3T4E+a7pjKyVMmuvx+dFMB8GA1UdIwQYMBaAFPtGsh/tGQMTPMMScp5aUdNC7C4hMDgGCCsGAQUFBwEBBCwwKjAoBggrBgEFBQcwAoYcaHR0cHM6Ly8xMC4wLjAuMi9hZmQvdmVjcy9jYTANBgkqhkiG9w0BAQsFAAOCAQEAcPHQ+tcAZHAQPoCsTuCOVVtbRYGa97kiwQ0F1jzvtwsCYuJMHM8uvYXS3bGsEfVsFcZNQ7goDsmyujOX7zYutkGuUwlNQ2Y/5qiWHXCE5SjvFgh2BEHDhmngnfyxZ7jVXf2N8rWOC9vELg7feMF5AF3M0Wfr3p3ylOPWu4SJ6iN3AIfibradGDIfjyUnJhMgB5JTB6gbXWWaMpuuYT4Z73yT8XjWYvw/OcXSOvrfRnImwgjPWHbJoEACU4z0c2WTr87dWt0x23XTJ4fvjwdkEOHrMqYvu30KPthOS0eQyE/hH3U5+7XRv9J+DOPMvz7CUUyWUHhaPoYwdTJKraZNjg==</ds:X509Certificate><ds:X509Certificate>MIIECzCCAvOgAwIBAgIJAOD5oZMAx93qMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQDDAJDQTEXMBUGCgmSJomT8ixkARkWB3ZzcGhlcmUxFTATBgoJkiaJk/IsZAEZFgVsb2NhbDELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExEjAQBgNVBAoMCWxvY2FsaG9zdDEbMBkGA1UECwwSVk13YXJlIEVuZ2luZWVyaW5nMB4XDTIyMDcxMTE0Mzc0OVoXDTMyMDcwODE0Mzc0OVowgZAxCzAJBgNVBAMMAkNBMRcwFQYKCZImiZPyLGQBGRYHdnNwaGVyZTEVMBMGCgmSJomT8ixkARkWBWxvY2FsMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTESMBAGA1UECgwJbG9jYWxob3N0MRswGQYDVQQLDBJWTXdhcmUgRW5naW5lZXJpbmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+UHVPQxrYIC++TWMFd7dnb69qEpW0NnUAEmwM6FCoNdek874psFXdsix0dxCuzujL2X3CcTvMV09BtlPdDqDZbCG+QqcfnFNvit4OD5Ux89LMvVxoLpFn67h7CdAMc30Ng1A+IzXUeTv06ETb0H0DeQOs5gJgGEjXaUyNs/n2GUIDmZjlLxCNOhDOgOVRaaOI6M1rkve/MlTzMILkRD0vu72kwWnmqgO3+7CBKyxgY4EcqU3WhCOU4jNhX7kZDBhBUsiEmLSigwBHiuTn5JE01gFPUfzlCuROaffP6WSqqRyvfFK7XzMPgBIPJai1Uc73e/aIGCSuff9qUZf8OAyzAgMBAAGjZjBkMB0GA1UdDgQWBBT7RrIf7RkDEzzDEnKeWlHTQuwuITAfBgNVHREEGDAWgQ5lbWFpbEBhY21lLmNvbYcEfwAAATAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADANBgkqhkiG9w0BAQsFAAOCAQEAmFzXTwXAILSfhrjCtHAGVqFjnMmHEdxEOks02nP+2OWXdHgmXUEPe5Xgqb/E6d5TNGmgnomG84e9GVJTUSR+m1azwAyf1QeFNPXbGjyRI41mCKDFgJiMcn8k9tHoPQDnS9Q7Byv6kA92PuCyN4zQOOHiQO4QJbsQqcDweQq1GohMhBndgzDL0Wkcpg3JSb7csFN3+MZi4Z8gHu6de75dzZJCH1DDbbU1cMKV09qlrY3IjxyBeGZce2k7ySW83ETUolkJVbL6Wsj/I/5RBOqAD1Q1LB7zl79eMeBgUojJZhwouFayjvZxGWzmA9ufdvMLAKOxcW/kCqb7M4JX5IWQ/w==</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><saml2:Subject><saml2:NameID Format="http://schemas.xmlsoap.org/claims/UPN">Administrator@VSPHERE.LOCAL</saml2:NameID><saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml2:SubjectConfirmationData NotOnOrAfter="2022-11-11T07:22:44.323Z" /></saml2:SubjectConfirmation></saml2:Subject><saml2:Conditions NotBefore="2022-11-11T07:07:44.323Z" NotOnOrAfter="2022-11-11T07:22:44.323Z"><saml2:ProxyRestriction Count="10" /><saml2:Condition xmlns:rsa="http://www.rsa.com/names/2009/12/std-ext/SAML2.0" Count="10" xsi:type="rsa:RenewRestrictionType" /></saml2:Conditions><saml2:AuthnStatement AuthnInstant="2022-11-11T07:07:44.490Z"><saml2:AuthnContext><saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef></saml2:AuthnContext></saml2:AuthnStatement><saml2:AttributeStatement><saml2:Attribute FriendlyName="Subject Type" Name="http://vmware.com/schemas/attr-names/2011/07/isSolution" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml2:AttributeValue xsi:type="xsd:string">false</saml2:AttributeValue></saml2:Attribute><saml2:Attribute FriendlyName="surname" Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml2:AttributeValue xsi:type="xsd:string">vsphere.local</saml2:AttributeValue></saml2:Attribute><saml2:Attribute FriendlyName="givenName" Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml2:AttributeValue xsi:type="xsd:string">Administrator</saml2:AttributeValue></saml2:Attribute><saml2:Attribute FriendlyName="Groups" Name="http://rsa.com/schemas/attr-names/2009/01/GroupIdentity" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml2:AttributeValue xsi:type="xsd:string">vsphere.local\Users</saml2:AttributeValue><saml2:AttributeValue xsi:type="xsd:string">vsphere.local\Administrators</saml2:AttributeValue><saml2:AttributeValue xsi:type="xsd:string">vsphere.local\CAAdmins</saml2:AttributeValue><saml2:AttributeValue xsi:type="xsd:string">vsphere.local\SystemConfiguration.BashShellAdministrators</saml2:AttributeValue><saml2:AttributeValue xsi:type="xsd:string">vsphere.local\SystemConfiguration.ReadOnly</saml2:AttributeValue><saml2:AttributeValue xsi:type="xsd:string">vsphere.local\SystemConfiguration.SupportUsers</saml2:AttributeValue><saml2:AttributeValue xsi:type="xsd:string">vsphere.local\SystemConfiguration.Administrators</saml2:AttributeValue><saml2:AttributeValue xsi:type="xsd:string">vsphere.local\LicenseService.Administrators</saml2:AttributeValue><saml2:AttributeValue xsi:type="xsd:string">vsphere.local\Everyone</saml2:AttributeValue></saml2:Attribute></saml2:AttributeStatement></saml2:Assertion>

lemke1458 commented 1 year ago

You're not showing how the token is used, but since your token fetching function is returning SamlToken object, instead of the actual string, it seems very likely that you may be rebuilding (serializing) the token as a string, which we've seen cause problems before.

altinsoft commented 1 year ago

You're not showing how the token is used, but since your token fetching function is returning SamlToken object, instead of the actual string, it seems very likely that you may be rebuilding (serializing) the token as a string, which we've seen cause problems before.

usage command here, @lemke1458

`{ SamlToken Saml = GetSamlBearerToken("https://" + VcenterIP + "/sts/STSService", VcenterUser, VcenterPassword); string SessionID = LoginSamlToken(VcenterIP, Saml); Console.WriteLine("Session ID : " + SessionID); Console.WriteLine("TokenSaml : " + Saml.TokenString);

var payload = new ProcessesCreate.Root();

var credentials = new ProcessesCreate.Credentials();
credentials.interactive_session = false;

credentials.user_name = "root";
credentials.saml_token = Saml.TokenString;
credentials.type = "SAML_BEARER_TOKEN";

var spec = new ProcessesCreate.Spec();
spec.start_minimized = false;

// Linux usage
spec.arguments = "root:123456-- | chpasswd";
spec.path = "/usr/bin/echo";
spec.working_directory = "/root";

// Windows usage
// spec.arguments = "user administrator Arc123--"
// spec.path = "C:\Windows\SysWOW64\net.exe"
// spec.working_directory = "C:\"

payload.spec = spec;
payload.credentials = credentials;
string payloadJson = JsonConvert.SerializeObject(payload);
var client = new RestClient("https://" + VcenterIP);
ServicePointManager.ServerCertificateValidationCallback = new Func<bool>(() => true);
client.Timeout = 3600000;
client.ReadWriteTimeout = 3600000;
var request = new RestRequest("/api/vcenter/vm/vm-15119/guest/processes?action=create", Method.POST);
request.AddHeader("vmware-api-session-id", SessionID);
request.AddParameter("application/json", payloadJson, ParameterType.RequestBody);
IRestResponse response = client.Execute(request);
Console.WriteLine("Result Json   : " + response.Content);
Console.ReadLine();

} `

lemke1458 commented 1 year ago

Compare the Saml.TokenString you're using above with the data you dumped when it came from the SSO server. They have to be the same; I suspect they're not because instead of using the value as a String, you've put it into an object that may not deserialize int the same value.

I also see you're using the REST variant of the API here, so I hope you've already properly configured the AliasStore (which current cannot be done via REST), or that will be the next thing you struggle with.

SAML tokens as guest authentication require extra configuration; you cannot simply use an SSO token from the vSphere user space in the guest user space.

altinsoft commented 1 year ago

Compare the Saml.TokenString you're using above with the data you dumped when it came from the SSO server. They have to be the same; I suspect they're not because instead of using the value as a String, you've put it into an object that may not deserialize int the same value.

I also see you're using the REST variant of the API here, so I hope you've already properly configured the AliasStore (which current cannot be done via REST), or that will be the next thing you struggle with.

SAML tokens as guest authentication require extra configuration; you cannot simply use an SSO token from the vSphere user space in the guest user space.

I don't think it has anything to do with what you're talking about. The problem seems to be a bug with vmware tools. Unable to parse XML. I guess there is a problem with the XML schema. Because with this saml token, I can do many transactions without any problems. @lemke1458 @liuqi @dyno @matt-royal

vmware Tools error logs,

resim

PaTHml commented 1 year ago

Alright, lets start with the XML schemas.

VGAuth's packaged and installed XML schemas files can be found on the guest: On Linux: /etc/vmware-tools/vgauth/schemas/

On Windows: C:\Program Files\VMware\VMware Tools\VMware VGAuth\schemas

Unless I missed it, I don't see any "RenewRestrictionType" defined in the packaged schemas.

The schemas packaged with VMware Tools and open-vm-tools have not changed in quite a few years (decade?) and are (as far as I know) unchanged from the defaults for SAML bearer tokens.

So the question from @lemke1458 regarding what is the SSO server needs a more specific answer:

All we can say at this time is what ever XML is sent to VGAuth for validation is out of spec.

Since we're not seeing this issue internally, we'll need details on the SSO configuration to reproduce. Until we have a repro to work from all we can do is browse code to try and find where the "RenewRestrictionType" gets introduced in the mix.

and thanks to @mtsvetanov for the hint on the SDK, language and bindings in use in the pasted code.

altinsoft commented 1 year ago

Alright, lets start with the XML schemas.

VGAuth's packaged and installed XML schemas files can be found on the guest: On Linux: /etc/vmware-tools/vgauth/schemas/

On Windows: C:\Program Files\VMware\VMware Tools\VMware VGAuth\schemas

Unless I missed it, I don't see any "RenewRestrictionType" defined in the packaged schemas.

The schemas packaged with VMware Tools and open-vm-tools have not changed in quite a few years (decade?) and are (as far as I know) unchanged from the defaults for SAML bearer tokens.

So the question from @lemke1458 regarding what is the SSO server needs a more specific answer:

* Is the VCenter SSO integrated with something like Active Directory or similar service?

* Any custom policy involved that would result in the "RenewRestrictionType" element being added to the XML.

All we can say at this time is what ever XML is sent to VGAuth for validation is out of spec.

Since we're not seeing this issue internally, we'll need details on the SSO configuration to reproduce. Until we have a repro to work from all we can do is browse code to try and find where the "RenewRestrictionType" gets introduced in the mix.

and thanks to @mtsvetanov for the hint on the SDK, language and bindings in use in the pasted code.

1-) Vcenter SSO System Domain - vsphere.local (It is not integrated with Active Directory or other services.) 2-) "RenewRestrictionType" This definition is available in Vcenter xml schemas. We did not add. @PaTHml

PaTHml commented 1 year ago

I'm wondering if the issue stems from the usage of RenewingType() class when trying to get a token issues in GetSamlBearerToken().

I'm not familiar with the vmware-automation-sdk-java.

The code shared above differs from the sample found in that project. https://github.com/vmware/vsphere-automation-sdk-java/blob/master/src/main/java/vmware/samples/sso/SsoHelper.java

Mainly the RenewingType instance attributes configuration.

mtsvetanov commented 1 year ago

The SAML token pasted above looks good to me actually.

The usage of SamlToken from the vsphere-automation-sdk-for-java to parse the XML and serialize it back shouldn't be a problem. It has been designed for that, in case one needs to perform local validation or access properties and attributes of the token.

The piece of the token that is rejected 

  <saml2:Condition xmlns:rsa="http://www.rsa.com/names/2009/12/std-ext/SAML2.0"
                   Count="10"
                   xsi:type="rsa:RenewRestrictionType"/>

Looks like something typical for SAML tokens issued by vCenter SSO service.

What is a bit suspicious is that it reads like the token is renewable, but the code shared above seems to be asking for the opposite while issuing the token, with

renewingType.Allow = false; renewingType.OK = true;

as documented here: https://developer.vmware.com/apis/34/vcenter-sso/doc/GUID-C9385AB9-6E94-4BEA-85C9-2A2FFF72EF18.html

( Note that you should NOT be using true on the second line )

So, indeed it seems that VGAuthService is rejecting what looks like a valid token. BTW, you can also validate it against the vCenter SSO server by using the Validate method documented here: https://developer.vmware.com/apis/34/vcenter-sso/doc/GUID-62E14DC5-F43C-4F8A-8538-46ABC47D2F8F.html

It might be that VGAuthService indeed lost the schema for this type from the RSA namespace, or maybe it never had it and has a requirement for using non-renewable tokens only (or whatever it means when the first snippet I pasted above is not present in the token).

lemke1458 commented 1 year ago

Yes, VGAuthService is using the official standard XML schemas from OASIS (https://wiki.oasis-open.org/security/FrontPage).

The RenewRestrictionType assertion doesn't seem to be part of the SAML standard; I've never seen it before (or at least never seen this failure), and we've been testing against the VMware SSO service for many years.

The URL in the RenewRestrictionType assertion (which returns a 404) suggests that perhaps this is (was?) an RSA extension to SAML, but google only finds a couple references.

altinsoft commented 1 year ago

The SAML token pasted above looks good to me actually.

The usage of SamlToken from the vsphere-automation-sdk-for-java to parse the XML and serialize it back shouldn't be a problem. It has been designed for that, in case one needs to perform local validation or access properties and attributes of the token.

The piece of the token that is rejected

  <saml2:Condition xmlns:rsa="http://www.rsa.com/names/2009/12/std-ext/SAML2.0"
                   Count="10"
                   xsi:type="rsa:RenewRestrictionType"/>

Looks like something typical for SAML tokens issued by vCenter SSO service.

What is a bit suspicious is that it reads like the token is renewable, but the code shared above seems to be asking for the opposite while issuing the token, with

renewingType.Allow = false; renewingType.OK = true;

as documented here: https://developer.vmware.com/apis/34/vcenter-sso/doc/GUID-C9385AB9-6E94-4BEA-85C9-2A2FFF72EF18.html

( Note that you should NOT be using true on the second line )

So, indeed it seems that VGAuthService is rejecting what looks like a valid token. BTW, you can also validate it against the vCenter SSO server by using the Validate method documented here: https://developer.vmware.com/apis/34/vcenter-sso/doc/GUID-62E14DC5-F43C-4F8A-8538-46ABC47D2F8F.html

It might be that VGAuthService indeed lost the schema for this type from the RSA namespace, or maybe it never had it and has a requirement for using non-renewable tokens only (or whatever it means when the first snippet I pasted above is not present in the token).

renewingType.Allow = false; renewingType.OK = false;

We tried, the result did not change. Same problem. Note that the problem is in c#, there is no problem in java code.

mtsvetanov commented 1 year ago

We tried, the result did not change. Same problem. Note that the problem is in c#, there is no problem in java code.

@altinsoft, do you mean that you can do the same worfklow with Java and it works just fine?

When Java is used, does the token have the following (which is causing the trouble):

<saml2:Condition xmlns:rsa="http://www.rsa.com/names/2009/12/std-ext/SAML2.0" Count="10" xsi:type="rsa:RenewRestrictionType"/>

altinsoft commented 1 year ago

yes. It works fine in java code. "rsa:RenewRestrictionType" does not exist in the java code.

https://github.com/vmware-archive/vsphere-automation-sdk-.net/blob/e04396cdd716360bf01fd83cafe905deaab5b2aa/vmware/samples/common/SamplesCommon/SsoHelper.cs#L40

When the example here is used, incorrect saml token is returned. The xml data returned has "rsa:RenewRestrictionType". @mtsvetanov @lemke1458 @PaTHml @liuqi

altinsoft commented 1 year ago

I guess nobody knows the solution to this problem. :(