.
-->
Use a tool to intercept the web requests between your browser ant the cloudstack UI (our pentester used "burp"). Login to cloudstack using a SSO account (SAML).
Now, you're logged in successfully to your cloudstack domain. 
Logout from cloudstack.

Now, log in again to cloudstack, but with the "interceptor" active. In the request, delete the whole saml-signature and change the username to another SSO user from within another tenant.
Run the modified request, and you're logged in into this foreign account.

<!-- Paste example playbooks or commands between quotes below -->
~~~

~~~

<!-- You can also paste gist.github.com links for larger files -->

##### EXPECTED RESULTS
<!-- What did you expect to happen when running the steps above? -->
User can't log in into foreign tenant
~~~

~~~

##### ACTUAL RESULTS
<!-- What actually happened? -->
User can log in into foreign tenant
<!-- Paste verbatim command output between quotes below -->
~~~

~~~
<issue_comment>username_1: @username_5 @username_2 Guys, this looks like a pretty nasty security bug. SAML isn't used by default, but regardless this may be a blocker for 4.15 and 4.14.x.
<issue_comment>username_2: @username_1 yes let's discuss and understand how the env was setup, I suspect it may related to env configuration.

@username_0 can you share details of your IDP setup? For example the IDP xml metadata, what IDP server are you using (Shibboleth, keycloak etc). Usually, the SP (CloudStack acts as a service provider in SAML terminology) is not in control of whether the SAML token is encrypted or not, and signing and encryption is enforced by the IDP server. For best practices, IDP servers generally should enforce that both signing and encryption be done and (authn) tokens be signed and encrypted (when this is done correct we should see an encryption and sining public key in the IDP metadata xml, for example https://samltest.id/saml/idp). I think only if encryption is not enforced you'll be able to read/extract/change the token parameters, can you try to enforce encryption in your IDP and try your attack/test again? In case that works then we certainly have a blocker.

CloudStack's SAML support (SP) was implemented and tested against Shibboleth and you may use https://samltest.id/ to test the setup. For doc ref: http://docs.cloudstack.apache.org/en/latest/adminguide/accounts.html#using-a-saml-2-0-identity-provider-for-user-authentication
<issue_comment>username_2: cc @username_3 @username_5
<issue_comment>username_2: I did a quick code investigation, looks like when there is no encryption in place we get the unencrypted username (`uid` usually) parameter from the SAML token: (if I recall correctly this was done only to allow and test unsecure IDP servers)
https://github.com/apache/cloudstack/blob/master/plugins/user-authenticators/saml2/src/main/java/org/apache/cloudstack/api/command/SAML2LoginAPIAuthenticatorCmd.java#L241

... however, I'm not sure if changing the whole SAML token/response should fail at https://github.com/apache/cloudstack/blob/master/plugins/user-authenticators/saml2/src/main/java/org/apache/cloudstack/api/command/SAML2LoginAPIAuthenticatorCmd.java#L232 which was signed by a signature?

However, if the SAML IDP server has encryption enforced (see for example https://wiki.shibboleth.net/confluence/display/IDP30/SecurityConfiguration#SecurityConfiguration-SigningandEncryptionEnablement) we get the username from the encrypted assertion value:
https://github.com/apache/cloudstack/blob/master/plugins/user-authenticators/saml2/src/main/java/org/apache/cloudstack/api/command/SAML2LoginAPIAuthenticatorCmd.java#L289
<issue_comment>username_2: I guess we need exact steps of reproduction if encryption and signing are both enabled. In which case, @username_0 can you email me privately on rohit AT apache.org? Thanks.

I ran a quick test, this server is SAML enabled: http://primate-qa.cloudstack.cloud:8080/client/master 

![Screenshot from 2020-12-04 22-21-20](https://user-images.githubusercontent.com/95203/101191111-43224d00-367f-11eb-8c4b-3fce6f43e548.png)

I tracked both SAML request and response. SAML request (base64 encoded) was encrypted so couldn't decode it, SAML response (base64 encoded) was not but I see the username attribute is not plaintext in the XML as encryption in enforced:

```
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:Response Destination="http://primate-qa.cloudstack.cloud:8080/client/api?command=samlSso" ID="_12f9925a270fb1652e82e635fa6fde35" InResponseTo="uk3foqohiipf3948r0gn2tavbdgo1gsc" IssueInstant="2020-12-04T16:50:45.549Z" Version="2.0" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"><saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://samltest.id/saml/idp</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="#_12f9925a270fb1652e82e635fa6fde35"><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#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><ds:DigestValue>Ru6R2nqZCGs532STdqd5alLYCOxgMooNlfww1JWVR4U=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>FKUtzP59Vht1Pd77s9jW0KejzbG1m6B2txUyVOi3Y1ioTAg1Xvy/VvxNui8u9G6mVV4s1n5l/gFDGi5v2SIN7YcxH+yX9GJ1TW8XX1WJqxtiDFgGbm+KL8DHeVgyc8kJmAC1zOMRUKOy7arvWc42KmhilAumXbS5oo0qwfnvjNmyhzGQW+lZcMcd/K3eE6ZvdsetRToWlXpnzwKuBqy1iZfZZpxKwgKhBtXDTwCltJjH97FOGP7G9epJH/sfNir/970oNzr+y3TXYL2uDoQKVP5SYOzBPtRvUBR4+qcY0SLIsSNn7X9iXMgKAr2GPfgNMG7zgP4F14ElErYlPiBGgA==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIIDEjCCAfqgAwIBAgIVAMECQ1tjghafm5OxWDh9hwZfxthWMA0GCSqGSIb3DQEBCwUAMBYxFDAS
BgNVBAMMC3NhbWx0ZXN0LmlkMB4XDTE4MDgyNDIxMTQwOVoXDTM4MDgyNDIxMTQwOVowFjEUMB