Difference between revisions of "GFIPM Service Provider Monitoring"

From GFIPM Implementation Wiki
Jump to: navigation, search
Line 4: Line 4:
  
  
Many federations might find it useful to centrally monitor the federation's systems to verify availability.  [https://nief.gfipm.net/ NIEF] is one such [http://gfipm.net/federations.html GFIPM Federation] that implements monitoring of its Service Providers.  The [http://it.ojp.gov/docdownloader.aspx?ddid=1336 GFIPM Web Browser User to System Profile] (section 6.13) describes the normative requirements for this monitoring, while this wiki article focuses on getting the implementation correct.
+
Many federations might find it useful to centrally monitor the federation's systems to verify availability.  [https://nief.gfipm.net/ NIEF] is one such [http://gfipm.net/federations.html GFIPM Federation] that implements monitoring of its Service Providers.  The [http://it.ojp.gov/docdownloader.aspx?ddid=1336 GFIPM Web Browser User to System Profile] (section 6.13) describes the normative requirements for this monitoring, while this article focuses on getting the implementation correct.
  
 
== Service Providers ==
 
== Service Providers ==

Revision as of 18:26, 31 May 2011

Main Page


Many federations might find it useful to centrally monitor the federation's systems to verify availability. NIEF is one such GFIPM Federation that implements monitoring of its Service Providers. The GFIPM Web Browser User to System Profile (section 6.13) describes the normative requirements for this monitoring, while this article focuses on getting the implementation correct.

Service Providers

This monitoring validates each Service Provider is operating correct at a SAML level by performing SP-Initiated SAML SSO to access a status URL. The output of this status URL is an XML document describing the status of the Service Provider in question. This XML document can simply be a static page that the Service Provider requires SAML SSO to retrieve or it can be generated by software and provide detailed and complex status information about the system.


Identity Providers

It is much harder to automate monitoring for Identity Providers. Identity Providers are frequently only accessible by their user base; they do not need to be accessible on the Internet (and it simply makes sense from a security standpoint to minimize their accessibility). Additionally, most organizations have strict rules about issuing credentials to users, and to automate monitoring of IDPs, you would need to issue some sort of test/monitoring credentials. And the value of monitoring Identity Providers is a bit harder to analyze, since the results of that monitoring would likely be controlled in a way as to rely on the IDPs for access, yielding a situation in which the only time the monitoring of results might be valuable, they are inaccessible. This ultimately led to the decision by GFIPM to not try and standardize any sort of IDP monitoring.


XML Format of Health Status Document

The format of the XML status document is a simple tree structure with System Status reported initially, and allowing each organization to provide as much and as complex of a subsystem status as desired. Here is the simplest possible status document:

 <?xml version="1.0" encoding="UTF-8"?>
 <gs:SystemStatus xmlns:gs="http://gfipm.net/system/status/0.3">
 	<gs:SystemName>Your SPs Name</gs:SystemName>
 	<gs:Status>OK</gs:Status>
 </gs:SystemStatus>
                     

For initial deployments the above is the actual recommended results to return, since implementing complex status functionality is likely to only become an issue as a system grows and sysadmins need additional information inorder to adequately help users and diagnose problems. For a more sophisticated system that periodically tested their systems to generate a more complex and detailed status might look like:

 <?xml version="1.0" encoding="UTF-8"?>
 <gs:SystemStatus xmlns:gs="http://gfipm.net/system/status/0.3">
 	<gs:SystemName>CISAnet Service Provider</gs:SystemName>
 	<gs:Status>Degraded</gs:Status>
 	<gs:Description>At least one resource is currently offline.</gs:Description>
 	<gs:Subsystem>
 		<gs:SystemName>CISAnet Query Tool</gs:SystemName>
 		<gs:Status>OK</gs:Status>
 	</gs:Subsystem>
 	<gs:Subsystem>
 		<gs:SystemName>California DoJ JRIES</gs:SystemName>
 		<gs:Status>Failed</gs:Status>
 		<gs:Description>This component appears to be offline.</gs:Description>
 	</gs:Subsystem>
 	<gs:Subsystem>
 		<gs:SystemName>CISAnet Portal</gs:SystemName>
 		<gs:Status>OK</gs:Status>
 		<gs:Description>500 accesses in the past 28 days.</gs:Description>
 	</gs:Subsystem>
 </gs:SystemStatus>


Service Provider Requirements

All Service Providers must provide a Status URL to the Federation Manager at which the XML status for their Service Provider can be queried. This URL must be protected by SAML SSO. The Federation will deploy a Monitoring Identity Provider that will periodically poll this status URL and record the results for review on the GFIPM Portal. This file can be a static XML file for as long as the Service Provider Organization feels that such status is adequate.


XML Schema for Health Status Document

You can view the schema below:

 <xsd:schema
 targetNamespace='http://gfipm.net/system/status/0.3'
 xmlns:xsd='http://www.w3.org/2001/XMLSchema'
 xmlns:gs='http://gfipm.net/system/status/0.3'
 elementFormDefault='qualified' attributeFormDefault='unqualified'>
 
 <xsd:complexType name='SystemStatusType'>
   <xsd:sequence>
     <xsd:element ref='gs:SystemName' minOccurs='1' maxOccurs='1'/>
     <xsd:element ref='gs:Status' minOccurs='1' maxOccurs='1'/>
     <xsd:element ref='gs:Description' minOccurs='0' maxOccurs='1'/>
     <xsd:element ref='gs:Subsystem' minOccurs='0' maxOccurs='unbounded'/>
   </xsd:sequence>
 </xsd:complexType>
 
 <xsd:simpleType name='StatusType'>
   <xsd:restriction base='xsd:token'>
     <xsd:enumeration value='OK'/>
     <xsd:enumeration value='Degraded'/>
     <xsd:enumeration value='Failed'/>
   </xsd:restriction>
 </xsd:simpleType>
 
 <xsd:element name='SystemName'  type='xsd:string'  nillable='false'>
   <xsd:annotation>
     <xsd:documentation>The name of the system.</xsd:documentation>
   </xsd:annotation>
 </xsd:element>
 <xsd:element name='Status'  type='gs:StatusType'  nillable='false'>
   <xsd:annotation>
     <xsd:documentation>The status of the system.</xsd:documentation>
   </xsd:annotation>
 </xsd:element>
 <xsd:element name='Description'  type='xsd:string'  nillable='true'>
   <xsd:annotation>
     <xsd:documentation>A human readable description of the system's status, error codes can be included as appropriate.</xsd:documentation>
   </xsd:annotation>
 </xsd:element>
 <xsd:element name='Subsystem'  type='gs:SystemStatusType'  nillable='true'>
   <xsd:annotation>
     <xsd:documentation>If subsystem status is reported, it is a simple recursive type over the System Status.</xsd:documentation>
   </xsd:annotation>
 </xsd:element>
 <xsd:element name='SystemStatus'  type='gs:SystemStatusType'  nillable='true'>
   <xsd:annotation>
     <xsd:documentation>Overall System Status.</xsd:documentation>
   </xsd:annotation>
   </xsd:element>
 
 </xsd:schema>


Downloads

Monitor.zip - This zipfile contains sample monitoring XML files as well as the XSD schema file that validates these files.


Main Page