Grandpa Ham - Grandpa Can do IT! » Uncategorized

Web Services Security – A Link to a Really Good Non-Technical Description

grandpah — Mon, 14 May 2012 19:06:33 +0000

Why you should attach security at the message level, not just use SSL.

I found the following today as a good explanation. It goes all the way back to 2005, but the metaphor still works. See: Naked Motorcycle Riding

Java Solutions for the IPAWS-OPEN CAP 1.2 Aggregator

grandpah — Tue, 10 Jan 2012 17:44:50 +0000

I now have two very useful jar files to support Java developers connect to IPAWS-OPEN for CAP 1.2 Origination. The first takes a CAP 1.2 message as an XML String and signs it using the signature provided. The second, I wrote as a test driver for all IPAWS Origination and retrieval functions of the Originating System Interface (aka Interface A). It is entirely Property file driven, but it can also use the command line to override some properties in execution and can serve as a Java Class for providing the interface to systems that might want to put their own GUI front end in place (It has no GUI). It also does message signing for post operations. I cannot just put it on the open Internet, but I can provide the jar(s) to developers who have valid MOA’s to develop to IPAWS-OPEN Interface A. If you qualify, please contact me and I will the find a way to get the jar(s) to you. It is, after all, Government property that you, as taxpayers, paid for. One caveat: No warranties on this test code. You use it at your own risk. But it may help a lot.

The National EAS Test and IPAWS-OPEN

grandpah — Fri, 11 Nov 2011 12:43:21 +0000

Funny thing about the national test held on Wednesday 9 November. It was a test of the old stuff; not the new. IPAWS-OPEN and the Common Alerting Protocol (CAP) were not even part of the test. It worked – with glitches – but it worked. The glitches seemed to be mostly about garbled messages and misinterpreted tones; things that the text and Internet-based IPAWS-OPEN solution are designed to prevent. I am confident that the next test, when it happens, will go MUCH better from that standpoint.

The comments about the national test that were most amusing were the ones that connected the National test with an attempt by the federal Government to “take over the airwaves and the Internet.” The internet was not even used. I am not going to comment on whether the Government wants to regulate (or over-regulate) the Internet. That may, or may not be, depending on your personal political perspective. What I can say his that FEMA’s IPAWS program is absolutely not involved in that sort of activity. Input can come from the president, but it can also come from local authorities at all levels of government using alert origination tools provided mostly by private industry. Dissemination is the same. It is primarily voluntary; using a Government provided query architecture that allows local agencies and information providers to weed out unwanted material, making it the very opposite of a Government forced content push. Finally, the “last mile distribution” is almost completely through commercial providers and/or a very wide variety local government controlled software from the commercial sector. So, while IPAWS is designed to provide a way for the president to get an emergency alert to as many people as possible at one time, its architecture is actually built with local alerting and local control at its very core. Check it out for yourself. I will be at the annual International Association of Emergency Managers (IAEM) convention in Las Vegas next week. Drop by the IPAWS booth to say “hi” and to get a live demonstration. Good stuff.

NIEM Compliant and Not Standards Conforming – Absolutely Possible

grandpah — Thu, 04 Aug 2011 13:46:15 +0000

There have been at least two situations that I have heard of recently that claim NIEM Compliance and External Standards Conformance in the same breath. While it can be done, neither actually did so. In one case, NIEM elements were mixed into non-NIEM schemas, but the NIEM attributes were removed. This is clearly not the correct approach (although at least NIEM concept re-use was achieved). In another approach, external standard concepts were “NEIMified” in a tool and mixed with NIEM elements in a combined IEPD without the use of adapters. This approach is NIEM conforming, but NOT standards conforming. This approach can claim to use input from existing standards but cannot claim to actually use those standards. Especially, this approach cannot claim to conform to them. I firmly believe in NEIM as a methodology and as an excellent model for concept re-use, but building a NIEM conforming schema is not the same as building a standard. A standard involves acceptance of the exchange schema by a formal standards body or by a wide body of users as a reusable exchange. When you build a NIEM complient IEPD you have 3 options:

1. Build it as a NIEM IEPD and ignore other standards.
2. Build an IEPD and use pieces of external standards but ignore validation or conformance to the the standards that are reused.
3. Build an IEPD with standards conforming components in adapters and add any other needed data using NIEM want list methods or current NIEM elements .

In all three cases, the result is not a standard until it is recognized as one, either de facto or through a recognized standards body. So, the IEPD is just the beginning. Before it becomes a standard, it must be recognized, either by a formal standards body, or through industry dominant re-use.

Bottom line: If you choose path 2, you should not advertise it as standards conforming. While you can claim NIEM Conformance, you cannot honestly claim conformance to the external standards used as input in any way whatsoever.

Upcoming NIEM NTE Presentation – Using NIEM Metadata in an EDXL-DE wrapper to Support IPAWS

grandpah — Wed, 13 Jul 2011 20:46:13 +0000

If you work with the National Information Exchange Model (NIEM) as well as with other standards, you often run into issues related to how your overall work should incorporate (or not incorporate) NIEM. The rules for NIEM allow you to use recognized external standards independently. FEMA’s Integrated Public Alert and Warning System (IPAWS) does this with it implementation of the Common Alerting Protocol (CAP). You can also use components from an external Standard within a NIEM conforming schema, but only if you use the formally defined NIEM “Adapter” approach. You can also use NIEM inside an externally defined standard wrapper as shown in the graphic below.

My talk at the NIEM National Training Event (NTE) in Philadelphia this August will discuss using an OASIS Emergency Data Exchange Language – Distribution Element (EDXL-DE) as a wrapper as shown, but it will go beyond that. It will show how NIEM conforming data structures can be used within the EDXL-DE wrapper itself as DE conforming metadata to describe the content and desired distribution of the Information Exchange Package (IEP). The goal is to show an innovative use of NIEM that is actually made possible by the (also) innovative structure designed into the EDXL-DE standard. The actual content of the IEP will be an IPAW Profile conforming CAP message. The wrapping DE will use NIEM conforming metadata to define IPAWS distribution and content identification needs.

IPAWS-OPEN Live Demonstration (XML Geeks only)

grandpah — Fri, 11 Feb 2011 18:03:46 +0000

The notice below is an invitation to view IPAWS-OPEN 2.0 live via a SOAP UI connection. It will be of value to people who read XML and wish to see the capabilities of IPAWS-OPEN 2.0 as it works today. There are no “regular user” gui interfaces. Just Raw XML. But, it will be a live demonstration and will cover all of the current capabilities of IPAWS-OPEN 2.0. So, if you read XML, please join us. You will be able to see an unvarnished, live demonstration of IPAWS-OPEN 2.0 message exchange.

If you want a pretty GUI for the exchange, you will not see it here. But YOU CAN BUILD IT for your customers. And what you see can be a foundation.

Live Demonstration, XML Messages To and From
The Integrated Public Alert and Warning System (IPAWS)
Open Platform for Emergency Networks (OPEN) 2.0
Wednesday February 16, 12:00 Noon Eastern

Please note: The audio set up for this program has changed per below.  In order to check your audio set up, staff member Amy Sebring will be logged in by 11:30 AM Eastern to provide assistance.

IPAWS-OPEN enables the interoperable sharing of emergency alerts and incident-related data between systems that comply with non-proprietary information standards, and serves as the message aggregator for the Integrated Public Alert and Warning System.  During our next Webinar, System Architect Gary Ham will demonstrate a live soapUI view into IPAWS-OPEN 2.0 to show XML messages being transmitted to and from the system.

This program is intended primarily for third party IPAWS-OPEN developers and testers.  Please make plans to join us via Live Meeting. As always, your questions and comments are welcome.

IMPORTANT: The format of our Live Meeting has changed.  The audio portion will be delivered via your computer speakers and no telephone bridge will be provided for attendees.  The primary reason for this is to eliminate audio quality problems associated with using a bridge. The Live Meeting client must be used in order to receive the audio. Prior to the program, all attendees are urged to review the revised instructions available from:
http://www.fema.gov/about/programs/disastermanagement/archive/LiveMtgInstruct.pdf

(1) Login to MS Live Meeting for visuals: The following login link can only be used 30 minutes prior to the scheduled meeting time:https://www.livemeeting.com/cc/eiip/join?id=DMprogram&role=attend

If you are unable to attend this month’s meeting due to other commitments, a recording will be accessible from FEMA.gov.

Twitter Weekly Updates for 2010-12-26

grandpah — Sun, 26 Dec 2010 16:44:00 +0000

Diseconomies of scale in IT. 1 cause: disassociation of the correction of error conditions from those affected by the error. #
Probably the greatest Geek Christmas comic ever written!!! http://xkcd.com/835/ #
And do check out the mouse over added comment!!! Particularly if you have ever taken a data structures course. http://xkcd.com/835/ #

CAP For IPAWS – Defining Content Guidance

grandpah — Thu, 16 Dec 2010 15:24:46 +0000

What have we done to the Common Alerting Protocol (CAP)? In 2003, CAP 1.0 was released a simple, straightforward XML schema for alerting. It was, and is, a great idea and has achieved almost worldwide acceptance. As with any great idea, folks have discovered a need to tweak here and there and to impose their own rules for usage, security, etc. The great thing is that the basic structure remains in tact. The devil, however, remains in the details of implementation in systems throughout the world. We are on CAP 1.2. Europe has adopted CAP 1.1. Canada has published its own CAP Canadian Profile. We, in the U.S., also have the CAP IPAWS profile as an OASIS TC Committee specification and a requirement for broadcast of messages through FEMA’s Integrated Public Alert and Warning System (IPAWS).

I am currently trying to define a document to help CAP message origination software builders build an appropriate message for use in the world of FEMA’s IPAWS. This world includes both “regular CAP” and IPAWS Profile CAP, including its variations (EAS, NOAA NWEM, and CMAS). It is no small task. There are at least seven different documents that need to be “amalgamated” for the purpose (one of which has not even been formalized in writing yet):

The first is the actual CAP Standard; now version 1.2 (OASIS Common Alerting Protocol, Version 1.2, OASIS Standard, 01 July2010).
This is modified by the CAP IPAWS profile specification (Common Alerting Protocol, v.1.2 USA Integrated Public Alert and Warning System Profile Version 1.0, Committee Specification 01, 13 October 2009).
For messages bound for Emergency Alert System (EAS) disseminators there is the CAP ECIG recommendation (ECIG Recommendations for a CAP EAS Implementation Guide, EAS CAP Industry Group – ECIG, EAS-CAP Implementation Guide SubCommittee, Version 1.0, 17 May2010).
For messages bound for broadcast via NOAA Radio, there are additional rules (National Weather Service Instruction 10-1701, Text Product Formats and Codes, February 12, 2003).
For messages bound for cell phone broadcast there are rules requires to implement the ATIS/TIA Standard (Joint ATIS/TIA CMAS Federal Alert Gateway to CMSP Gateway Interface Specification, October 2009)
Originators will also need the documentation for connection to IPAWS-OPEN itself (Federal Emergency Management Agency (FEMA), Integrated Public Alert and Warning System (IPAWS) Open Platform for Emergency Networks (IPAWS-OPEN v2) Web-Service Interface Design Guidance Version 1.2, November 12, 2010). Note: the document is provided to external vendors and programs upon completion of MOA documentation.
Finally there will be formal rules on originator approval; NWEM and EAS Alert Originator Approval and Permission Procedures for IPAWS COGs (to be published).

My goal is to provide this document in iterations (think beta versions) to IPAWS-OPEN partners with completed MOAs. It will take some time, but, eventually, a formal version will also be published. Your input will be appreciated.

IPAWS-OPEN 2.0 Interoperable Connectivity Underway!

grandpah — Fri, 12 Nov 2010 15:56:38 +0000

I sent out the first 8 sets of credentials to independent interoperable systems this week. The test environment can now actually be used. Those of you who are familiar with FEMA procedures know what it took. Whew!!!!

For those who may not be totally familiar with IPAWS-OPEN, Check my permanent page on IPAWS.

IPAWS-OPEN 2.0 Has Been Given Authority to Test with Outside Developers

grandpah — Mon, 18 Oct 2010 22:37:21 +0000

A note to all of you who have been waiting since January (and before). We have been given authority. There is security paperwork to do, but the process is now in place.

Here are the details about the the IPAWS-OPEN Special Interest Group Meeting to be held at noon Eastern Time on wednesday where I will provide further detail :

Integrated Public Alert and Warning System (IPAWS)
Open Platform for Emergency Networks (OPEN) 2.0 Test Environment
Wednesday October 20, 12:00 Noon Eastern

During our next Webinar, System Architect Gary Ham will provide the latest information about access requirements for the IPAWS-OPEN 2.0 development test environment, including documentation and reporting requirements.

This program is intended primarily for system developers. Please make plans to join us via conference bridge and Live Meeting. As always, your questions and comments are welcome.

IMPORTANT: If you have not logged into Live Meeting before, check out the following connection instructions and participant guidelines prior to next week’s meeting:
http://www.fema.gov/about/programs/disastermanagement/archive/LiveMtgInstruct.pdf

(1) Login to MS Live Meeting for visuals: The following login link can only be used 30 minutes prior to the scheduled meeting time: https://www.livemeeting.com/cc/eiip/join?id=DMprogram&role=attend

(2) Call into the Conference Bridge number as follows: 1 (800) 366-7242 PIN 3647 6736#.

If you are unable to attend this month’s meeting due to other commitments, a recording will be accessible from the DM Web site.