Why after a SAML authentication I have an "auth code not found" error?

viola.mauro

I have an application in FusionAuth, which uses a python script to validate a user's login.
The script works without problems.
At this stage I also wanted to implement SAML authentication (using ADFS): I used the official FusionAuth tutorials, leaving any unspecified options at their default values (I say this because the problem I have could be solved with a simple setting that I don't know).
Then on the login page the "login with saml" section appears, clicking on it appears the ADFS login page ( <baseurl>/adfs/ls? SAMLRequest = jZJba9 ....), entering the domain credentials I see that the process continues: I think there is at least one intermediate redirect (as there should be) and finally I land on my python script which, however, refuses me.
It rejects me in the sense that the client_response.was_successful value of this statement
client_response = client.exchange_o_auth_code_for_access_token (authCode, redirectURL, applicationID, clientSecret)
has value false, with the following reason:

{'error': 'invalid_request', 'error_description': 'Invalid Authorization Code', 'error_reason': 'auth_code_not_found'}

I see that after authentication, the domain user (registered for this FusionAuth application) is created among the users present in FusionAuth, I therefore believe that I am at a good point and that there are no particular problems in the SAML phase.
If I authenticate a local user, everything works.

What am I doing wrong? Is getting a nonexistent authCode normal? If so, how should I perform the login verification?
I looked around for a while but found nothing ...

Thank you.

viola.mauro

Update 1.

I found an oddity.
The user that is automatically created in FusionAuth after logging in via SAML has the email address that was set in the active directory but the username is empty.
So I tried to set the username (the same as the email) and if I now try to authenticate via SAML everything works.
At this point I think that the problem is the Claim Rules in ADFS, but I confirm that I have scrupulously followed what is reported here:
https://fusionauth.io/docs/v1/tech/identity-providers/samlv2/adfs

now check again. if in the meantime there are new ideas ...

dan

What version of the python library are you using? Recently the order of parameters changed.

Here's a bug discussing it: https://github.com/FusionAuth/fusionauth-python-client/issues/7

And here are the release notes documenting the change: https://fusionauth.io/docs/v1/tech/release-notes#version-1-19-0

viola.mauro

Hello.
yes, I am aware of the change in the order of the parameters.
the problem is not that, in fact if I try to log in with a local user the script works.
furthermore, after setting the username (to the user created by saml authentication) everything works.

dan

Ah, great. A few questions so I can do some more research:

Do you see any messages in the logs or the event log which are related?
What version of FusionAuth are you running?

viola.mauro

Fusionauth is 1.19.6
And no, in the log there aren't warning. At the logon I see this:

SAMLv2 IdP Start Debug Log 10/2/2020 03:45:21 PM CEST Generated a one time use SAML Request Id [id8c2168b91f6046509694420ff4c3d630]

and the next event is:

SAML v2 IdP Response Debug Log for [Contoso 2016] with Id [4d4dfe29-25e7-49b8-80a4-f35f88bafddb]

10/2/2020 03:45:32 PM CEST Parse the SAML response
10/2/2020 03:45:32 PM CEST Base64 encoded response:
PHNhbWxwOlJlc3BvbnNlIElEPSJfZGYxOGJhM2ItZTFhMi00ODU5LWIxOTUtYjVjOTczMWUyNWZiIiBWZXJzaW9uPSIyLjAiIElzc3VlSW5zdGFudD0iMjAyMC0xMC0wMlQxMzo0NTozMi43NjNaIiBEZXN0aW5hdGlvbj0iaHR0cHM6Ly8xOTIuMTY4LjE0NC4xMzM6OTAxMy9zYW1sdjIvYWNzIiBDb25zZW50PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6Y29uc2VudDp1bnNwZWNpZmllZCIgSW5SZXNwb25zZVRvPSJpZDhjMjE2OGI5MWY2MDQ2NTA5Njk0NDIwZmY0YzNkNjMwIiB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIj48SXNzdWVyIHhtbG5zPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXNzZXJ0aW9uIj5odHRwOi8vU3J2MjAxNi5jb250b3NvLmxvY2FsL2FkZnMvc2VydmljZXMvdHJ1c3Q8L0lzc3Vlcj48c2FtbHA6U3RhdHVzPjxzYW1scDpTdGF0dXNDb2RlIFZhbHVlPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6c3RhdHVzOlN1Y2Nlc3MiIC8+PC9zYW1scDpTdGF0dXM+PEFzc2VydGlvbiBJRD0iXzFlNWZhN2E3LTE3ODItNGU5Yi05MTRlLWUxMjIwOWUzZjBmYSIgSXNzdWVJbnN0YW50PSIyMDIwLTEwLTAyVDEzOjQ1OjMyLjc2M1oiIFZlcnNpb249IjIuMCIgeG1sbnM9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iPjxJc3N1ZXI+aHR0cDovL1NydjIwMTYuY29udG9zby5sb2NhbC9hZGZzL3NlcnZpY2VzL3RydXN0PC9Jc3N1ZXI+PGRzOlNpZ25hdHVyZSB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+PGRzOlNpZ25lZEluZm8+PGRzOkNhbm9uaWNhbGl6YXRpb25NZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzEwL3htbC1leGMtYzE0biMiIC8+PGRzOlNpZ25hdHVyZU1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZHNpZy1tb3JlI3JzYS1zaGEyNTYiIC8+PGRzOlJlZmVyZW5jZSBVUkk9IiNfMWU1ZmE3YTctMTc4Mi00ZTliLTkxNGUtZTEyMjA5ZTNmMGZhIj48ZHM6VHJhbnNmb3Jtcz48ZHM6VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3BlZC1zaWduYXR1cmUiIC8+PGRzOlRyYW5zZm9ybSBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMTAveG1sLWV4Yy1jMTRuIyIgLz48L2RzOlRyYW5zZm9ybXM+PGRzOkRpZ2VzdE1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jI3NoYTI1NiIgLz48ZHM6RGlnZXN0VmFsdWU+MEZPOE9QV2NENXh3U01oSzJ6YnUydDFPcnRrVjVwZTBJYm1VSExVbWFxbz08L2RzOkRpZ2VzdFZhbHVlPjwvZHM6UmVmZXJlbmNlPjwvZHM6U2lnbmVkSW5mbz48ZHM6U2lnbmF0dXJlVmFsdWU+RmI1WFhPd3VQVTh5bm0rWnNseFVwNmJUbjdlZFMzeDBnMm1QUk9BUFFXOFJyWUlMSG40dEhaRStLc1NqL1B4ek95ZG5tZldOU0prVnAyeVk1YXJndGNkZkxONWpjUDBXVkhGbWRLYVhqOVZ5cUZaeVNkVU93cnM2aHB0K2RhSkdWWlZkUGMvMTFGR2dTT2dLUDhRQllCUHU2V00vOGh2OUNXK0xUNDJUZThWb3VvMENGSjN1L29rbVJvV29QMTI5eG1HeE5kMVhoN2EvUGZZOEYyRFJCSk5acVcwWE9WeFZyOFF1SnRmWWxyNWdIczZHQ25IU0pzdWZYV1JTVnNOKzVqdnhMQ1J0anpHR3RhZDZWT3VoeFAyZlViYXkzOW80SGVJbm90UFpEemlhN1h0U3A3WkxWM04yKzUyd0tiZTlhN2NtcnZyMzNiUGVRZVcwckFld3dBPT08L2RzOlNpZ25hdHVyZVZhbHVlPjxLZXlJbmZvIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIj48ZHM6WDUwOURhdGE+PGRzOlg1MDlDZXJ0aWZpY2F0ZT5NSUlDNWpDQ0FjNmdBd0lCQWdJUUdRMytSNEtUS0psQTJjSHgvMDlyUHpBTkJna3Foa2lHOXcwQkFRc0ZBREF2TVMwd0t3WURWUVFERXlSQlJFWlRJRk5wWjI1cGJtY2dMU0JUY25ZeU1ERTJMbU52Ym5SdmMyOHViRzlqWVd3d0hoY05NakF4TURBeU1EazFOelF3V2hjTk1qRXhNREF5TURrMU56UXdXakF2TVMwd0t3WURWUVFERXlSQlJFWlRJRk5wWjI1cGJtY2dMU0JUY25ZeU1ERTJMbU52Ym5SdmMyOHViRzlqWVd3d2dnRWlNQTBHQ1NxR1NJYjNEUUVCQVFVQUE0SUJEd0F3Z2dFS0FvSUJBUURVaWN6L1d3NCt4aC90TjJKTHh2T21QbTdncGpRYTZwSHNEVERDZ2Vhd3JvWW54dEo0N2pCVGdmelRmbGdZTDdrdmE1K3RKVGFFUFdOeFlPL3Q3NXV4bkFudENrWXJyYjFDNStrV29JQmdISFdWQkgrWTJVZE00Vjk5VFhJSUVnTnJuVWxtcklySExGdHhCQWU1UkxiKzhWeVp5S3oxeUZhT3h5VXF0YUtUZ1drdVM5VjU2dDFxb0NuQkdXWEIrb1RabzREMFFEMkRxMVFMYXBzOUhFNEtmRjZpcGJPa3hKdmRrVDVaa1RLcmg3N1ZUZ0w5U3lVSGE0UkZzSWlXMUt1c25zbzNwTy9lSmNHY1JoZVhrd0RkRnhsRzZ1R0VuOWN6eHNQbGl4MXhDd1NFV2xhVm1HQTNKVjYrUFdEK2JLNFA3VlVGZ01kazNVUE5zNnhORGdWdkFnTUJBQUV3RFFZSktvWklodmNOQVFFTEJRQURnZ0VCQUhIeHhLZEJ6MVZVYzdLZlp2bW1hRUVsc1paVlZBZm8wb0R5RFhkMmw1alJOOGVSdEU5aWdYQW5rRTZBTVBjWFl4bVYxTlRNa2xWbFhTMG51OExqRHM1VlBOZC9raS9mQnNpUUk3dEFoVUUrelEvejZaVkRJd2ZQSGF2eEh2bTY2Qyt4b0JzUnc0ZUk3WjhwQ2o2dXhYYTQvU0VzS291UmJmUU5MbWJjMlRKY24rbzZnMW5xMjl1VGhWVDhrVHE5L3BWKzdzbUN6R1ZUNitnTGgrY2lSVmVxMUx0VzIxaW16KzBpRXVwWjVEREhraHBIaHJYUWJzaGduNkpjdnFYVDdJUytjbXJXVDJMZjFnRVRvNVhhdVJHeTBlN2d4UzVTZWVvQmo0YjRBcWppZ2Z4UEFibHc4YkxYYjR1ZHdkMHJFUlE3dzNiMHV0aE81ejFrdnd2eWhTND08L2RzOlg1MDlDZXJ0aWZpY2F0ZT48L2RzOlg1MDlEYXRhPjwvS2V5SW5mbz48L2RzOlNpZ25hdHVyZT48U3ViamVjdD48TmFtZUlEIEZvcm1hdD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6MS4xOm5hbWVpZC1mb3JtYXQ6ZW1haWxBZGRyZXNzIj5tYXVyby52aW9sYUBjb250b3NvLmxvY2FsPC9OYW1lSUQ+PFN1YmplY3RDb25maXJtYXRpb24gTWV0aG9kPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6Y206YmVhcmVyIj48U3ViamVjdENvbmZpcm1hdGlvbkRhdGEgSW5SZXNwb25zZVRvPSJpZDhjMjE2OGI5MWY2MDQ2NTA5Njk0NDIwZmY0YzNkNjMwIiBOb3RPbk9yQWZ0ZXI9IjIwMjAtMTAtMDJUMTM6NTA6MzIuNzYzWiIgUmVjaXBpZW50PSJodHRwczovLzE5Mi4xNjguMTQ0LjEzMzo5MDEzL3NhbWx2Mi9hY3MiIC8+PC9TdWJqZWN0Q29uZmlybWF0aW9uPjwvU3ViamVjdD48Q29uZGl0aW9ucyBOb3RCZWZvcmU9IjIwMjAtMTAtMDJUMTM6NDU6MzIuNzQ4WiIgTm90T25PckFmdGVyPSIyMDIwLTEwLTAyVDE0OjQ1OjMyLjc0OFoiPjxBdWRpZW5jZVJlc3RyaWN0aW9uPjxBdWRpZW5jZT5odHRwczovLzE5Mi4xNjguMTQ0LjEzMzo5MDEzL3NhbWx2Mi9zcC80ZDRkZmUyOS0yNWU3LTQ5YjgtODBhNC1mMzVmODhiYWZkZGI8L0F1ZGllbmNlPjwvQXVkaWVuY2VSZXN0cmljdGlvbj48L0NvbmRpdGlvbnM+PEF0dHJpYnV0ZVN0YXRlbWVudD48QXR0cmlidXRlIE5hbWU9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3dzLzIwMDUvMDUvaWRlbnRpdHkvY2xhaW1zL2VtYWlsYWRkcmVzcyI+PEF0dHJpYnV0ZVZhbHVlPm1hdXJvLnZpb2xhQGNvbnRvc28ubG9jYWw8L0F0dHJpYnV0ZVZhbHVlPjwvQXR0cmlidXRlPjwvQXR0cmlidXRlU3RhdGVtZW50PjxBdXRoblN0YXRlbWVudCBBdXRobkluc3RhbnQ9IjIwMjAtMTAtMDJUMTM6NDU6MzIuNzE3WiIgU2Vzc2lvbkluZGV4PSJfMWU1ZmE3YTctMTc4Mi00ZTliLTkxNGUtZTEyMjA5ZTNmMGZhIj48QXV0aG5Db250ZXh0PjxBdXRobkNvbnRleHRDbGFzc1JlZj51cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydDwvQXV0aG5Db250ZXh0Q2xhc3NSZWY+PC9BdXRobkNvbnRleHQ+PC9BdXRoblN0YXRlbWVudD48L0Fzc2VydGlvbj48L3NhbWxwOlJlc3BvbnNlPg==
10/2/2020 03:45:32 PM CEST Response Ok. Status [urn:oasis:names:tc:SAML:2.0:status:Success]
10/2/2020 03:45:32 PM CEST Raw SAML Response:
<?xml version="1.0" encoding="UTF-8"?><samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_df18ba3b-e1a2-4859-b195-b5c9731e25fb" Version="2.0" IssueInstant="2020-10-02T13:45:32.763Z" Destination="https://192.168.144.133:9013/samlv2/acs" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="id8c2168b91f6046509694420ff4c3d630">
  <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://Srv2016.contoso.local/adfs/services/trust</Issuer>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="_1e5fa7a7-1782-4e9b-914e-e12209e3f0fa" IssueInstant="2020-10-02T13:45:32.763Z" Version="2.0">
    <Issuer>http://Srv2016.contoso.local/adfs/services/trust</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="#_1e5fa7a7-1782-4e9b-914e-e12209e3f0fa">
          <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>0FO8OPWcD5xwSMhK2zbu2t1OrtkV5pe0IbmUHLUmaqo=</ds:DigestValue>
        </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>Fb5XXOwuPU8ynm+ZslxUp6bTn7edS3x0g2mPROAPQW8RrYILHn4tHZE+KsSj/PxzOydnmfWNSJkVp2yY5argtcdfLN5jcP0WVHFmdKaXj9VyqFZySdUOwrs6hpt+daJGVZVdPc/11FGgSOgKP8QBYBPu6WM/8hv9CW+LT42Te8Vouo0CFJ3u/okmRoWoP129xmGxNd1Xh7a/PfY8F2DRBJNZqW0XOVxVr8QuJtfYlr5gHs6GCnHSJsufXWRSVsN+5jvxLCRtjzGGtad6VOuhxP2fUbay39o4HeInotPZDzia7XtSp7ZLV3N2+52wKbe9a7cmrvr33bPeQeW0rAewwA==</ds:SignatureValue>
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>MIIC5jCCAc6gAwIBAgIQGQ3+R4KTKJlA2cHx/09rPzANBgkqhkiG9w0BAQsFADAvMS0wKwYDVQQDEyRBREZTIFNpZ25pbmcgLSBTcnYyMDE2LmNvbnRvc28ubG9jYWwwHhcNMjAxMDAyMDk1NzQwWhcNMjExMDAyMDk1NzQwWjAvMS0wKwYDVQQDEyRBREZTIFNpZ25pbmcgLSBTcnYyMDE2LmNvbnRvc28ubG9jYWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUicz/Ww4+xh/tN2JLxvOmPm7gpjQa6pHsDTDCgeawroYnxtJ47jBTgfzTflgYL7kva5+tJTaEPWNxYO/t75uxnAntCkYrrb1C5+kWoIBgHHWVBH+Y2UdM4V99TXIIEgNrnUlmrIrHLFtxBAe5RLb+8VyZyKz1yFaOxyUqtaKTgWkuS9V56t1qoCnBGWXB+oTZo4D0QD2Dq1QLaps9HE4KfF6ipbOkxJvdkT5ZkTKrh77VTgL9SyUHa4RFsIiW1Kusnso3pO/eJcGcRheXkwDdFxlG6uGEn9czxsPlix1xCwSEWlaVmGA3JV6+PWD+bK4P7VUFgMdk3UPNs6xNDgVvAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAHHxxKdBz1VUc7KfZvmmaEElsZZVVAfo0oDyDXd2l5jRN8eRtE9igXAnkE6AMPcXYxmV1NTMklVlXS0nu8LjDs5VPNd/ki/fBsiQI7tAhUE+zQ/z6ZVDIwfPHavxHvm66C+xoBsRw4eI7Z8pCj6uxXa4/SEsKouRbfQNLmbc2TJcn+o6g1nq29uThVT8kTq9/pV+7smCzGVT6+gLh+ciRVeq1LtW21imz+0iEupZ5DDHkhpHhrXQbshgn6JcvqXT7IS+cmrWT2Lf1gETo5XauRGy0e7gxS5SeeoBj4b4AqjigfxPAblw8bLXb4udwd0rERQ7w3b0uthO5z1kvwvyhS4=</ds:X509Certificate>
        </ds:X509Data>
      </KeyInfo>
    </ds:Signature>
    <Subject>
      <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">mauro.viola@contoso.local</NameID>
      <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <SubjectConfirmationData InResponseTo="id8c2168b91f6046509694420ff4c3d630" NotOnOrAfter="2020-10-02T13:50:32.763Z" Recipient="https://192.168.144.133:9013/samlv2/acs"/>
      </SubjectConfirmation>
    </Subject>
    <Conditions NotBefore="2020-10-02T13:45:32.748Z" NotOnOrAfter="2020-10-02T14:45:32.748Z">
      <AudienceRestriction>
        <Audience>https://192.168.144.133:9013/samlv2/sp/4d4dfe29-25e7-49b8-80a4-f35f88bafddb</Audience>
      </AudienceRestriction>
    </Conditions>
    <AttributeStatement>
      <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
        <AttributeValue>mauro.viola@contoso.local</AttributeValue>
      </Attribute>
    </AttributeStatement>
    <AuthnStatement AuthnInstant="2020-10-02T13:45:32.717Z" SessionIndex="_1e5fa7a7-1782-4e9b-914e-e12209e3f0fa">
      <AuthnContext>
        <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>
      </AuthnContext>
    </AuthnStatement>
  </Assertion>
</samlp:Response>

10/2/2020 03:45:32 PM CEST Assert the [InResponseTo] attribute value [id8c2168b91f6046509694420ff4c3d630] is expected.
10/2/2020 03:45:32 PM CEST Assert the [Destination] attribute is equal to the expected [https://192.168.144.133:9013/samlv2/acs].
10/2/2020 03:45:32 PM CEST Assert the audience is eligible for confirmation if [NotBefore] is defined.
10/2/2020 03:45:32 PM CEST Assert the audience is eligible for confirmation if [NotOnOrAfter] is defined.
10/2/2020 03:45:32 PM CEST Assert the audience of the SAML response is equal to the expected [https://192.168.144.133:9013/samlv2/sp/4d4dfe29-25e7-49b8-80a4-f35f88bafddb].
10/2/2020 03:45:32 PM CEST Assert the Subject is eligible for confirmation if [NotBefore] is defined.
10/2/2020 03:45:32 PM CEST Assert the Subject is eligible for confirmation if [NotOnOrAfter] is defined.
10/2/2020 03:45:32 PM CEST Resolved email claim to [mauro.viola@contoso.local]
10/2/2020 03:45:32 PM CEST The user with the email address [mauro.viola@contoso.local] does not exist.
10/2/2020 03:45:32 PM CEST Creating user: 
{
  "active" : false,
  "data" : { },
  "email" : "mauro.viola@contoso.local",
  "memberships" : [ ],
  "passwordChangeRequired" : false,
  "preferredLanguages" : [ ],
  "registrations" : [ ],
  "twoFactorEnabled" : false,
  "verified" : false
}
10/2/2020 03:45:32 PM CEST User is not registered for application with Id [9053769e-399a-4a82-b6bc-716d61fe3526]
10/2/2020 03:45:32 PM CEST User has successfully been reconciled and logged into FusionAuth.
10/2/2020 03:45:32 PM CEST Authentication type: SAMLv2
10/2/2020 03:45:32 PM CEST Authentication state: Authenticated

I think this part is ok.
leaving SAML alone, I think the problem is elsewhere.
if I create a local user in fusionauth, only with an email address and therefore without a username, the behavior is the same.
i.e. I get a:
auth_code_not_found

if I ALSO set the username, then everything works.
It seems that the token decryption procedure does not work if the username field is blank.
actually fusionauth-client is 1.19.0

I tried to do it all over again: with an updated ADFS (2016 instead of 2012) and not localized (therefore in English): the result is the same. I don't think it's an ADFS problem. honestly, I don't know much ADFS, so I don't know if it's possible to create rules that can also create the username on FusionAuth, I tried without success: maybe, however, that fusionauth side is not possible.

however the problem is that with a user (even local) who has only the email, it is not possible to complete the verification of the token.

viola.mauro

Update 2.

after realizing that the problem is that of the lack of username, I thought of using the lambdas.
I changed the default of fusionauth for reconcile with SAML2.
There is no way to set the username.
I thought it was a problem related to the values passed in the SAML2 response, so I tried to set it specifically, in this way:

user.username = 'mauro';
user.fullName = defaultIfNull (samlResponse, 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name', 'name', 'full_name');

the created user should have username: mauro.
instead it is empty.
the fullname is correct and is taken from the SAML response.

help!

dan

@viola-mauro

Yes, we protect the username and email from being hijacked (more here: https://fusionauth.io/docs/v1/tech/lambdas/samlv2-response-reconcile#Limitations )

But I just want to make sure I understand this. From what you are saying, this doesn't have anything to do with ADFS at all.

If you create a user using the admin ui and only give them an email address, and then try to use the python code like so client.exchange_o_auth_code_for_access_token (authCode, redirectURL, applicationID, clientSecret)

you get an error message.

And you are using v1.19.0 of the python fusionauth client.

Here is that signature from the v1.19.0 lib:

    def exchange_o_auth_code_for_access_token(self, code, client_id, redirect_uri, client_secret=None):

You can see that is different than the one you are using. Can you try swapping the client_id and redirect_uri parameters in your code and see if that works? (I'm not sure why using a username would work, though.)

If that doesn't resolve the issue, can you please share your python code so I can take a look? (a zip file or github repo is great).

viola.mauro

I confirm: what you think you understand is correct.

I confirm version 1.19.0.
I saw the limitations of lambda functions: I had missed it. Thank you.

as for the signature of the exchange_o_auth_code_for_access_token method: I confirm that the signature is correct, it was probably a typo what I wrote in the first post.

in fact the instruction in the code is this:
client_response = client.exchange_o_auth_code_for_access_token (authCode, applicationID, redirectURL, clientSecret)

I will send you the zip with the code in private.

viola.mauro

I understood!
forgive me if I waste your time.
I feel stupid, very stupid.

the problem was downstream. I hadn't thought about it and my little knowledge of python error handling did the rest.
I noticed this by preparing the code for the zip file.
I report a part of it so as to explain the problem: even if I doubt that anyone can commit this idiocy.

            client_response = client.exchange_o_auth_code_for_access_token(authCode,applicationID,redirectURL,clientSecret)
            if client_response.was_successful():
	        result = '<p style="color:green">Access Granted.</p> Link logout: <a href="' + logoutUrl + '">Logout</a>'
                print(client_response.success_response)
		#... other code
                jsonResponse = json.loads(str(client_response.success_response).replace("\'", "\""))
                userId = jsonResponse['userId']
                userInfo = client.retrieve_user(userId)
                userInfoStr = str(userInfo.success_response).replace("\'", "\"")
                userInfoJson = yaml.load(userInfoStr, Loader=yaml.FullLoader)
                userName = userInfoJson['user']['username']
                userName = userName.lower()
                print ("Authenticated user: " + userName)
                sys.stdout.flush()

            else:
                print(client_response.error_response)
                result = '<p style="color:red">Access Denied!</p> Link logout: <a href="' + logoutUrl + '">Logout</a>'

When logging in with the username present there was no problem, if the username is missing something strange happens.
In reality the block was in error because I was trying to acquire data that I didn't have (UserName doesn't exist!).
Without that part of user identification everything works.

Damn!

dan

Ah, that's great! I've definitely made my share of mistakes, no worries!