Symantec Access Management

  • Private Community
 View Only
Back to Library

GLIMPSE and CA Single Sign On WebAgent interoperability issues 

Apr 20, 2015 10:19 AM

Glimpse an opensource, is a web debugger and diagnostics tool for ASP.NET and ASP.NET MVC. Glimpse inspects web requests as they happen, providing insights and tooling that reduce debugging time and empower every developer to improve their web applications.

 

Recently had an issue which was surprising to deal with. An ASP .NET Application issuing a Large POST Data (JSON Format) working when CA Single Sign On (SiteMinder) WebAgent was disabled. However when enabled, the POST request returned a HTTP 500 Error as response.

 

Finer Details of the Issue being encountered.

 

BROWSER >> ISAPI FILTER / MODULE (WEBSERVER IIS) >> ASP .NET Code.

 

We traced both SM Enabled and Disabled Request from BROWSER >> ISAPI FILTER / MODULE (WebServer IIS) using a HTTP Requestor Tool which can generate different types of Request pattern. We took the POST DATA, stuck that into the Tool and did a POST to the same URL (under both Conditions SM Enabled / Disabled).

 

We see than when SM WebAgent is turned on, we are getting a ASP .Net Error back as response for the request we issued. At the same time when SM WebAgent is turned down we get a successful response from ASP .Net Code. Hence using the tool we were able to go beyond SM trace log (no errors in SM Logs - only success) and inference that the HTTP 500 error is being thrown by ASP .NET Code (This was confirmed).

 

We then started focusing on why is the ASP .NET application issuing a HTTP 500 Error as response when SM WebAgent is enabled. The obvious suspect was the possibility of SM WebAgent Tampering the POST Data. After enabling code level logging at the ASP .Net layer; we printed out a log file with the incoming POST Data at Code level. We found that with SM WebAgent enabled the file created was empty, however with SM WebAgent disabled the file created was populated with the POST Data.

 

Further investigation proofed that there was an logging tool called GLIMPSE which was running and that was causing the issue when interworking with SM WebAgent.

  • We removed this Tool from the WebSite (SM enabled), the POST worked. We added the Tool back in (SM Enabled) and POST Stopped working.
  • We add the Tool into WebSite (SMDISABLED), POST works. We add the Tool into WebSite (SMENABLED), POST stops working.

 

 

 

We knew that GLIMPSE (Reference Link below) had earlier interoperability issues with SiteMinder. However that was mitigated by a configuration change in GLIMPSE. In this case even with this configuration change in place, we were seeing interoperability issues. Hence due to business importance of SiteMinder we removed the tool from the ASP .NET Application.

 

Reference Link.

#############

1. https://github.com/Glimpse/Glimpse/issues/547

 

 

 

We do have a Support Ticket open on this issue. The reason I blogged here is, currently there seems be no solution within GLIMPSE nor in SiteMinder to have the tool interworking. Hence incase any one happens to see such an anomaly i.e. HTTP 500 errors and nothing being logged in SiteMinder Trace logs except success (You may need to start looking at what else is running other than the Application Code).

 

 

Having said that I have channelized the Support ticket to seek thoughts from CA Engineering about why GLIMPSE breaks when SM is enabled or Vice Versa; coz we don't know who is breaking who? Would let know if we find anything.

 

 

Regards

 

Hubert

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

Legacy User
Apr 24, 2015 08:16 AM

Thank You Ujwol for the suggestions.

 

Workaround-1 : Won't help, as the POST which is failing is a POST to a *.aspx page with Application specific data.

Workaround-2 : Is something that I am channeling with the Development Team to see if we could make it work; by tinkering GLIMPSE.

 

The longer term strategy sounds like the best. I am inclined to raise an ER and link this issue. So that CA Product Management gets visibility on this Product interoperability issue. As it is always the illusion that SiteMinder ain't working. More so we seem to spending a lot of time investigating this issue and a lot of man hours lost because it is not just SiteMinder resources but also Application Team, other product vendors and Microsoft not the least.

 

 

Regards

 

Hubert.

Ujwol
Apr 23, 2015 08:04 PM

Agreed.

 

Please note, I have updated my original post to include some workaround.

For SiteCore integration we confirmed that the first workaround worked.

However, based on the Microsoft documentation the second workaround should work as well ( we haven't tested it though as there was no flexibility to move the SiteCore module later in the event lifecycle.

 

Good Luck.

 

Regards,

Ujwol

Legacy User
Apr 23, 2015 08:40 AM

You're the man - Thank You Ujwol

 

This is awesome input, I guess the customer I am working with would be having the same issue. I am going to feed this input into the Support Ticket number [00075325: POST Request Failure].

 

This is where my confusion starts hence the thread CA Single Sign On : ISAPI Filter preCondition

 

What is the concept of NATIVE (I thought we just had MANAGED and CLASSIC Pipeline Mode).

  • IIS7WebAgent.dll supports the Managed Pipeline mode as a MODULE in the Integrated Model.
  • ISAPI6WebAgent.dll supports the Classic Pipeline mode as an ISAPI FILTER in the Classic Model.
  • However now I understand that both these DLL code is written in NATIVE mode and not MANAGED Mode.
  • After Googling (Hail Google and those blessed bloggers!!!) around found a couple of good articles which clearly differentiates
    • INTEGRATED Vs CLASSIC Pipeline Mode.
    • NATIVE Vs MANAGED Code.

 

 

Bottemline, it looks like we are going to get more and more such cases as the onus of determining the combination / permutation developing module on IIS for each product vendor is left to their own discretion. I am glad to know that it is not just me / this Customer who has encountered this with GLIMPSE. However there are others Tools which would have interoperability issues with WebAgent MODULE / ISAPI on IIS due to various possible combination of leeway that is allowed by Microsoft to deploy / build modules (the discretion is left to the Product Vendor)

 

All this makes me wonder, why couldn't there be a standard like SAML for building Solution Modules on IIS as that helps all Product Vendors to be following the same rules / regulation / standards.

 

 

Regards


Hubert

Ujwol
Apr 23, 2015 01:30 AM

Hi Hubert,

 

What a coincidence !!!

We recently worked on a very very similar issue where customer was integrating a IIS SiteCore module with SiteMinder.

 

Problem

The problem was when both SiteCore & SiteMinder are enabled in IIS 8.0, SiteMinder modules were NOT receiving any POST data and thus the request was failing with HTTP 500 server error.

It will work without any issue with just SiteCore or just SiteMinder standalone but not together.

 

Findings

After spending multiple days troubleshooting and going back and forth with engineering to build debug modules we finally found that this was as per the design of IIS 7 and above !!!

 

The following Microsoft KB article pretty much explained the problem

https://support.microsoft.com/en-us/kb/972541/

 

According to this article, when a MANAGED module reads the POST data it loads it into managed memory. After this point, any NATIVE module which executes will not be able to read the POST data as it is no more available.

Remember, SiteMinder modules/handlers are all NATIVE and Site Core module was Managed.

 

I am pretty sure in your case as well,  GLIMPSE is a managed component so when it happens to read the POST data prior to SiteMinder it will not leave any data for SiteMinder and hence the issue.

 

Work Around

 

1. As the problem is related to reading of the POST data destined for SiteMinder, one of the work around could be to have the MANAGED module (GLIMPSE logging component in your case ) avoid reading the POST data for SiteMinder specific extensions like .fcc/.sfcc/.ccc etc

 

2. Other option (which needs to best tested) is to move the other MANAGED module after the SiteMinder in the event lifecycle.

SiteMinder subscribes to AUTHENTICE_REQUEST event trigger so have the MANAGED module subscribe to event after "AUTHENTICE_REQUEST” ( e.g PostAuthenticateRequest)

 

Following document list all the Lifecycle Events in IIS Pipeline

http://www.dotnetcurry.com/showarticle.aspx?ID=747

 

Long Term Solution

As this issue has now been brought up couple of times already, we will need to engage our development and have them aware of this issue.

The future design of SiteMinder can then take into account of this problem.

 

References

RTC : 149402

Support Case : 00044995

 

Hope this helps.

 

Regards,

Ujwol

Related Entries and Links

No Related Resource entered.