Development of a National Adult Protective Services Data System: Namrs Pilot Final Report (volume 2). 3. Namrs Pilot Website


The NAMRS Pilot Website was the main web interface that users interacted with. This website allowed state users, federal users, technical users, and administrators to log in, view/edit data, upload XML files, download reports, etc.


There were several functional types of pages on the website:

  • Administrative--These pages allowed a technical user or administrative user to manage (i.e., create/update/disable) resources, announcements, and users.

  • Account--These pages allowed any user to change their own password or log off.

  • Component Data--These pages allowed state users to enter/upload, change, and view their Agency, Case, and Key Indicators data. Federal users could view these pages for any state (although they could not change any data). Technical users and administrators could update data for any state and change the workflow status (i.e., accept/reject data).

  • Informational--These pages allowed any user to view information about NAMRS.

The website was built as a Microsoft ASP.Net MVC Web Application. The site was written in C# and used Entity Framework and LINQ for all database access. The site used HTML5, CSS3, and JavaScript, as well as many open-source components and frameworks, including jQuery, jQuery UI, Bootstrap, ELMAH, Unity, iTextSharp, and other components.

The website was hosted in the Microsoft Azure Cloud as a "Web App." A Web App (previously called an Azure Website) is a scalable, highly-available website. They provide a directory to upload the website into. They manage the all the underlying servers, security, server updates, networking, etc. Like all cloud services, if underlying hardware fails, the site is immediately moved and will become available immediately. Because of the redundant nature of the Web App service, there is no downtime for hardware upgrades and patches. If the site becomes slow because of traffic, it can be scaled to multiple server instances, and it can even spread those instances around the country and geographical load balancing will occur. The site can also be automatically scaled out based on traffic and scaled back in as traffic goes down (after hours) to keep costs down.


The site was accessed directly by users, like any other website. The user logged in to access any pages--there were no pages accessible without logging in, other than the login page itself and the NAMRS XML Schema Definition (XSD) file (the XSD file that needed to be accessed by users submitting Case Component data). The reason that the XSD file was accessible was that many (most) XML validators do not have a way of logging into a website before they retrieve an XSD file. Therefore, the general paradigm on the web is to make XSD files available without login through HTTP. There was no sensitive data in the XSD file.

The site also accessed several other components in the Azure Cloud (each component is covered in more detail later):

  • Session Data--There were just a few bytes of session data used across the site. An example of this data is that when a state user logged in, their assigned state was stored into session data for convenience. Session data was generally used for performance and convenience. The NAMRS Pilot used very little session data. Session data was stored in the Azure Redis Cache service and was very fast and very secure.

  • Website Data--All data for the NAMRS Pilot Website, including the state's Agency, Key Indicators, and Case Components, announcements and resources that were displayed on the website, login data, and other data was all stored in the NAMRS Pilot Database. This database used Microsoft SQL Server running on an Azure VM. (We looked at using SQL Azure, which (like Web Apps) was a managed SQL Service, but the space required and the performance levels would have been prohibitive for our purposes.)

  • Email--The NAMRS Pilot Website sent emails to state users and technical users as the status of state data was updated. For example, when a state user submitted their Agency Component data, an email was sent to a technical user to inform them that they needed to inspect this data. When the technical user approves/rejects the data, an email was sent to the state users to let them know the updated status.

Obviously, sending email requires an SMTP server, however Azure does not have an SMTP service available. However, Microsoft has contracted with a company called SendGrid to supply SMTP service through the Azure Marketplace. SendGrid offers an SMTP service (the service is also called SendGrid) to Azure customers for free. The service can send up to 25,000 emails a month for free, and additional credits can be purchased very inexpensively.


There were multiple security measures in the website, as described below.


As stated above, the entire site (other than the login page and XSD file) was protected by the requirement to login.


All communications between the user's browser and the website were encrypted with SSL. (The lock was displayed in the user's browser.) The site was configured to immediately switch to HTTPS if the user attempted to access through HTTP, so the connection was always encrypted.

The only exception to this was the XSD file. Users could access the XSD file using HTTP without being switched to HTTPS--this was the only file on the site that could be accessed through HTTP. The reason for this is that many (most) XML Editors/Validators cannot handle HTTPS.

Hashed Passwords

The site did not store user passwords in the database. Instead, only password hashes were stored. The password hash algorithm used in Microsoft Identity 2 was SHA1--more specifically, it ran 1000 iterations of a salted SHA1 (where the salt becomes part of the actual hash). Therefore, even if someone gained access to the database, it would require tremendous work to figure out the passwords (if it was possible at all). When a user entered their password, the password was sent to the website, where it was hashed and compared to the hashed value stored in the database. Since the website used HTTPS for all communications, the actual password was encrypted while it is being transported.


Every user was assigned a role when their account was created by an administrator. There were four roles:

  • State User--State users were also assigned to a state. State users could access data only for their state. There was no way for a state user to access data for a different state--there were checks in the site to block this and log it if a user attempted to do so.

  • Federal User--Federal users could access data for all states. They could view data but could not change any data on the site (except their own password).

  • Technical User--Technical users could access data for all states. They could view and change data for any state. They could also change the workflow status (i.e., accept/reject data components for each state). They could also manage (i.e., create/update/disable) resources and announcements.

  • Administrators--Administrators could do everything that technical users could do. They were also able to manage (i.e., create/update/disable) users.


The Web Apps service was firewalled from the Internet, and all physical and network security was handled by Azure.

Data Precautions

There was no personally identifiable information in the NAMRS Pilot, so there was no way to link any particular piece of data to an individual person. States always encrypted all their database IDs (using their preferred encryption methodology) that could potentially be tracked to an individual.


Like all ASP.Net Apps, configuration was done through the web.config file, located in the root of the App. All the parameters were documented in the web.config file.

View full report


"NAMRSpilot-V2.pdf" (pdf, 1.83Mb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®