By: Ben Murphy user 30 Jul 2019 at 9:32 p.m. CDT

5 Responses
Ben Murphy gravatar
Attempting to get office365 SSO working via GLUU. have followed the guide as best I can, it seems the documentation changes a lot from version to version. I have got to the point where we get redirected from office365 and have a Gluu login screen, then we can login but when redirected back to office365 we get error "AADSTS500082: SAML Assertion is not present in the token" from the Microsoft side. Any suggestions on where to look?

By Aliaksandr Samuseu staff 31 Jul 2019 at 11:33 a.m. CDT

Aliaksandr Samuseu gravatar
Hi, Ben. Please also create and share a HAR file with a capture of the whole failing flow. 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.

By Ben Murphy user 31 Jul 2019 at 7:51 p.m. CDT

Ben Murphy gravatar
Thanks for the quick reply. the HAR File can be downloaded from here https://file.io/spy43J

By Aliaksandr Samuseu staff 23 Aug 2019 at 7:21 p.m. CDT

Aliaksandr Samuseu gravatar
Hi, Ben. Sorry for the delayed answer. Do you still need help with this one? I believe I was looking into the HAR and saw some nameid issue in it back then, but I can't find it anymore, and the link is dead now. Could you re-upload, or create a new one perhaps?

By Ben Murphy user 23 Aug 2019 at 7:31 p.m. CDT

Ben Murphy gravatar
yes please still struggling with this. The HAR file is available here now https://file.io/sJLQvH

By Aliaksandr Samuseu staff 23 Aug 2019 at 8:29 p.m. CDT

Aliaksandr Samuseu gravatar
Thanks. This is SAML request your O365 instance sends: ``` <samlp:AuthnRequest ID="_a2aff004-40ca-4233-acff-5d36a7a89e8a" Version="2.0" IssueInstant="2019-07-31T21:15:13.753Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:MicrosoftOnline</Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/></samlp:AuthnRequest> ``` It explicitly requests nameid of "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" type, and this request will take priority over whatever is specified in its metadata, AFAICR. Shibboleth answers with this: ``` <saml2p:Response Destination="https://login.microsoftonline.com/login.srf" ID="_8125004480751d711c970429371c88ad" InResponseTo="_a2aff004-40ca-4233-acff-5d36a7a89e8a" IssueInstant="2019-07-31T21:15:17.337Z" 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://login.gen2.nz/idp/shibboleth</saml2:Issuer><saml2p:Status><saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester"><saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy"/></saml2p:StatusCode><saml2p:StatusMessage>An error occurred.</saml2p:StatusMessage></saml2p:Status></saml2p:Response> ``` `<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy"/>` means it wasn't able to find a suitable nameid it can release for this SP. Is it something configurable at O365 side? I see that our doc was suggesting to release nameid of "emailAddress" type. Overall, have you followed all steps in this doc, including modifying the template file and adding custom attribute to serve as email nameid? I would suggest to remove all custom additions to the template file for now, and also remove any configurations you could add using "SAML -> Configure Custom NameId" page too. Then you need to choose what could you use as a nameid. If you can switch it to "emailAddress" at O365's side, then you need to choose an attribute to serve as nameid of "persistent" type. The easiest way perhaps would be to use a computed nameid based on some unique attribute present on all your user entries. We can continue working on this tomorrow.