Reputation: 174
We are developing a .NET 7.0 web app, running on IIS 7. Our users will be authenticated remotely so we have Shibboleth-sp 3.4 installed to communicate with the appropriate IdPs. The IdPs send the authenticated user's info as a number of custom fields, passed both in the HttpRequest headers and the ServerVariables collection. The application can read all the fields from both sources correctly, except the one named "serialNumber".
For example, both Request.Headers["yearofBirth"].FirstOrDefault()
and HttpContext.GetServerVariable("yearofBirth")
return a valid value, however Request.Headers["serialNumber"].FirstOrDefault()
and HttpContext.GetServerVariable("serialNumber")
both return null
.
The application can read that there is a field named "serialNumber" in the request header, which doesn't seem to have a value. However, we have several older .NET 4.7 web applications communicating with the same IdPs and they all receive and read a valid value for this field, either from the request header or as a server variable (tested with the same test accounts). We are wondering if the name "serialNumber" has somehow been rendered invalid in .NET 7.0? Is there any solution other than trying to get every IdP in the federation to change the field name?
We have tested the code on two developer machines and one server. The developer machines have shibboleth-sp version 3 installed, upgraded from version 2 to maintain compatibility with the old applications. This means that the old applications (that can read the field value) and the new one are running on the exact same configuration. The web server has a clean installation of shibboleth-sp version 3 so the old applications can't be tested on that one.
Upvotes: 0
Views: 94