By: Simon Hill user 27 Jun 2018 at 6:28 a.m. CDT

25 Responses
Simon Hill gravatar
I have been following instructions at <https://gluu.org/docs/ce/3.1.3/authn-guide/inbound-saml-passport/> and <https://gluu.org/docs/ce/3.1.3/admin-guide/saml/> to configure both Passport Inbound SAML and Gluu SAML IDP, because I am intending to use Gluu Server as an IdP proxy. 'External' IdP: ADFS 4.0 running on Windows 2016 IdP Proxy: Gluu Server v3.13 'Website' SP: F5 BIG-IP APM v13 The initial Website SP / Gluu IdP trust relationship is working, and the client is dropped onto a page where they can select an IdP. The configuration for the remote ADFS server has been dropped into passport-saml-config.json ``` { "Test-IdP": { "entryPoint": "https://*removed*/adfs/ls/idpinitiatedsignon.aspx", "issuer": "urn:oasis:names:tc:SAML:2.0:metadata", "identifierFormat": "urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified", "authnRequestBinding": "HTTP-POST", "additionalAuthorizeParams": "", "skipRequestCompression": "true", "logo_img": "", "enable":"true", "cert":"MIIC2jCCAcKgAwIB ... MlK5phNnTa1Oj4Is=", "reverseMapping": { "email" : "email", "username": "urn:oid:0.9.2342.19200300.100.1.1", "displayName": "urn:oid:2.16.840.1.113730.3.1.241", "id": "urn:oid:0.9.2342.19200300.100.1.1", "name": "urn:oid:2.5.4.42", "givenName": "urn:oid:2.5.4.42", "familyName": "urn:oid:2.5.4.4", "provider" :"issuer" } } } ``` ...and has validated successfully and produced metadata. ``` <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="urn:oasis:names:tc:SAML:2.0:metadata" ID="urn_oasis_names_tc_SAML_2_0_metadata"> <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <KeyDescriptor> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIIDaDCCAlACCQDTaQL ... 0zO2Lmec9fAEyoD/VnEBQa6zkmApX 2PnrwhO0uC14tFLW </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/> </KeyDescriptor> <NameIDFormat> urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified </NameIDFormat> <AssertionConsumerService index="1" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://*removed*/passport/auth/saml/Test-IdP/callback"/> </SPSSODescriptor> </EntityDescriptor> ``` However when the user authenticates and the SAML token comes back from this ADFS IdP, something goes wrong, the passport_saml custom script <https://github.com/GluuFederation/oxAuth/blob/e4bd2499e884a447412a589a7cdcb65e79b79e50/Server/integrations/saml-passport/SamlPassportAuthenticator.py> returns an error at line 239 when trying to json.load the session state/attributes. I've zipped the oxauth and passport logs and dropped them on OneDrive along with some screenshots of the login process, and a diagram of the setup also. Please let me know if you need anything else. thanks, Simon.

By Thomas Gasmyr Mougang staff 27 Jun 2018 at 3:29 p.m. CDT

Thomas Gasmyr Mougang gravatar
Hi Simon, The problem is not at line 239 as that method itself returns true in all cases. Can you provide these log files: 1. `/opt/gluu/jetty/oxauth/oxauth_script.log` 1. `/opt/gluu/jetty/oxauth/oxauth.log`

By Simon Hill user 27 Jun 2018 at 3:34 p.m. CDT

Simon Hill gravatar
/opt/gluu/jetty/oxauth/logs/oxauth_script.log ``` 2018-06-27 10:31:11,240 INFO [qtp1744347043-18] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:239) - Passport-saml: Prepare for Step 1 method call 2018-06-27 10:31:11,241 INFO [qtp1744347043-18] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:239) - Passport-saml: session {auth_step: 1, acr: passport_saml, remote_ip: 86.153.152.3, scope: openid email user_name, response_type: code, redirect_uri: https://*removed*/idp/auth-code.jsp, state: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZnAiOiJhMzVmZjU0Ny02NzI5LTQ4MzgtOTBhNy1hY2ZhZTljNTk0OWYiLCJqdGkiOiJiNjc2NmJmOC0xNzM3LTRjNzctOTBkMC1hNjZjYjYxZjhkYTIiLCJhZGRpdGlvbmFsX2NsYWltcyI6eyJyZWx5aW5nUGFydHlJZCI6Imh0dHBzOlwvXC9yZW1vdGUucHJpLmNzZC5idC5jb21cLyJ9fQ.H3slgi2HhINjEgw4JKk2H_OT9W3PqcgzY6LLPJEE8QI, nonce: 76ecc20a-9816-4252-b3ad-bd79d9bfcb61, client_id: @!02D7.C9ED.8F2E.54A3!0001!EBCA.1411!0008!7C04.0268} 2018-06-27 10:31:11,241 INFO [qtp1744347043-18] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:239) - Passport-saml: state is obtained 2018-06-27 10:31:11,242 INFO [qtp1744347043-18] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:239) - Extra data: line 1 column 28 - line 1 column 226 (char 27 - 225) 2018-06-27 10:31:11,757 INFO [qtp1744347043-13] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:239) - Passport-saml: Prepare for Step 1 method call 2018-06-27 10:31:11,757 INFO [qtp1744347043-13] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:239) - Passport-saml: session {auth_step: 1, acr: passport_saml, remote_ip: 86.153.152.3, auth_external_attributes: [], scope: openid email user_name, response_type: code, redirect_uri: https://*removed*/idp/auth-code.jsp, state: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZnAiOiJhMzVmZjU0Ny02NzI5LTQ4MzgtOTBhNy1hY2ZhZTljNTk0OWYiLCJqdGkiOiJiNjc2NmJmOC0xNzM3LTRjNzctOTBkMC1hNjZjYjYxZjhkYTIiLCJhZGRpdGlvbmFsX2NsYWltcyI6eyJyZWx5aW5nUGFydHlJZCI6Imh0dHBzOlwvXC9yZW1vdGUucHJpLmNzZC5idC5jb21cLyJ9fQ.H3slgi2HhINjEgw4JKk2H_OT9W3PqcgzY6LLPJEE8QI, nonce: 76ecc20a-9816-4252-b3ad-bd79d9bfcb61, client_id: @!02D7.C9ED.8F2E.54A3!0001!EBCA.1411!0008!7C04.0268} 2018-06-27 10:31:11,757 INFO [qtp1744347043-13] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:239) - Passport-saml: state is obtained 2018-06-27 10:31:11,758 INFO [qtp1744347043-13] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:239) - Extra data: line 1 column 28 - line 1 column 226 (char 27 - 225) 2018-06-27 10:31:22,873 INFO [qtp1744347043-14] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:239) - Passport-saml: Basic Authentication 2018-06-27 10:31:22,875 INFO [qtp1744347043-14] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:239) - Passport-saml: Basic Authentication returning False ``` /opt/gluu/jetty/oxauth/logs/oxauth.log ``` 2018-06-27 10:31:22,875 INFO [qtp1744347043-14] [org.xdi.oxauth.auth.Authenticator] (Authenticator.java:164) - Authentication failed for 'null' ```

By Thomas Gasmyr Mougang staff 27 Jun 2018 at 3:49 p.m. CDT

Thomas Gasmyr Mougang gravatar
Is there a user with this email `gluuuser@iuser@test` among Gluu users? if so: 1. Delete that user 1. Make sure the authentication method is set correctly. Test again

By Thomas Gasmyr Mougang staff 27 Jun 2018 at 4:01 p.m. CDT

Thomas Gasmyr Mougang gravatar
Steps to apply passport authentication method: 1. Log into Gluu Admin Ui 1. Navigate to: **Configuration** > **Manage Custom scripts** 1. Select **Person authentication** tab 1. Enable **passport_saml** 1. Enable it Then 1. Navigate to : **Configuration** > **Manage Authentication** 1. Select **Default Authentication Method** tab 1. Select **passport**

By Simon Hill user 28 Jun 2018 at 1:56 a.m. CDT

Simon Hill gravatar
There is no `gluuuser@iuser.test` user existing, that's a brand new test account only exists in the external IdP. `Passport_saml` script is enabled, and `Default acr:` authentication method is set to `passport_saml`. /opt/gluu/node/passport/server/logs/passport-2018-06-27-10.log ``` 2018-06-27T10:31:11+0000 [INFO] ::ffff:127.0.0.1 - - [27/Jun/2018:10:31:11 +0000] "GET /passport/saml_config HTTP/1.1" 200 473 "https://*removed*/oxauth/auth/passport/passportlogin" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36" 2018-06-27T10:31:11+0000 [INFO] ::ffff:127.0.0.1 - - [27/Jun/2018:10:31:11 +0000] "GET /passport/login HTTP/1.1" 302 120 "https://*removed*/oxauth/auth/passport/passportlogin" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36" 2018-06-27T10:31:13+0000 [INFO] ::ffff:127.0.0.1 - - [27/Jun/2018:10:31:13 +0000] "GET /passport/token HTTP/1.1" 200 201 "https://*removed*/oxauth/auth/passport/passportlogin" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36" 2018-06-27T10:31:13+0000 [INFO] ::ffff:127.0.0.1 - - [27/Jun/2018:10:31:13 +0000] "GET /passport/auth/saml/Test-IdP/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJqd3QiOiJkYmFlYmUyMC04M2NkLTQ3MjQtOTczMC0zODgzNjNlZjMyZjYiLCJpYXQiOjE1MzAwOTU0NzMsImV4cCI6MTUzMDA5NjkxM30.MfdIVwTF85RQ2sW7lrT2AgCy7f-rFmwNsCbTB4lmUEo HTTP/1.1" 200 1901 "https://*removed*/oxauth/auth/passport/passportlogin" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36" 2018-06-27T10:31:22+0000 [INFO] profile : [object Object] 2018-06-27T10:31:22+0000 [INFO] PHNhbWxwOlJlc3BvbnNlIElEPSJfY2I1MDBhMmYtMmIxNi00NzY5LWI5NzktMTExMjg0ODIyMGZmIiBWZXJzaW9uPSIyLjAiIElzc3VlSW5zdGFudD0iMjAxOC0wNi0yN1QxMDozMToyMi41MDhaIiBEZXN0aW5hdGlvbj0iaHR0cHM6Ly9nbHV1LmNzZC5idC5jb20vcGFzc3BvcnQvYXV0aC9zYW1sL1Rlc3QtSWRQL2NhbGxiYWNrIiBDb25zZW50PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6Y29uc2VudDp1bnNwZWNpZmllZCIgSW5SZXNwb25zZVRvPSJfMDZiZTAyMGFmMDg0MjdhMzFkODQiIHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiPjxJc3N1ZXIgeG1sbnM9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphc3NlcnRpb24iPmh0dHA6Ly9hdXRoLmNzZC5idC5jb20vYWRmcy9zZXJ2aWNlcy90cnVzdDwvSXNzdWVyPjxzYW1scDpTdGF0dXM+PHNhbWxwOlN0YXR1c0NvZGUgVmFsdWU9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpzdGF0dXM6U3VjY2VzcyIgLz48L3NhbWxwOlN0YXR1cz48QXNzZXJ0aW9uIElEPSJfZGU1YTc3MWItZGRkYS00NDAwLThkZmUtMmIzNjJkMjQ3YjA2IiBJc3N1ZUluc3RhbnQ9IjIwMTgtMDYtMjdUMTA6MzE6MjIuNTA4WiIgVmVyc2lvbj0iMi4wIiB4bWxucz0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiI+PElzc3Vlcj5odHRwOi8vYXV0aC5jc2QuYnQuY29tL2FkZnMvc2VydmljZXMvdHJ1c3Q8L0lzc3Vlcj48ZHM6U2lnbmF0dXJlIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIj48ZHM6U2lnbmVkSW5mbz48ZHM6Q2Fub25pY2FsaXphdGlvbk1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMTAveG1sLWV4Yy1jMTRuIyIgLz48ZHM6U2lnbmF0dXJlTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxkc2lnLW1vcmUjcnNhLXNoYTI1NiIgLz48ZHM6UmVmZXJlbmNlIFVSST0iI19kZTVhNzcxYi1kZGRhLTQ0MDAtOGRmZS0yYjM2MmQyNDdiMDYiPjxkczpUcmFuc2Zvcm1zPjxkczpUcmFuc2Zvcm0gQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjZW52ZWxvcGVkLXNpZ25hdHVyZSIgLz48ZHM6VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIiAvPjwvZHM6VHJhbnNmb3Jtcz48ZHM6RGlnZXN0TWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjc2hhMjU2IiAvPjxkczpEaWdlc3RWYWx1ZT5Sc3FoVGVLQXZ3alNaWW4vZkludUNxWG9QbEFBQXFEMHBTSmxWMm85aXVjPTwvZHM6RGlnZXN0VmFsdWU+PC9kczpSZWZlcmVuY2U+PC9kczpTaWduZWRJbmZvPjxkczpTaWduYXR1cmVWYWx1ZT5vem1mMDdJM2NGZFVwU01BdHBHaWkxODRBdFR5eTBHTUcrdkRiY25BbndMbHRKeHpqZkg5QlIxUGlLNEJQb0FEZ2xNbW42YUZCMis5a1B5bVRvUFVoWmNMRGZkZzBJSDIrOW4yMnJVbDVqeGlNZnBYOWYxeEFZTUM5UWtPYktrS3JtNmJUeHRFZVhLMi9tTm5halI4c2lUNkRpK0FOMUNaRjVDa3YybWZvVlE0VEpIeDZPQ2JBSFpUK1hOeWlQMVp4V0tBcHhvbzZUNlJMYjViYmh2amJiU1JYMUxOM1RTbVhyRFNFNEdmTnB1cWwzY01MSTgvYWZpRU1hNUcxN2FHdHlncmZLaHM1Z3hJOHpiay9aZmQyQlpoWDBXTUk4UWFsVm5laWJ3Q2kySkM2RzVwZ1FaelBaa0NuU1VHdE5XeTNURHIzQW81Yjk3TTJRWHBEUGF6V3c9PTwvZHM6U2lnbmF0dXJlVmFsdWU+PEtleUluZm8geG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMiPjxkczpYNTA5RGF0YT48ZHM6WDUwOUNlcnRpZmljYXRlPk1JSUMyakNDQWNLZ0F3SUJBZ0lRU1dMeU1sU2E0cEpHbVNKWERLZlhuVEFOQmdrcWhraUc5dzBCQVFzRkFEQXBNU2N3SlFZRFZRUURFeDVCUkVaVElGTnBaMjVwYm1jZ0xTQmhkWFJvTG1OelpDNWlkQzVqYjIwd0hoY05NVGd3TmpFNU1URXhNek0xV2hjTk1Ua3dOakU1TVRFeE16TTFXakFwTVNjd0pRWURWUVFERXg1QlJFWlRJRk5wWjI1cGJtY2dMU0JoZFhSb0xtTnpaQzVpZEM1amIyMHdnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFEcXgySUozSGYrZFhrMGdZeTdnbThLd2FOSllsOVJDWmdBbGw0bHVnc01mK0xEeC9YSW11M1N1ZGNXWDVBM0poZmJJKzE5QmpPamVScytGZUVhcWxPeUhXRS9ZRm9zOXEyazF6b2FuM0FYZEFsbkRmVXc3bWdhMXBBdXNPdkJhNFBiM0krUHFCb2E5UzhaYTdISVVUcFBDd25QOUFLaGszcDZFVks2L2tweGdkSmRGUm5BUkNQV1ovU3FFS3lpaWNlMWMrdmVpM09UdExlb1FtWjY2Z1NyUDVTWHZHaHBwMnpaMlVabXY3bXVPZFMzaElnTzF5dFlTb2pld1QzYVBaem0rRTdCRXdXOWlkK08zak1LckNHa0gwdVd0R2s0aTFsR2E5UkdieTgraW91eU10emFVK2t6Y3J6WWJkMHFhVkFOSy9oQlNsMkdMcThyLzZWb0pBSGZBZ01CQUFFd0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFCbXZadFhYUG5paEFmTVNlT0hST2FFQU01bDNENW0rSDYzUVpJbEMvSGJRRDhXL1N4RXdVRXVlTHhVNjdzb0Q4R3Vja2poekdwSXlmOWFxQzVYZlo2eGZDb1VjY1IvcXR2UkoxMTd5QThjbmNQU2NjRU5BdDhVM3RyMDZGL0g0YXp4amdxL1RUQXZOcFZSa09BRzI1cDlMU3R3dFl3RTlUVFdaUnJnRkVTeTJGVzIwUmxmZVBwdTlXZXEzYVRNS2ZMR0M5dzZROG9TNXQ5QUtwTE1MZUd0Vmd1RFkxN25FZXRSWVBpK0RuVENYYW8vNHIvYlRJZzFNR2ZqR0h3ci84MmRManVyM0paZjNyUytkOE1yaTVDRXNxZjJDN2pkdkZnMVlUalRYckp1VFdWZWRYWFJLSzdvaWVVRDVpQlRGY0Nwajh2c01sSzVwaE5uVGExT2o0SXM9PC9kczpYNTA5Q2VydGlmaWNhdGU+PC9kczpYNTA5RGF0YT48L0tleUluZm8+PC9kczpTaWduYXR1cmU+PFN1YmplY3Q+PE5hbWVJRCBGb3JtYXQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpuYW1laWQtZm9ybWF0OnVuc3BlY2lmaWVkIj5nbHV1dXNlckBpdXNlci50ZXN0PC9OYW1lSUQ+PFN1YmplY3RDb25maXJtYXRpb24gTWV0aG9kPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6Y206YmVhcmVyIj48U3ViamVjdENvbmZpcm1hdGlvbkRhdGEgSW5SZXNwb25zZVRvPSJfMDZiZTAyMGFmMDg0MjdhMzFkODQiIE5vdE9uT3JBZnRlcj0iMjAxOC0wNi0yN1QxMDozNjoyMi41MDhaIiBSZWNpcGllbnQ9Imh0dHBzOi8vZ2x1dS5jc2QuYnQuY29tL3Bhc3Nwb3J0L2F1dGgvc2FtbC9UZXN0LUlkUC9jYWxsYmFjayIgLz48L1N1YmplY3RDb25maXJtYXRpb24+PC9TdWJqZWN0PjxDb25kaXRpb25zIE5vdEJlZm9yZT0iMjAxOC0wNi0yN1QxMDozMToyMi41MDdaIiBOb3RPbk9yQWZ0ZXI9IjIwMTgtMDYtMjdUMTE6MzE6MjIuNTA3WiI+PEF1ZGllbmNlUmVzdHJpY3Rpb24+PEF1ZGllbmNlPnVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDptZXRhZGF0YTwvQXVkaWVuY2U+PC9BdWRpZW5jZVJlc3RyaWN0aW9uPjwvQ29uZGl0aW9ucz48QXR0cmlidXRlU3RhdGVtZW50PjxBdHRyaWJ1dGUgTmFtZT0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvd3MvMjAwNS8wNS9pZGVudGl0eS9jbGFpbXMvZW1haWxhZGRyZXNzIj48QXR0cmlidXRlVmFsdWU+Z2x1dXVzZXJAaXVzZXIudGVzdDwvQXR0cmlidXRlVmFsdWU+PC9BdHRyaWJ1dGU+PEF0dHJpYnV0ZSBOYW1lPSJlbWFpbCI+PEF0dHJpYnV0ZVZhbHVlPmdsdXV1c2VyQGl1c2VyLnRlc3Q8L0F0dHJpYnV0ZVZhbHVlPjwvQXR0cmlidXRlPjxBdHRyaWJ1dGUgTmFtZT0idXNlcm5hbWUiPjxBdHRyaWJ1dGVWYWx1ZT5nbHV1dXNlcjwvQXR0cmlidXRlVmFsdWU+PC9BdHRyaWJ1dGU+PC9BdHRyaWJ1dGVTdGF0ZW1lbnQ+PEF1dGhuU3RhdGVtZW50IEF1dGhuSW5zdGFudD0iMjAxOC0wNi0yN1QxMDozMToyMi40NTZaIiBTZXNzaW9uSW5kZXg9Il9kZTVhNzcxYi1kZGRhLTQ0MDAtOGRmZS0yYjM2MmQyNDdiMDYiPjxBdXRobkNvbnRleHQ+PEF1dGhuQ29udGV4dENsYXNzUmVmPnVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0PC9BdXRobkNvbnRleHRDbGFzc1JlZj48L0F1dGhuQ29udGV4dD48L0F1dGhuU3RhdGVtZW50PjwvQXNzZXJ0aW9uPjwvc2FtbHA6UmVzcG9uc2U+ 2018-06-27T10:31:22+0000 [INFO] mapping : [object Object] 2018-06-27T10:31:22+0000 [INFO] User authenticated with: http://*removed2*/adfs/services/trustStrategy with userid: 2018-06-27T10:31:22+0000 [INFO] User redirected with: https://*removed*/oxauth/auth/passport/passportpostlogin.htm?user=eyJpZCI6IiIsIm1lbWJlck9mIjoiIiwibmFtZSI6IiIsInVzZXJuYW1lIjoiIiwiZW1haWwiOiJnbHV1dXNlckBpdXNlci50ZXN0IiwiZ2l2ZW5OYW1lIjoiIiwiZmFtaWx5TmFtZSI6IiIsInByb3ZpZGVyIjoiaHR0cDovL2F1dGguY3NkLmJ0LmNvbS9hZGZzL3NlcnZpY2VzL3RydXN0IiwiYWNjZXNzVG9rZW4iOiJhY2Nlc3N0b2tlbiJ9 2018-06-27T10:31:22+0000 [INFO] ::ffff:127.0.0.1 - - [27/Jun/2018:10:31:22 +0000] "POST /passport/auth/saml/Test-IdP/callback HTTP/1.1" 200 1103 "https://*removed2*/adfs/ls/idpinitiatedsignon.aspx?client-request-id=43c9c01f-03c5-4560-8f01-0080000000e2" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36" ```

By Thomas Gasmyr Mougang staff 28 Jun 2018 at 4:18 a.m. CDT

Thomas Gasmyr Mougang gravatar
Hi, As you can see from the oxauth_script.log file, basic authentication method is use to login. ``` 2018-06-27 10:31:22,873 INFO [qtp1744347043-14] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:239) - Passport-saml: Basic Authentication 2018-06-27 10:31:22,875 INFO [qtp1744347043-14] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:239) - Passport-saml: Basic Authentication returning False ``` You can check that at line 111 [here](https://github.com/GluuFederation/oxAuth/blob/master/Server/integrations/saml-passport/SamlPassportAuthenticator.py#L111). This mean that the uid attribute is not release as expected, hence [this line](https://github.com/GluuFederation/oxAuth/blob/master/Server/integrations/saml-passport/SamlPassportAuthenticator.py#L107) returns true. That is also visible in **passport-2018-06-27-10.log** file provide. ``` 2018-06-27T10:31:22+0000 [INFO] User authenticated with: http://*removed2*/adfs/services/trustStrategy with userid: ``` For a normal flow the message should look like this: ``` 2018-06-27T10:31:22+0000 [INFO] User authenticated with: http://*removed2*/adfs/services/trustStrategy with userid: thomas ```

By Simon Hill user 28 Jun 2018 at 4:31 a.m. CDT

Simon Hill gravatar
The authentication method is definitely SAML, because it's redirecting to the external IdP successfully, and returning a SAML token, you can see this in the line which begins ``` 2018-06-27T10:31:22+0000 [INFO] PHNhbWxwOlJlc3BvbnNlIElEPSJfY2I1MDBhMmYtMmIxNi00NzY5LWI5NzktMTExMjg0ODIyMGZmIiBWZXJzaW9uPSIyLjAiIElzc3VlSW5zdGFudD0iMjAxOC0wNi0yN1QxMDozMToyMi41MDhaIiBEZXN0aW5hdGlvbj0iaHR0cHM6Ly9nbHV1LmNzZC5idC5... ``` in the `/opt/gluu/node/passport/server/logs/passport-2018-06-27-10.log` log file. The SAML token is being returned to the Passport service, but the userid can't be determined for some reason? If you decode the SAML token, the attributes being returned look ok: ``` <AttributeStatement> <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"><AttributeValue>gluuuser@iuser.test</AttributeValue></Attribute> <Attribute Name="email"><AttributeValue>gluuuser@iuser.test</AttributeValue></Attribute> <Attribute Name="username"><AttributeValue>gluuuser</AttributeValue></Attribute></AttributeStatement> ``` Passport-saml returns that `state is obtained` in the oxauth-script.log: ``` 2018-06-27 10:31:11,757 INFO [qtp1744347043-13] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:239) - Passport-saml: state is obtained 2018-06-27 10:31:11,758 INFO [qtp1744347043-13] [org.xdi.service.PythonService$PythonLoggerOutputStream] (PythonService.java:239) - Extra data: line 1 column 28 - line 1 column 226 (char 27 - 225) ``` ...but the very next line is a message about `Extra data` which is why I thought the json.load was failing. Am I passing the parameters correctly, or is the SAML malformed in some way, preventing the passport-saml script from parsing it?

By Thomas Gasmyr Mougang staff 28 Jun 2018 at 4:37 a.m. CDT

Thomas Gasmyr Mougang gravatar
please follow these steps: 1. Login into gluu container 1. cd `/opt/gluu/node/passport/server/auth` 1. vim `saml.js` 1. change line 70 from `id: profile[mapping["id"]] || '',` to `id: profile[mapping["id"]] || profile[mapping["username"]] || profile[mapping["email"]]` 1. Restart passport service. Let me know the outcome.

By Simon Hill user 28 Jun 2018 at 4:47 a.m. CDT

Simon Hill gravatar
Changed script as per below: ``` var strategy = new SamlStrategy(strategyConfigOptions, function (req, profile, done) { logger.info("profile : "+profile); var idp = req.originalUrl.replace("/passport/auth/saml/","").replace("/callback",""); var mapping =global.saml_config[idp].reverseMapping; logger.info(req.body.SAMLResponse); logger.info("mapping : "+mapping); var userProfile = { id: profile[mapping["id"]] || profile[mapping["username"]] || profile[mapping["email"]] || '', memberOf: profile[mapping["memberOf"]] || '', name: profile[mapping["name"]] || '', username: profile[mapping["username"]] || '', email: profile[mapping["email"]], givenName: profile[mapping["givenName"]] || '', familyName: profile[mapping["familyName"]] || '', provider: profile[mapping["provider"]] || '', accessToken: "accesstoken" }; return done(null, userProfile); }); ``` This seems to have fixed the userid issue: ``` 2018-06-28T09:48:47+0000 [INFO] User authenticated with: http://auth.csd.bt.com/adfs/services/trustStrategy with userid: gluuuser@iuser.test ``` However logon still fails, I am directed to https://gluu.csd.bt.com/oxauth/auth/passport/passport-post-login and still get the same red error message `Incorrect username or password`

By Thomas Gasmyr Mougang staff 28 Jun 2018 at 4:54 a.m. CDT

Thomas Gasmyr Mougang gravatar
Note that the attribute mapping isn't working well. The username is not retrieve even if it is present in saml assertion. The solution provide above use the email as id if the id and the username aren't present in saml assertion. So you have to fix that too.

By Thomas Gasmyr Mougang staff 28 Jun 2018 at 5:03 a.m. CDT

Thomas Gasmyr Mougang gravatar
1. Login into gluu container 1. cd `/opt/gluu/node/passport/server/auth` 1. vim `saml.js` 1. Change line 64 to look like this `logger.info("profile : "+JSON.stringify(profile));` 1. Restart passport service. 1. Test the flow 1. open the `/opt/gluu/node/passport/server/logs/passport-2018-06-27-xx.log` 1. You can see user profile information Then you can decide how to extract these information.

By Simon Hill user 28 Jun 2018 at 5:42 a.m. CDT

Simon Hill gravatar
Ok, added the logger line, and now I get a message like this: ``` 2018-06-28T10:42:33+0000 [INFO] profile : {"issuer":"http://*removed*/adfs/services/trust","sessionIndex":"_1a418b0f-71a3-45da-90ee-9bbee574ba34","nameID":"gluuuser@iuser.test","nameIDFormat":"urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified","http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress":"gluuuser@iuser.test","email":"gluuuser@iuser.test","username":"gluuuser"} ``` The passport service also seems to have auto-created the gluuuser@iuser.test account now, but without any of the normal parameters, only the email address is set: ``` Display Name iName UID Email Status - - - - gluuuser@iuser.test active ```

By Simon Hill user 28 Jun 2018 at 5:44 a.m. CDT

Simon Hill gravatar
A consequence of this user not having a display name or UID is that I can't click-through in the manage people GUI to manage or delete this user.

By Thomas Gasmyr Mougang staff 28 Jun 2018 at 6 a.m. CDT

Thomas Gasmyr Mougang gravatar
As you can see from the profile received, just the `email` and `username` are release from the `auth.csd.bt.com`. You have to release all required attributes or just replace missing one with ones of the existing ones. `auth.csd.bt.com` must release these attributes. A proper profile should be similar to this: ``` {"issuer":"https://gluu1.gasmyr.com/idp/shibboleth","sessionIndex":"_93d400987b37b1ccfb9d313975823 cf6","nameID":"AAdzZWNyZXQxMbaBc5A7ATcWriolyKaRPwXe/I7bd9XbG/G0d/8lRmJ4EetSZKdFx6UBHc/ska1/zujvdNsBPuzpVLQ6jCUw0Csy968ueOfMwc4Ad8M=","nameID Format":"urn:oasis:names:tc:SAML:2.0:nameid-format:transient","nameQualifier":"https://gluu1.gasmyr.com/idp/shibboleth","spNameQualifier":"u rn:test","urn:oid:0.9.2342.19200300.100.1.1":"thomas","urn:oid:0.9.2342.19200300.100.1.3":"thomasgasmyr@yahoo.fr","urn:oid:2.16.840.1.113730 .3.1.241":"Gasmyr","urn:oid:2.5.4.42":"Thomas","urn:oid:2.5.4.4":"Thomas","mail":"thomasgasmyr@yahoo.fr","email":"thomasgasmyr@yahoo.fr"} ``` Note that in your case the way the username attribute is map is no correct that is why its value is not retrieve. But you can get that value if you change this line in `saml.js` from `username: profile[mapping["username"]] || '',` to `profile[mapping["username"]] || profile["username"] || '',`

By Simon Hill user 28 Jun 2018 at 6:10 a.m. CDT

Simon Hill gravatar
I'm not quite clear from the documentation what attributes should be released, or how they should be mapped. I have these attribute lists configured in the passport_saml script: ``` generic_local_attributes_list: uid, mail, cn, displayName, givenName, sn, provider generic_remote_attributes_list: username, email, name, name, givenName, familyName, provider ``` ...and this is the 'reverse mapping' section of my `passport-saml-onfig.json` file: ``` "reverseMapping": { "email" : "email", "username": "urn:oid:0.9.2342.19200300.100.1.1", "displayName": "urn:oid:2.16.840.1.113730.3.1.241", "id": "urn:oid:0.9.2342.19200300.100.1.1", "name": "urn:oid:2.5.4.42", "givenName": "urn:oid:2.5.4.42", "familyName": "urn:oid:2.5.4.4", "provider" :"issuer" } ``` So using username as an example - do I release it from the external IdP as `urn:oid:0.9.2342.19200300.100.1.1` or as `username`, or `uid`, or...?

By Simon Hill user 28 Jun 2018 at 6:12 a.m. CDT

Simon Hill gravatar
Should I change the reverse mappings so they read more like this for example? ``` "reverseMapping": { "username": "username", "email": "email", ``` etc

By Thomas Gasmyr Mougang staff 28 Jun 2018 at 6:22 a.m. CDT

Thomas Gasmyr Mougang gravatar
> Should I change the reverse mappings so they read more like this for example? **No a good idea. Let said you have several external IDP, others may release attributes correctly and other may not.** The standard way is to release attributes by reference as define in reverse mapping. 1. `urn:oid:0.9.2342.19200300.100.1.1` is equivalent to `username` 1. `urn:oid:0.9.2342.19200300.100.1.3` is equivalent to `email` and so on.

By Simon Hill user 28 Jun 2018 at 6:26 a.m. CDT

Simon Hill gravatar
Ok, that makes sense, thankyou - I'll give it a go now. Appreciate your persistence on this one.

By Simon Hill user 28 Jun 2018 at 6:56 a.m. CDT

Simon Hill gravatar
Ok, I've updated my reverse mappings as below: ``` "reverseMapping": { "email" : "email", "username": "urn:oid:0.9.2342.19200300.100.1.1", "displayName": "urn:oid:2.16.840.1.113730.3.1.241", "givenName": "urn:oid:2.5.4.42", "familyName": "urn:oid:2.5.4.4", "provider" :"issuer" } ``` And the incoming profile now looks like this: ``` profile : {"issuer":"http://*removed*/adfs/services/trust","sessionIndex":"_7902a4a6-9871-4614-b75b-c6ead03d04fc","nameID":"gluuuser@iuser.test","nameIDFormat":"urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified","email":"gluuuser@iuser.test","username":"gluuuser","displayName":"Gluu User","givenName":"Gluu","familyName":"User"} ``` So all of the values listed are sent as attributes. Does this look correct?

By Thomas Gasmyr Mougang staff 28 Jun 2018 at 7:16 a.m. CDT

Thomas Gasmyr Mougang gravatar
No Sample: ``` {"issuer":"https://gluu1.gasmyr.com/idp/shibboleth","sessionIndex":"_93d400987b37b1ccfb9d313975823 cf6","nameID":"AAdzZWNyZXQxMbaBc5A7ATcWriolyKaRPwXe/I7bd9XbG/G0d/8lRmJ4EetSZKdFx6UBHc/ska1/zujvdNsBPuzpVLQ6jCUw0Csy968ueOfMwc4Ad8M=","nameID Format":"urn:oasis:names:tc:SAML:2.0:nameid-format:transient","nameQualifier":"https://gluu1.gasmyr.com/idp/shibboleth","spNameQualifier":"u rn:test","urn:oid:0.9.2342.19200300.100.1.1":"thomas","urn:oid:0.9.2342.19200300.100.1.3":"thomasgasmyr@yahoo.fr","urn:oid:2.16.840.1.113730 .3.1.241":"Gasmyr","urn:oid:2.5.4.42":"Thomas","urn:oid:2.5.4.4":"Thomas","mail":"thomasgasmyr@yahoo.fr","email":"thomasgasmyr@yahoo.fr"} ``` The revereMapping is correct but `auth.csd.bt.com` is releasing these attributes in a non formal way. This will work only if you change the way profile information are read: For example: 1. From `email: profile[mapping["email"]], ` to `email: profile[mapping["email"]] || profile["email"],` 1. From `id: profile[mapping["id"]] || '', ` to ` id: profile[mapping["id"]] || profile["username"] || '',` and so on.

By Thomas Gasmyr Mougang staff 28 Jun 2018 at 7:17 a.m. CDT

Thomas Gasmyr Mougang gravatar
Can you share how the attribute release is configured in `auth.csd.bt.com`?

By Simon Hill user 28 Jun 2018 at 9:12 a.m. CDT

Simon Hill gravatar
I've tried to keep the attributes released by the external IdP as generic as possible, because although I control it in this instance, in the future I may not be able to dictate the format that these attributes arrive as I add other 3rd party IdPs. My aim is to understand all the transformation/reverse mapping which can be done on the Gluu server end, so that I can accommodate whatever format arrives. This setup is a PoC for a larger deployment. If we pretend for now that I can't change the incoming attributes, and they will always arrive in this form: ``` "email":"gluuuser@iuser.test", "username":"gluuuser", "displayName":"Gluu User", "givenName":"Gluu", "familyName":"User" ``` What reverse mappings would I have to apply to this in order for passport service to process it correctly?

By Simon Hill user 28 Jun 2018 at 9:29 a.m. CDT

Simon Hill gravatar
I'm particularly interested in the Gluu Server auto-provisioning users based on incoming SAML attributes, so I'm keen to understand what I need to create a well-formed user account, with all necessary entries...

By Thomas Gasmyr Mougang staff 28 Jun 2018 at 11:20 a.m. CDT

Thomas Gasmyr Mougang gravatar
You can leave leave the reverse mapping as it is right now. The only part that you have to deal with is the user profile extract. You have to extract based on what is coming in. I think there is no more issue. Closing this ticket.

By William Lowe user 28 Jun 2018 at 4:24 p.m. CDT

William Lowe gravatar
We are going to work on smoothing out configurations for inbound identity in 3.1.4. [See this issue](https://github.com/GluuFederation/oxTrust/issues/389).