SungHoon_Kim

How to healthcheck if Policy Server is working (not just running)

Blog Post created by SungHoon_Kim Employee on May 18, 2016

Some healthcheck only monitors if a process is running or if a port is up.

But that may not be the best way to monitor if Single Sign-On Policy Server is correctly processing requests.

Tools like SOI/Spectrum/eHealth and similar tools can be used to monitor the service using SNMP.

You can also create a custom agent or use testtool to check if it works.

 

But this is a simple way to check if Policy Server (and the Web Agent) is working.

(Among the limitations, this method cannot test against specific policy server)

 

Best way is to actually send a request and see if it returns a success.

IsAuthenticated call would be a good way to check the status.

IsProtected is also one way but it cannot tell if users can login and if the login is taking too much time.

 

One can use any tool that will send HTTP POST request.

Perl or curl are good sample.

 

I am going to use curl to do this.

Firstly, you need to choose which site to check.

From webagenttrace.log, you should be able to get the URL that is redirecting to login page.

But you can also simply use the "http://<host:port>/siteminderagent/forms/login.fcc" url.

 

In this sample, the site that I will be checking is http://www.test.lab and the protected resource is /test/

Based on the fiddler, following headers were sent to the login.fcc

POST to login.fcc for login

POST http://www.test.lab/siteminderagent/forms/login.fcc?TYPE=33554433&REALMOID=06-8f31087c-dd63-41ba-9dc1-4cb2da5a4b7a&GUID=&SMAUTHREASON=0&METHOD=GET&SMAGENTNAME=HmkWdrDG03zXzBHQL96mDV0ApL5Fig0aJWj16ECSd101PMca0xi0wB5DiH03GrgU&TARGET=-SM-http%3a%2f%2fwww%2etest%2elab%2ftest%2f HTTP/1.1

Accept: text/html, application/xhtml+xml, */*

Referer: http://www.test.lab/siteminderagent/forms/login.fcc?TYPE=33554433&REALMOID=06-8f31087c-dd63-41ba-9dc1-4cb2da5a4b7a&GUID=&SMAUTHREASON=0&METHOD=GET&SMAGENTNAME=HmkWdrDG03zXzBHQL96mDV0ApL5Fig0aJWj16ECSd101PMca0xi0wB5DiH03GrgU&TARGET=-SM-http%3a%2f%2fwww%2etest%2elab%2ftest%2f

Accept-Language: en-AU

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko

Content-Type: application/x-www-form-urlencoded

Accept-Encoding: gzip, deflate

Host: www.test.lab

Content-Length: 253

Connection: Keep-Alive

Pragma: no-cache

Cookie: SMLOCALE=en-US

 

 

 

SMENC=UTF-8&SMLOCALE=US-EN&USER=user1@test.lab&PASSWORD=XXXXX&target=http%3A%2F%2Fwww.test.lab%2Ftest%2F&smquerydata=&smauthreason=0&smagentname=HmkWdrDG03zXzBHQL96mDV0ApL5Fig0aJWj16ECSd101PMca0xi0wB5DiH03GrgU&postpreservationdata=

 

As long as you are sending the same information to this agent, it should return success.

So, the effort here is simply to repost the same data above.

 

I wrote a batch script to make the request.

batch file to post

@echo off

cd "C:\Users\Administrator\Desktop\winssl"

curl -v -i --data @postdata.txt -D header.txt -H "Host: www.test.lab" --user-agent "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" -H "Accept-Language: en-US,en;q=0.5" -H "Content-Type: application/x-www-form-urlencoded" "http://www.test.lab/siteminderagent/forms/login.fcc?TYPE=33554433&REALMOID=06-8f31087c-dd63-41ba-9dc1-4cb2da5a4b7a&GUID=&SMAUTHREASON=0&METHOD=GET&SMAGENTNAME=HmkWdrDG03zXzBHQL96mDV0ApL5Fig0aJWj16ECSd101PMca0xi0wB5DiH03GrgU&TARGET=-SM-http%3a%2f%2fwww%2etest%2elab%2ftest%2f"

 

And the postdata.txt file is where the POSTDATA is stored.

POSTDATA

SMENC=UTF-8&

SMLOCALE=US-EN&

USER=user1@test.lab&

PASSWORD=XXXXX&

target=http://www.test.lab/test/&

smquerydata=&

smauthreason=0&

smagentname=HmkWdrDG03zXzBHQL96mDV0ApL5Fig0aJWj16ECSd101PMca0xi0wB5DiH03GrgU&

postpreservationdata=

 

Now, if you run this batch script, it will POST to the login.fcc and authenticate the user.

 

The server response will be saved in the header.txt file as specified in the batch script.

Server response

HTTP/1.1 302 HTTP/1.1 302 Object Moved

Cache-Control: no-store

Content-Length: 0

Location: http://www.test.lab/test/

Server: Microsoft-IIS/7.5

set-cookie: SMLOCALE=en-US,en; path=/

set-cookie: SMTRYNO=; expires=Fri, 20 Nov 2015 04:45:57 GMT; path=/; domain=.test.lab

set-cookie: SMSESSION=funGNAeoS8i+a/UkOI75VKfJdpw9C+OuULXlwXeiD5pAXeut3QZRgVqcOKaFDzKuEjlAD9J+eyLyt7Mb80rfEKHi7qsyfSuKcbRz+P2C780seBjXR9oxyE66u6d1jb7dLzrWQ3JQQA+TbqzgRZUarD8UEBeKkyMv252pkEar/wfNwNPK88+CDlRsknklzetMmQ+ATxS48ZBZoZ+SVpHWtHfF4PDyoThdmRiHbepFGyeDyxGLPuSBcQlmSwlOImGR+avrN9/FY/nOukm1kcCwiokeBDy5dQSEpyDZu/gg7rclol1HnCO7WfMiymsAafzXhPO0XkOEJzQ/IS7w11FOm3cu6AnirmOD7uTPnaBmItHGNitTRQ7bgkZGg7gGrWZxGNsZ5tFYx0p2pzeFnrDmPCZLlvRkwgt2aRmqXsnbJLVqzNvdGH53uK+k7Xn7T9B/WYtW49h8lyWAqOIGc+cn83HwBv2Hs2E16Hh0AZq4SVBF6Ph4/G/iJZd+cupiWTBCQByvstqIeKsXYAfRgS4NnBXvNERGZIjkWjoLz2Bsu1GA0MpkoYLgKsrcZvLUIPYSbNBVdZHf6Gydy/krZgqX0sUMhz7LknquPTvu4K6m1aqEiqnyiY/pv+bYRkp7B5WEan6ynMFTupDLRVp8WFI4CgpxOJi6NRZtrbZgVxFQWZfAvx0SFgAwr7K6yZ4R0ndgbGd+TGPpS1t7fkWriP+H0agxPv0ir5kjMzD0AZDdBZ3/uaWiC5PMpJcPYh9/X3XwmIGZy8gJej3sIG2XOeohDUBDvXu0UTOl/WsBTK2i9KaP4xAgJyclcHMdgRWkaQSBqXPCnJ2GyWoxGf8U2yvK/BrDHW9Ma3Kuh6sEZCVNXk7376oYDw4tpmGtR7RHIgmwDx+RHKayBByEEKMRnj/CuT0JMaqyvjMQ7fZ3KxEDI5pTKOq+4CfzHPS+M0caifCVPc/bseRI+uMZAnyHP0iD/6uBkHl2Fd/NeDOjDccDVUZ/9/4cX1+YYH4bF4gJWY0AEQUy4wx1nXcVkVeQX8tnE9NMNl0wHqjeG3EB4GFBBS+cXImzf9X5h3eYBgBHVDwr; path=/; domain=.test.lab

X-Powered-By: ASP.NET

Date: Wed, 18 May 2016 04:45:59 GMT

 

From above, you can be sure that the Policy Server was authenticating the user just fine.

If the response does not return HTTP 302 or if the processing takes long time, you could add more actions to the batch script to send an alert or take some actions.

Outcomes