Today we tried to deploy a fix for a site to production. The fix was unrelated to ComponentSpace and SAML, so no changes were made to that code specifically, although changes were made to the AssertionConsumerService controller. Additional logging was added, some additional Try/Catch blocks were added, and the necessary code fix was added. This works fine in local development, and our staging/QA environment. Upon deploying to production, however, we discovered a problem. Users were unable to log in to the site via SSO. The following error was logged:
ComponentSpace.SAML2.Exceptions.SAMLEnvironmentException: There is no HTTP context.
at ComponentSpace.SAML2.Utility.SAML.GetHttpContext()
at ComponentSpace.SAML2.Utility.SAML.GetHttpSessionState()
at ComponentSpace.SAML2.Data.HttpSSOSessionStore.Load(Type type)
at ComponentSpace.SAML2.InternalSAMLServiceProvider.LoadServiceProviderSession()
at ComponentSpace.SAML2.InternalSAMLServiceProvider…ctor()
at Application.UI.Controllers.SAMLController.d__10.MoveNext()
One SAML-related change we did make was to update the certificate used for the SP in the config file. I tried switching this out with the previous version of the cert and having the users try to log in again, but got the same message. The Assertion request data was logged, and I was able to post it into my local development instance and get a good login. So I think maybe IdP-initiated login could work? But I am not sure.
Can the certs be switched out live? Or do I need to reboot the site after changing those? Could that have been the issue in this case? That is the only thing that is really different between the UAT and Prod environments that is sticking out to me.
ComponentSpace version: 2.6.0.7 (9/11/17)
Hi Matt,
I don’t think this is related to the certificates.
To process the SAML response, we need to access the System.Web.HttpContext.Current. For some reason, this property is returning null.
It’s strange that this would be null in the context of a controller class.
As an experiment, I suggest checking if System.Web.HttpContext.Current is null in your controller prior to calling the SAML API.
If you’re not sure what’s causing the issue, please enable SAML trace and send the generated log file as an email attachment to support@componentspace.com mentioning your forum post.
Thanks.
Error trying to add tracing:
Exception information:
Exception type: TargetInvocationException
Exception message: Exception has been thrown by the target of an invocation.
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at Owin.Loader.DefaultLoader.<>c__DisplayClass12.b__b(IAppBuilder builder)
at Owin.Loader.DefaultLoader.<>c__DisplayClass1.b__0(IAppBuilder builder)
at Microsoft.Owin.Host.SystemWeb.OwinAppContext.Initialize(Action startup)
at Microsoft.Owin.Host.SystemWeb.OwinBuilder.Build(Action startup)
at Microsoft.Owin.Host.SystemWeb.OwinHttpModule.InitializeBlueprint()
at System.Threading.LazyInitializer.EnsureInitializedCore[T](T& target, Boolean& initialized, Object& syncLock, Func valueFactory)
at Microsoft.Owin.Host.SystemWeb.OwinHttpModule.Init(HttpApplication context)
at System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers)
at System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context)
at System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context)
at System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext)
The type initializer for ‘ComponentSpace.SAML2.Utility.Diagnostics’ threw an exception.
at ComponentSpace.SAML2.Utility.Diagnostics.Verbose(String format, Object[] args)
at ComponentSpace.SAML2.Configuration.SAMLConfiguration.Load()
at ComponentSpace.SAML2.Configuration.SAMLConfiguration.Load(String fileName)
at Application.UI.Startup.ConfigureAuth(IAppBuilder app) in S:\Agent003_work\1695\s\Application.UI\App_Start\Startup.Auth.cs:line 98
at Application.UI.Startup.Configuration(IAppBuilder app) in S:\Agent003_work\1695\s\Application.UI\Startup.cs:line 39
Couldn’t find type for class ComponentSpace.SAML2.Utility.CyclicTraceListener,ComponentSpace.SAML2.
at System.Diagnostics.TraceUtils.GetRuntimeObject(String className, Type baseType, String initializeData)
at System.Diagnostics.TypedElement.BaseGetRuntimeObject()
at System.Diagnostics.ListenerElement.GetRuntimeObject()
at System.Diagnostics.ListenerElement.GetRuntimeObject()
at System.Diagnostics.ListenerElementsCollection.GetRuntimeObject()
at System.Diagnostics.TraceSource.Initialize()
at System.Diagnostics.TraceSource.get_Switch()
at ComponentSpace.SAML2.Utility.Diagnostics…cctor()
Configuration:
<system.diagnostics>
<add
name=“CyclicTextWriter”
type=“ComponentSpace.SAML2.Utility.CyclicTraceListener,ComponentSpace.SAML2”
initializeData=“e:\logs\cpo”/>
</system.diagnostics>
The SAML library version you’re using is relatively old and doesn’t include the CyclicTraceListener that’s available in more recent versions.
For this older version of the SAML library, your logging configuration in web.config should be as shown below.
Make sure the initializeData specifies an existing folder.
<system.diagnostics>
</system.diagnostics>
OK that worked! I will have to see about putting the new logging in production but at least we have the logging in place.
Please email the log once it’s available.
Also, I suggest checking if System.Web.HttpContext.Current is null in the controller prior to calling the SAML API. It would be interesting to see if this is the case in the application as well.