Hi, Eric. The current state of this web UI control is far from ideal. It's guaranteed to work only in a few specific cases. This is a known issue and will be attended in the next major release. Until then, I would recommend to remove the nameid configuration you created in web UI, and use the manual way of adding nameid, described in the same document.

To be specific, this is the document I mean: [link](https://gluu.org/docs/ce/3.1.4/admin-guide/saml/#manual-configuration). By the way, nameid of what format are you trying to add?

I've checked the files you provided, and see your configuration changes now. I still would ask to check Nameid configuration page in web UI and make sure you don't have anything defined there. Ideally, it should be empty, and whatever nameid you may have there should be defined manually instead. Regarding the definition of "emailid" attribute in particular, one thing worries me. You use next format for it: `urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress` According to [certain claims](https://stackoverflow.com/questions/31709692/is-urnoasisnamestcsaml2-0nameid-formatemailaddress-a-valid-nameid-format), it may not be a correct format, and `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress` is the only valid one. Are you sure it's the same format your SP uses in request?

We would need next data to be able to fully understand what happens: 1. HAR file with a capture of the flow 2. `idp-process.log` recorded at DEBUG level For log: 1. Move into container 2. Preserve previous IDP log file, if needed: `# cp /opt/shibboleth-idp/logs/idp-process.log /opt/shibboleth-idp/logs/idp-process.log.bak` 3. Stop the IDP: `# service idp stop` 4. Edit section "Logging level shortcuts" of the `/opt/shibboleth-idp/conf/logback.xml` file, switch "idp.loglevel.idp", "idp.loglevel.messages" and "idp.loglevel.opensaml" loggers to DEBUG 5. Start the IDP: `# service idp start` 6. Wait for 10 minutes to make sure it's started fully For HAR: You can use steps listed [here](https://www.inflectra.com/support/knowledgebase/kb254.aspx) - please use Firefox for that task, Chrome's HARs are flawed. Also don't forget to set "Persist log" and "Disable cache" checkboxes in the console to save everything, not just the recently loaded page. After increasing logs verbosity, please re-try your failing flow, then share `/opt/shibboleth-idp/logs/idp-process.log` and the HAR file with us.

Good morning Aliaksandr, I’m assuming you are referring to configure custom nameid page under the SAML section? If so, then yes there is nothing there. I had at one point added ‘emailid’ to it. but when looking at saml-nameid.xml.vm I had noticed there were two entries for it. one I had created manually and another, I assume, was created from the web ui. After that, I had deleted the one on the web ui. The current state of this web UI control is far from ideal. It's guaranteed to work only in a few specific cases. This is a known issue and will be attended in the next major release. Until then, I would recommend to remove the nameid configuration you created in web UI, and use the manual way of adding nameid, described in the same document. The use next format urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress was taken from our idp dev server. During the initial upgrade of our dev environment, Mohib had added it to show us how it was done. It turned out that we don’t have anything in dev that was using ‘emailid’, so it was never tested before this. Regarding the definition of "emailid" attribute in particular, one thing worries me. You use next format for it : urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress According to certain claims, it may not a correct format, and urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress is the valid one. I have gone over that document several times in the past week. And the example code blocks are also using the urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress format. Which matched what Mohib had entered in out dev build. To be specific, this is the document I mean: link. I’m not sure what you mean by this. But the sp is expecting an email address By the way, nameid of what format are you trying to add? Last, I would like to apologize. Going through this upgrade on dev and prod is the first I have ever had to touch gluu/saml/shibboleth in this capacity.

Hi, Eric. Sorry for the delayed response. >The use next format urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress was taken from our idp dev server. During the initial upgrade of our dev environment, Mohib had added it to show us how it was done. It turned out that we don’t have anything in dev that was using ‘emailid’, so it was never tested before this It's acceptable to use it, the most important part here is that whatever format you use in configuration files you edit must match the one specified in SAML request and / or SP's metadata. And `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress` more likely will appear in those. If you are sure your SP uses `urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress` as well, then it's fine (may not adhere to standards fully, but still should do). For example, here is SAML request I've extracted from your HAR file: ``` <samlp:AuthnRequest AssertionConsumerServiceURL='https://training.knowbe4.com/auth/saml/1a96552345e9/callback' Destination='https://idp.millersville.edu/idp/profile/SAML2/Redirect/SSO' ID='_1ed67ae5-aefa-42f2-b5f7-db946910de87' IssueInstant='2019-05-20T14:44:10Z' Version='2.0' xmlns:saml='urn:oasis:names:tc:SAML:2.0:assertion' xmlns:samlp='urn:oasis:names:tc:SAML:2.0:protocol'><saml:Issuer>KnowBe4</saml:Issuer><samlp:NameIDPolicy AllowCreate='true' Format='urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress'/></samlp:AuthnRequest> ``` As you can see, this SP explicitly requests `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress` format, and such request won't be ignored by the IDP. If it won't be able to provide exactly this format of nameid, it will respond with the wrong nameid policy error. The configuration added previously should be fine, you just need to change that format string to match the one SP needs: 1. Change definition for "emailid" in `saml-nameid.xml.vm` by changing `urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress` to `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress` 2. Change definition for "emailid" in `attribute-resolver.xml.vm` in the same way 3. `# service identity restart` 4. `# service idp restart` Wait 5 minutes for it to start, and retry your flow. If it won't work anyway, please record the logs (at DEBUG level) and the HAR file again and share here.

Also, if it won't work after that change, please provide the actual files generated from those templates, gathered after the services were restarted (after step 4 above): `/opt/shibboleth-idp/conf/attribute-resolver.xml` and `/opt/shibboleth-idp/conf/saml-nameid.xml`

Aliaksandr, I think i understand what you are saying. I've made the changes in attribute-resolver.xml.vm and saml-nameid.xml.vm. and restarted idp and identity. and i'm still getting the same result. i'm adding a zip file with the files you have requested.

Hi, Eric. Your latest configuration seems correct, overall. A couple of suggestions, though: 1. In `saml-nameid.xml.vm`, you seem to put element for "emailid" in "SAML 1 NameIdentifier Generation" configuration list - please move it to "SAML 2 NameID Generation", where the rest of your nameids are located. 2. Please make sure you add "emailid" attribute to the Released list of this SP's TR. After following both itmes, please restart "identity", then "idp" services, and try this flow again. This should be it.

Hi Aliaksandr, I give up at this point. I had put the 'emailid' element back under the saml 2 section. It had been there origionally and still didn't work. and it still doesn't work. I spent some time looking over some of the other things i had done already. like cache refresh, attributes, certs. found that i had imported the idp-signing.crt and shibIDP.crt certs incorrectly. and fixing that broke things further. can we schedule some time to have you remote in and help me fix this thing? Thanks

>can we schedule some time to have you remote in and help me fix this thing? Please schedule a call [here](https://www.gluu.org/book-support/). Normally a customer will grant us remote access via shared screen in Zoom, if needed. That's as much remote access as we are allowed to have, without a lot of paperwork.

Hi, Eric. To prepare for our call tomorrow, I've tested `emailAddress` nameid addition in 3.1.4 one more time. It works for me, so I'm kind of intrigued what can be the issue here. One thing I noted though. In the latest `saml-nameid.xml` file you shared, you tried to put definition for your nameid in SAML1 list, like this: ``` <util:list id="shibboleth.SAML1NameIdentifierGenerators"> <ref bean="shibboleth.SAML1TransientGenerator" /> <bean parent="shibboleth.SAML1AttributeSourcedGenerator" p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" p:attributeSourceIds="#{ {'emailid'} }"/> </util:list> ``` When I later suggested you to move it to SAML2 list above, you said you tried it, and it didn't work. Did you change ``` parent="shibboleth.SAML1AttributeSourcedGenerator" ``` ..to ``` parent="shibboleth.SAML2AttributeSourcedGenerator" ``` ..while moving it? Because I first didn't spot that small difference myself, and it first threw an error for me, so I thought you could do the same mistake. Except this, everything went smoothly. One more wild guess: do you release any other nameid attributes for this SP? Like, are there "transient" attribute in its Released list, or some other attribute representing nameid, except "emailid"? Have you tried to remove all extra such attributes, and see whether it will help?

Sorry, Eric, some markdown issues, my post got truncated, had to rewrite it a bit. Please check the most recent version at Support Portal.

Morning Aliaksandr, I'm pretty sure i have made that change. I will doubble check when i get the chance. unfortunitly i think we are going to have to cancel today's call. we are having issues with our virtual environment. and the server i am working on is effected.

Morning, Eric. I see, no problem. Just choose another day, then. I would suggest to book a call today in advance, to avoid any delays due to the fact you can only book it for the day after tomorrow (there is always 24 hours delay to ensure we can prepare for it, so you can't book it for Monday on Sunday, for example).

Morning, Eric. From what I see in my mailbox, there is a call you arranged with us for today, 9am CDT (started 5 minutes ago). Do you have some issues when trying to join, or may be there is some kind of confusion?

We waited for 15 minutes (our usual policy), then ended the call. Feel free to arrange another one when you are ready.

I am sorry Aliaksandr. I thought I had scheduled for 10:30 EDT and not 10. And I was in a meeting till 10:30. I will schedule another and time. And I am sorry for wasting yours.

That happens, I understand. We usually also recommend to notify us about the booked call in the ticket as well - less chance that it will be overlooked, as mail notifications sometimes can be lost or delayed.

Aliaksandr, I booked another appointment for monday at 11EDT. I also found that i was smart enough to have a few snapshots to revert to. That undid most of what i broke after this issue started. so we have a better starting point.

Hi, Eric. That's great news. Yes, I've seen the notification. Hopefully, we'll finally resovle it on Monday.

Closing the ticket as the issue was resolved during the call today. Feel free to re-open it again if needed, Eric.