Hi. when we use ISAMLObserver implementation to log SAML messages on SP, we faced the issue on PROD env under high load (on DEV env all is ok).
It fails with exception: “Collection was modified; enumeration operation may not execute.” and broke all login process. If ISAMLObserver is commented out - no any problems to login.
ExceptionCollection was modified; enumeration operation may not execute. System.InvalidOperationException: Collection was modified; enumeration operation may not execute.
at System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource)
at System.Collections.Generic.List.Enumerator.MoveNextRare()
at ComponentSpace.SAML2.Notifications.SAMLObservable.OnSAMLResponseReceived(String partnerName, XmlElement samlResponse, String relayState) in C:\Sandboxes\ComponentSpace\SAMLv20\Library\Notifications\SAMLObservable.cs:line 69
at ComponentSpace.SAML2.InternalSAMLServiceProvider.ReceiveSSO(HttpRequestBase httpRequest, Boolean& isInResponseTo, String& partnerIdP, String& userName, SAMLAttribute[]& attributes, String& relayState) in C:\Sandboxes\ComponentSpace\SAMLv20\Library\InternalSAMLServiceProvider.cs:line 640
at ThinkTimeWeb.Controllers.AccountController.AssertionConsumerService(Int64 id)
We maintain an internal list of ISAMLObserver objects and iterate through this list calling OnSAMLResponseReceived.
Our assumption is that ISAMLObserver objects will be added to the list at application start-up etc rather than during SAML SSO.
The exception suggests that an ISAMLObserver object has been added whilst iterating across the list.
Does that make sense with your code? When are you adding ISAMLObserver objects?
If it possible to add ISAMLObserver objects at application start-up only?
Our assumption is that ISAMLObserver objects will be added to the list at application start-up etc rather than during SAML SSO.
The exception suggests that an ISAMLObserver object has been added whilst iterating across the list.
Does that make sense with your code? When are you adding ISAMLObserver objects?
If it possible to add ISAMLObserver objects at application start-up only?
Not clear what means under "ISAMLObserver objects". Are we speaking about XML messages which sent/received during login? Or about Subscription to the observer and OnCreateSAMLMessage, OnAuthnRequestSent and e.t.c.
We have ASP.NET app. ISAMLObserver implemented in 'AccountController' where AssertionConsumerService method placed (where we Receive SSO). We call Observer Subscribe in Initialize and Unsubscribe in Dispose method.
Messages came when users make login.
I meant the observer you register with the Subscribe method.
The current limitation we have is that we don’t protect the internal list of ISAMLObserver objects (ie the list of subscribers).
We’re iterating over that list to publish the OnSAMLResponseReceived event but a call to Subscribe has modified the list.
As a workaround, would it be possible to not Subscribe/Unsubscribe as you are currently doing? Instead, could you just register once?
The current limitation we have is that we don't protect the internal list of ISAMLObserver objects (ie the list of subscribers).
We're iterating over that list to publish the OnSAMLResponseReceived event but a call to Subscribe has modified the list.
As a workaround, would it be possible to not Subscribe/Unsubscribe as you are currently doing? Instead, could you just register once?
We were trying to implement Observer via singleton pattern to subscribe only once, but faced issue with saving data to DB. We are saving XML and current OrgId, but it appears that current OrgId already changed, but XML still came from the previous login. So in DB appears xml with the wrong OrgId.
Is there any chance to have the fix from your side?
But in any case, thanks for the explanation of the root cause of the error.
Please email support@componentspace.com.
If you could include some code showing the issue when using a singleton, that would be handy.
Perhaps there’s a simpler way to resolve the issue.
If not then we will look at whether this can be fixed in the short term.
If you could include some code showing the issue when using a singleton, that would be handy.
Perhaps there's a simpler way to resolve the issue.
If not then we will look at whether this can be fixed in the short term.
with singleton, the Observer is not a problem, but our own architecture and it can't be changed from your side. If fix for Observer Subscribe in Initialize and Unsubscribe in Dispose is possible, would be perfect, in another way will try to handle it by myself. at least i know what to do now. Thanks one more time.
You’re welcome.