Ongoing site architecture
An ongoing System Diagram of the Online Permitting System. It features an angular front end and node.js api for the public facing website hosted on cloud.gov. The public facing site connects to a SUDS middlelayer service, Pay.gov, login.gov and USDA eAuth through RESTful connections.
The public-facing platform is comprised of two applications: an Angular user interface and a Node.js backend server. These applications are hosted on cloud.gov. To see how the cloud.gov applications are provisioned please see the fs-cloud-migration repository.
The Platform module leverages both the user interface and the server of the public-facing site. It routes public users to a particular application form, enables them to fill an application form, and submit the information and accompanying files to available backend services. Forest Service administrators can accept pending special use applications and send the information to the USFS Natural Resource Manager Special Use Data System (SUDS) via the Middlelayer API.
At this point, the platform supports non-commercial group use applications and temporary outfitter and guide permit applications. It does not support the authorization or the issuance of the permit.
It does not support payment for permit fees.
To process incoming special user applications to SUDS, the Middlelayer API is a standalone router based on Node.js and hosted in cloud.gov.
The Middleylayer API receives incoming requests via an RESTful API from the public-facing site and saves some fields to its database, and files to its storage service. It modifies some of the fields (primarily through concatenation) and posts those and other fields to the SUDS Basic API through a series of requests.
In order to post an application to the SUDS Basic API, the Middleylayer API must:
- query to see if there an existing contact for the name on the application in SUDS,
- handle the creation of a contact, if no contact is found (by creating a contact, an organization, an address, and a phone number),
- submit the application,
- and return the status of the application back to the public-facing site.
Christmas tree permit sales are also available within the codebase of the public-facing site. This module allows users to purchase and print a Christmas Tree tag. It leverages a connection with the Pay.gov to process the payment via pay.gov hosted collection service. It will not handle processing or payment disbursement directly.
This module allows public users to print a Christmas tree permit from their own computer.
In utilizing a Heroku's 12 Factor Application Strategy we use backing services that are connected "makes no distinction between local and third party services". We manage these dependencies primarily using cloud.gov bound services, including user provided services for those not created via the service broker. The services are primarily managed through the Cloud migration.
For connected services that require an IP whitelist, please encourage the service provider to leverage other means of authentication with the service as this is not an ideal method to link a cloud-based application. If the provider cannot alter this provision, please refer them to the cloud.gov egress IPs which may be used in all cases and environments.
The public-facing site will leverage two kinds single sign-on authentication. The authentication is handled on the server using passport.js.
For Forest Service employees, the application will allow users to use USDA's implementation of CA 12.5.2 Siteminder: eAuth.
For end users that are members of the public, the application leverages the OpenID Connect Implementation of Login.gov.
The public-facing site will connect to the U.S. Treasury Department's Pay.gov, through an XML-based RESTful post request. This request will direct users to a payment form. Upon payment form submission, users will be redirected back to the public-facing site.
Pay.gov will pass along payment information to the USFS POSS Central Office application. POSS Central Office will relay the payment information to FMMI for disbursement to the forests.
The public-facing site's server leverages a PostgreSQL database provisioned through Amazon Web Services Relational Database Service (RDS) and cloud.gov and a Simple Storage Service (s3) bucket for file storage of application files prior to acceptance to SUDS.
The public-facing server uses an SMTP provided by the USDA relay service to send system emails. We send emails from the email address do_not_reply_openforest@usda.gov
The public-facing site connects to NRM SUDS through RESTful API services. For special use permit applications, the public-facing site directly interfaces with the Middlelayer API to simplify requests and store fields and files not currently held by SUDS. In the future, these services will be migrated to connect to a RESTful API service maintained by the redesigned NRM SUDS.
This is a RESTful API directly from NRM SUDS. It uses the Spring MVC to interact with the underlying SUDS Oracle database. For development purposes, this API modifies a partitioned schema within NRM SUDS.
It leverages a PostgreSQL database and an Amazon S3 storage service managed through cloud.gov to store fields and files not currently stored in SUDS, but needed for FS Special Use Administrators to make a determination on whether to accept an application.
A summary of the Cloud.gov roles is below, more information can be found in the Cloud Foundry - roles and Cloud.gov - managing teammates
- User: can view the list of other org users and their roles. When an Organization Manager gives a person an Organization or Space role, that person automatically receives Organization User status in that Organization
- Manager: managers or other users who need to administer the organization
- Billing manager: create and manage billing account and payment information (if applicable)
- Auditor: view but cannot edit user information and organization quota usage information
- User: view other users and their roles while being unable to make any changes
- Developer: application developers or other users who manage applications and services in a space
- Manager: managers or other users who administer a space within an org
- Auditor: view but cannot edit the space
-
middlelayer-production: fs-middlelayer-api -
middlelayer-staging: fs-middlelayer-api-staging -
middlelayer-dev: fs-middlelayer-api-dev -
platform-production: open-forest-platform-frontend, open-forest-platform-api -
platform-staging: open-forest-platform-frontend-staging, open-forest-platform-api-staging -
platform-dev: open-forest-platform-frontend-dev, open-forest-platform-api-dev
We maintain 3 environments for each application within Cloud.gov.
- Dev
- Connected Services:
- NRM TEST
- Connected Services:
- Staging
- Connected Services:
- NRM TEST
- Connected Services:
- Production
- Connected Services:
- NRM Prod
- Connected Services:
- Dev
- Connected Services:
- Login Int environment
- eAuth CERT
- Pay.gov QA
- Middlelayer Dev
- USDA Email
- Connected Services:
- Staging
- Connected Services:
- Login INT environment
- eAuth CERT
- Pay.gov QA
- Middlelayer Staging
- USDA Email
- Connected Services:
- Production
- Connected Services:
- Login Prod environment Needs IAA
- eAuth Production
- Pay.gov Production
- Middlelayer Production
- USDA Email
Our IAA with Cloud.gov specifies the absolute maximum amount of resources that we CAN use, however, they allocate a quota of those resources for immediate use. This is to prevent us from paying for resources that we do not use, since we are only billed for our quota.
Our current quota can be viewed using the Cloud Foundry CLI:
cf org usda-forest-service- copy the name for quota
cf quota <quota-name>
The result will look something like:
Total Memory 4G
Instance Memory unlimited
Routes 20
Services 30
Paid service plans allowed
App instance limit unlimited
Reserved Route Ports 0
By default the actual resources allocated and used can only be viewed one application at a time, however, plugins are available to make this easier. At the time of the writing, Open Forest is actively using 1.6 GB of an allocated 3 GB. Our target maximum memory is 2GB, but this is flexible subject to billing considerations.