Posts made by 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!

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.

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!

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.

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.

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 ...

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.

For python I have resolved.
with copy&paste I changed the order of parameters!
Now it works. My mistake.

I have tried also in Python:

Error 401.

I do not understand.
Or rather: I understand that I continue to make a mistake.
A logical or method error.

Gladly, Dan.

Returning to the problem.
I have also enabled webhooks under Tenants: nothing to do. From System-> Event log, I see the start of the webhook only if I test it with the appropriate button.
Never following the login event.

In any case, the problem remains. That is, even if I trigger the webhook, I still have to find the information I need and therefore I should run the various POST commands (with curl) to interface with the API: find the token, from this the IP of the request, etc.
So the command:

curl -v -X POST \
    -H 'Content-Type: application/json' \
    -d '{"code":"SLM0-9Slnm7bDgHOz-P6xNBkpyrRwnFupZyObSA_rUA","grant_type":"authorization_code","redirect_uri":"http%3A%2F%2F192.168.144.133%2Fcgi-bin%2Faddrule.sh","client_id":"5ee574b6-6929-437b-8f39-ec82ffc4e15b","client_secret":"r5wCNW0NNgmuzx2LNjfT1l7RlviZ3X8QOBk55iR7mWM"}' "http://localhost:9011/oauth2/token"

it is in any case to be performed and always returns me:
"error": "invalid_request", "error_description": "The request is missing a required parameter: grant_type", "error_reason": "missing_grant_type"

It's probably bullshit.
But I don't see it.

Hello.

@dan said in Authentication for a cgi-bin:

I"m not quite sure what you're trying to do.

maybe I don't know either.

without going into too much detail, the aim is to allow authenticated users to browse the Internet: the server where FusionAuth is installed will act as a firewall / gateway. Basically when a user is authenticated the executed script will create the appropriate rules via iptables.
so every time a user authenticates, something happens.
this something must know from which IP the request is made.

to answer your question: yes, I want to have an action (structured, complex) be fired off whenever someone logs in.

I repeat, maybe I'm wrong approach since I don't know the product, but I thought the best thing was to run a script after authentication. however I have to check that the call to the script is valid (authenticated user). If I authenticate via browser and then try to run the curl command (to simulate what the script would do) I get the error "The request is missing a required parameter: grant_type".
In the meantime, I'd like to understand what I'm wrong, that is why this error comes out: personal curiosity.
If there are simpler solutions to do what I need (events and webhooks) all the better.

After your suggestion I studied some webhooks (which I didn't know).
I created one, linked to the user.login.success event. If I didn't get it wrong, when this event goes off, it will visit a URL protected via basic auth, in this way I should be okay. I don't care about passing data, I just run the script. If I do it with the button (Webhooks-> Test-> Send events) everything works, if instead I perform the authentication nothing happens. there is no json handling in the script: I just run it, but it doesn't run.

I think I need to response with a status code of 200.

I don't know ... something is missing. maybe something big.

Hello.
No one?

Hello.
my goal is to start a .sh or .py file on the server after successful authentication.
I state that I tried for several hours without success.
I have also tried to find information about it, but I'm new to this technology and maybe I'm wrong to look for it (e.g. I'm looking for the wrong words).

said this: fusionauth is installed and running (version 1.17.5). I created the users (no role assigned) and the application (no particular options, except "Authorized redirect URLs" which you will then see). now, after the login proccess, the application is executed.
the problem is that: in the application I have not implemented (I have not succeeded) the check to understand if the user has authenticated.

I also followed this guide:
https://fusionauth.io/learn/expert-advice/oauth/definitive-guide-to-oauth-2

but in 5.1.3 it does not work (flow control, token).
when I run the POST, I get an error.

curl -v -X POST \
    -H 'Content-Type: application/json' \
    -d '{"code":"SLM0-9Slnm7bDgHOz-P6xNBkpyrRwnFupZyObSA_rUA","grant_type":"authorization_code","redirect_uri":"http%3A%2F%2F192.168.144.133%2Fcgi-bin%2Faddrule.sh","client_id":"5ee574b6-6929-437b-8f39-ec82ffc4e15b","client_secret":"r5wCNW0NNgmuzx2LNjfT1l7RlviZ3X8QOBk55iR7mWM"}' "http://localhost:9011/oauth2/token"

---

* Trying :: 1 ...
* TCP_NODELAY set
* Connected to localhost (:: 1) port 9011 (# 0)
> POST / oauth2 / HTTP / 1.1 token
> Host: localhost: 9011
> User-Agent: curl / 7.61.1
> Accept: * / *
> Content-Type: application / json
> Content-Length: 212
>
* upload completely sent off: 212 out of 212 bytes
<HTTP / 1.1 400
<Content-Type: application / json; charset = UTF-8
<Content-Length: 141
<Date: Fri, 17 Jul 2020 15:23:01 GMT
<Connection: close
<
* Closing connection 0
{"error": "invalid_request", "error_description": "The request is missing a required parameter: grant_type", "error_reason": "missing_grant_type"}

what am I doing wrong?
I have searched for grant_type around, but have not found anything interesting.