Addendum 2
RFP 2015 – 099
DOL Web Development and Support Questions and Answers
1
# PG.
NO.
SECTION
REFERENCE
QUESTION ANSWER
1 25 C-1
4th
sentence
There appears to be an incumbent vendor vis-à-vis the User
Account Management module. What will be the role of this
vendor with respect to this RFP?
The vendor registered and was present at the vendor conference and we
expect the vendor to submit a proposal.
2 25 C-3
“Vendor
will provide
support…”
Will the successful vendor be given VPN access to
servers to facilitate support?
No. Access to the State environment will need to be coordinated and in
the presence of a State DoIT resource either in-person or through the
use of a technology such as GoToMeeting.
3 25 C-3
Table C-3
(last row
on page
25)
Table C-3 mentions web application support as a
deliverable. Is this support for vendor-developed
software or does this imply support for modules
other than developed by the bidding vendor?
The vendor will be expected to provide support on the UAM currently
in development and also all applications developed under this RFP
contract.
4 What technologies, e.g., .NET, Java, PHP, etc., form
the basis for the existing web implementation?
The UAM application was built with .NET (framework 4.5) utilizing
MVC. The applications outlined in the RFP will be built using
WebForms.
5 Is there an update on the additional documents related to the
deliverables being made available? The c-2 spreadsheet
stated the missing documents will be made available by 3/5
The First Report of Injury Functional Design and Database Design were
posted to the Purchase and Property (P&P) web site on March 11th as
an addendum to the RFP.
The Wage Claim business requirements are being revisited and the
functional design will follow. The State will provide an extended Q&A
period for the Wage Claim deliverable only. Due date for inquiries by
Vendors and State responses will be provided with the addendum
containing the Wage Claim deliverable package. Due to this
inconvenience any Vendor wishing to receive an email notice of the
posting of this related addendum should send an email to
[email protected] with a subject line of “DOL RFP 2015-099
Wage Claim Alert”. This email notice shall be secondary, meaning it
remains the Vendors responsibility to check the site for any addendum
updates.
RFP 2015-099
DOL Web Development and Support - Questions and Answers
2
# PG.
NO.
SECTION
REFERENCE
QUESTION ANSWER
6 What was the cost for the services the last time this was out
for bid and how can I obtain a copy of the current contract?
The current contract was funded at $30,000/year for 2009-2013 and at
$13,554 for an extension into 2014. The State has increased its funding
for the anticipated development of these web application in the coming
2 years and realizes it may require multiple years to fund all the
development efforts. Vendors should realize State resources are limited
and it will be a single resource performing all code reviews along with
their other State duties. Acceptance testing will be performed by limited
resources with other duties on their plate as well. Based on funding, cost
of deliverables and State resources available the drafting of a projected
timeline deliverable work plans shall be an early step under the new
contract.
7 Can this work be done remotely or in house? Our expectation is the majority of this work if not all will be done
remotely on a vendor managed development environment that simulates
the State’s environment.
8 How much of this work do you anticipate can be done
remotely and how much do you anticipate can be done in
house?
Our expectation is the majority of this work if not all will be done
remotely on a vendor managed development environment that simulates
the State’s environment.
9 How many staff members is the current contractor using at
this time?
At the current stage in the UAM development project they are only
using one developer to my knowledge. Earlier in the process they had
two developers that I was aware of.
10 Is there any form of bonding or bid security required with
your bid? (other than the insurance requirements)
There is no bonding required, but you should be aware in the P37 Terms
of Agreement a vendor can be held liable for cost incurred by the State.
11 Is there a prebid conference being held for this solicitation?
if so is it mandatory to attend?
The optional vendor Conference was held on March 11th
at 10AM.
12 How will award be determined? Will it be "lowest
responsible offer or will it be most advantageous"?
A description of how the contract is awarded is provided in Section 5 of
the RFP, Proposal Evaluation Process.
13 We would like to convert the RFP from the provided pdf
format to a Word file to facilitate structuring our response
and to develop working checklists. Unfortunately the RFP
includes a password that prevents us from doing the
conversion. Are you able to provide us with the password?
If not could you provide a version of the document in Word
format?
The State prefers not to release the entire RFP as a Word document. The
State has extracted selected portions of the RFP and posted to the
Purchase & Property web site for vendor use. This Word document
extract is included in this same addendum.
RFP 2015-099
DOL Web Development and Support - Questions and Answers
3
# PG.
NO.
SECTION
REFERENCE
QUESTION ANSWER
14 Is there a general range that you are expecting for the
solution costs across all of the deliverables?
The State has provided detail business requirements, functional designs,
standards to be adhered to and descriptions of the State environment the
solutions must work in. The State is looking for Vendors to provide
competitive not-to-exceed (NTE) pricing per deliverable. The State is
under no obligation to go forward on any or all deliverables.
15 Has your organization ever awarded something similar
before, and is there a copy of the previous winner's proposal
that's publicly available?
The State has awarded similar contracts. A formal request under the
Right-To-Know law would need to be made for the proposal. The
request would then go through a lengthy process of redaction by the
AG’s office and the Vendor. It is unlikely the process would be
completed prior to the awarding of this contract.
16 Finally, we are based out of Nevada, but have a distributed
team across the entire United States. Are there any
restrictions in terms of where the vendor is? It would
obviously matter if you wanted to work with a local vendor.
See response to inquiry #17
17 Whether companies from Outside USA can apply for this?
(From India or Canada)
There are no restrictions regarding the location of companies or their
staff, however the State intends to add by addendum the following staff
requirements.
Vendors must be available Monday through Friday between the hours
of 8am and 4pm EDT and in the opinion of the State vendor
development and support staff team must be able to clearly
communicate with State developers.
18 Whether we need to come over there for meetings? On-site oral presentations will be required of Vendors as a final step in
the proposal evaluation and scoring process. At this point in the project
we cannot definitively state when or if any on-site meetings will be
required.
19 Can we perform the tasks (related to RFP) outside USA?
(From India or CANADA)
See response to inquiry #17
20 Can we submit our proposals via email ? No, proposals must be submitted as defined in the RFP
21
Is the NHDOL amenable to the projected being developed
using a Scrum methodology?
Yes. This is acceptable as long as the applications meet all applicable
standards.
22 Is it possible to receive a copy of the RFP in a word format? See response to inquiry #13
RFP 2015-099
DOL Web Development and Support - Questions and Answers
4
# PG.
NO.
SECTION
REFERENCE
QUESTION ANSWER
23 22 Appendix G
and H
Regarding Appendix G and H of the RFP, Page 22 of the
RFP states that these items could be completed after contract
award or are not required until contract time. Can the state
confirm there is no obligation for the vendor to complete any
items in appendix G or appendix H as part of their response
to this proposal?
The state confirms there is no obligation for the vendor to complete any
items in appendix G or appendix H as part of their response to this
proposal.
24 There were no completed functional design documents for
FROI and Wage Claim applications. Can the State provide a
copy of this information or identify a new anticipated release
date?
See response to inquiry #5
25 12 Deliverable 2B There was no database structure supporting the Central
Process Logging within the RFP (Deliverable 2B, page 12,
Section 5.2.1)? Can the State provide the database structure
for Central Process Logging?
In the Contact DOL functional design section 5.2.1 outlines the
requirements for the functionality. The State is leaving the database and
process flow design to the vendor which will require approval by the
State.
26 Will the outstanding documents stated above be delivered
before the deadline for formal questions?
In the Contact DOL functional design section 5.2.1 outlines the
requirements for the functionality. The State is leaving the database and
process flow design to the vendor which will require approval by the
State.
27 Is it possible to receive a copy of the RFP in a MS Word
format?
See response to inquiry #13
28 Can the state provide a listing of all vendor conference
attendees, including name, company, phone and email?
The State is providing the names of registered vendors who participated
in the vendor conference on March 11th
in a table following these
Q&A’s.
29 Is this a low cost bid? Or best value to the State? Cost is a substantial factor in the selection of a Vendor, but the
complete criteria and outline of the process is defined in Section 5
Proposal Evaluation Process.
RFP 2015-099
DOL Web Development and Support - Questions and Answers
5
# PG.
NO.
SECTION
REFERENCE
QUESTION ANSWER
30 There were no completed functional design documents for
FROI and Wage Claim applications. Can the State provide a
copy of this information or identify a new anticipated release
date? In the event the documents are released after the Q&A
period, will the state consider a Q&A extension period
related specifically for inquiries regarding these forms?
See response to inquiry #5
31 There was no database structure supporting the Central
Process Logging within the RFP (Deliverable 2B, page 12,
Section 5.2.1)? Can the State provide the database structure
for Central Process Logging? In the event this information is
released after the Q&A period, will the state consider a Q&A
extension period related specifically for inquiries regarding
the database structure?
See response to inquiry #25
32 Will each of the deliverables have a separate database? For
instance, will the Contact DOL-Public Side use the same
database as the Contact DOL-Admin side?
All deliverables will be in a single database. Users, roles and
permissions will separate applications and functionality. It is
understood that some adjustment to the design may need to happen to
accommodate this. Special consideration should be made for stored
procedures, functions or other objects in the database. Application will
need separate objects even if they are similar in functionality. Names
should reflect the application and still meet all applicable standards.
33 For each of the forms that can be downloaded, if a form is
printed and submitted via mail or fax, will NHDOL
manually enter the form in the internal interface and create
the user account for the person who submitted the form?
Submissions of forms by the public outside these new web applications
will be processed as they are today directly through the NHDOL legacy
system interfaces. The State will not create user accounts and enter
them through the new web applications.
34 Since applications must be able to work without JavaScript
enabled, what alternative methods can be used for features
like providing warning messages for session time-outs and
updating remaining character counts when entering data?
These will be text based instructions on the screen. The session time-
outs would then be displayed with the other page instructions and the
max number of characters would be displayed by the control.
35 Will NHDOL implement different design templates for iOS
and Android platforms? If so, when will those templates be
available and will the templates include layout samples for
basic forms and lists?
No.
36 What is the standard timeframe for passing state code review
and acceptance testing?
The State has limited resources, but for project timeline purposes the
vendor can assume an average of 30 business days for initial code
review and acceptance testing.
RFP 2015-099
DOL Web Development and Support - Questions and Answers
6
# PG.
NO.
SECTION
REFERENCE
QUESTION ANSWER
37 What procedures are in place if the state makes changes to
the specifications outlined within the RFP? In the event
specifications are changed, will the vendor have an
opportunity to revisit pricing associated with the amended
deliverable?
Changes to the specifications or scope are covered in Appendix H
under section H-25.7 Change Orders.
38 In Reference Document R1, Section 4.2, on Page 4, if an
amendment is added to implement changes to the RFP
specifications, and that amendment significantly impacts the
estimated deliverable hours as provided in an original
proposal submission, will the vendor have the opportunity to
revisit pricing associated with the amended deliverable?
Changes to the specifications or scope are covered in Appendix H
under section H-25.7 Change Orders
39 Proposal Submission, Section 4.1 on Page 6, Deadline, and
Location Instructions, Stares in the RFP that "The original
and all copies shall be bound separately, delivered in sealed
containers, and permanently marked as indicated above."
Does this mean that each of the 7 proposals must be in their
own container, or the original should be in a separate
container from the 6 copies? Can the vendor combine all
sealed containers into the same large container to minimize
shipping volume?
A single sealed container may contain the original and all six (6) copies
of the proposal.
40 RFP Addendum, Section 4.5 on page 8, In the event the State
issues amendments to the RFP, how will vendors be notified
and where can the amendments be retrieved from?
It is the Vendors responsibility to maintain checks of the RFP posting
on the Purchase and Property web site for updates.
41 Current Interfaces, Section C-4 on page 28, in the first
paragraph of this section the RFP states, "Vendor shall
complete the response checklist Table C-4 NHDOL Web
Application Interfaces." Following the text, there is a table
titled "Table C-4: NHDOL Web Site Interfaces." Can the
State confirm that these are one in the same despite the fact
they have different naming conventions?
The State has completed Table C-4: NHDOL Web Site Interfaces so the
opening sentence under C-4 Current Interfaces should be ignored. This
referenced opening sentence reads; Vendor shall complete the response
checklist Table C-4 NHDOL Web Application Interfaces.
RFP 2015-099
DOL Web Development and Support - Questions and Answers
7
# PG.
NO.
SECTION
REFERENCE
QUESTION ANSWER
42 Team Organization and Designation of key Vendor staff,
Section E-2 on page 39, this section instructs the vendor to
include resumes of key personnel proposed to work on the
project. The same resumes are also requested in sections E-3
and E-4. To avoid repetition and minimize response length,
would it be sufficient to only include the relevant resumes in
sections E-3 and E-4 and make reference to these complete
resumes in Section E-2?
Yes
43 State Staff Resource Worksheet, Section E-2.1 on page 40,
this section states, "Append a completed State Staff
Resource Worksheet to indicate resources expected of
organization… the required format follows." The table
following the text is titled "Table E-2: Proposed State Staff
Resource Hours Worksheet." Can the State confirm that
these are one in the same despite the fact they have different
naming conventions?
Yes confirmed
44 Appendix H on Page 61, Can the state identify Vendors are
expected to complete Appendix Hand submit it with their
proposal?
The P-37 Form under Appendix H will not be required to be completed
until such time a Vendor has been selected and a contract between the
State and Vendor is being constructed.
45 Regarding Section VIII of proposal Organization, can the
State clarify if the vendor is also expected to provide copies
of all appendix, deliverable and reference documents in the
‘Original’ binder response for this section?
The Vendor is required to provide copies of all documents in their
original form associated with the RFP posted to the Purchased and
Property website. This would include deliverables, reference
documents, addendums, etc.
These document copies are only required as part of the Vendor’s
original copy of their proposal.
46 Can the State clarify if an escrow agreement is required for
this Contract?
The State confirms the line should be removed. There is no requirement
for the Vendor to submit a proposed escrow agreement with their
proposal.
RFP 2015-099
DOL Web Development and Support - Questions and Answers
8
# PG.
NO.
SECTION
REFERENCE
QUESTION ANSWER
47 Document 1B
Sections
1.2 Purpose
1.3 Business
Owners and
Contacts
5.5.1
Stellarware
Testing
Just a quick note concerning documents 1A Business
Requirements and 1B Functional Design . References
throughout these documents refer to your current vendor
which make it appear as though these requirements were
intended to be sent directly to that company for proposal.
Stellarware has partially developed this deliverable under the previous
State Server Environment requiring further modifications. The
Stellarware contract expires this coming June and because they are
currently working on the UAM and may not get to these modifications
we included Deliverable 1 in this RFP. We will exclude Deliverable 1’s
cost from the cost criteria calculations.
48 Lastly, I had asked if this should be developed with MVC
and was told Web Forms.
5.3.3 Development Environment -
The application will use the ASP.NET MVC programming
model…
Web Forms. Any mention of MVC was an oversight.
49 C-2
Requirements
Sheet
For the applications referenced in the C-2 Requirements
Sheet, please provide any estimated usage statistics
(volume/number of users/peak windows of usage) for any/all
of the deliverables.
For calendar year 2011 the volume of submissions from the previous
web site were:
Contact DOL Inquiries: 3,226
FROI: 1,447
Wage Claims: 632
STW: 703
50 In section C-4
Current
Interfaces
The RFP DOL 2015-099 document asks vendors to complete
the response checklist C-4 NHDOL Web Applications
Interfaces. Please clarify what is being asked of the vendors
in completing this checklist.
The State has completed Table C-4: NHDOL Web Site Interfaces so the
opening sentence under C-4 Current Interfaces should be ignored. This
referenced opening sentence reads; Vendor shall complete the response
checklist Table C-4 NHDOL Web Application Interfaces.
RFP 2015-099
DOL Web Development and Support - Questions and Answers
9
# PG.
NO.
SECTION
REFERENCE
QUESTION ANSWER
51 With regard to the School-to-Work Program database,
rejection, and approval process (Deliverables 5A-5I), to what
extent is the State DOL looking for the application review
process to tie into the workers’ compensation and wage
claim databases to automatically check for compliance in
those areas? We note that state law at LAB 805.03(c)(1) and
LAB 805.03(c)(2) requires rejection of a school-to-work
business partner application for non-compliance with labor
laws and workers’ compensation requirements. If these
compliance checks are now done manually by the
department when reviewing these applications, is the
department looking to automate that with this new system
rollout to eliminate a manual process?
The is not seeking to automate their manual rejection,and approval
process with regard to the School-to-Work Program.
52 Page 23,
Section B-1
Submission Requirements of the RFP DOL 2015-099 states
that “The proposed escrow agreement shall be submitted
with the Vendor’s Proposal to be reviewed by the State.”
Should this statement be removed from the RFP?
The State confirms the line should be removed. There is no requirement
for the Vendor to submit a proposed escrow agreement with their
proposal.
53 In appendix F-
1, page 42 of
the RFP DOL
2015-099
The RFP requests a deliverable payment amount for each of
five milestones for each deliverable. Is the vendor able to
make an assumption of payment after a fixed number of days
for the 'Pass State Code Review and Acceptance Testing' and
'Implement to Production' milestones in the event the State
does not complete either activity in a timely fashion?
Each deliverable is expected to be invoiced separately with 90% being
invoiced upon implementation. The remaining10% holdback may be
invoiced upon completion of the warranty period.
54 What is the State’s expected timeline for test and production
deployment once an application is turned over to the State?
This is going to vary by application/deliverable as well as staff
availability. I would say within 30 days. When the time comes for an
application/deliverable we would be able to give a more specific
timeline.
55 Please provide the functional and technical design
documents for the UAM application.
At this point in the UAM development we will provide the UAM
business requirements and functional design documents. These
documents are included in the same addendum as these State responses
to Vendor inquiries.
56 Please provide a planned completion date for the UAM. The UAM solution has been delivered to the State and interface
obstacles between the UAM and the State’s single-sign-on application
are being worked on. We continue to resolve these obstacles daily, but
at this point we are unable to provide an expected completion date.
RFP 2015-099
DOL Web Development and Support - Questions and Answers
10
# PG.
NO.
SECTION
REFERENCE
QUESTION ANSWER
57 If we are to maintain the UAM, can the NHDoL provide
UAM design details? Architecture (dll, webservice, etc),
Access methods (webservice call, function, etc), and
approximate lines of code
See response to inquiry #55
58 In trying to get a feel for the budget for this project, we
looked at Stellarware’s current contract from 2008-present.
That contract was funded at $30,000/year for 2009-2013 and
at $13,554 for 2014. Should we anticipate that DoL is
expecting to continue that approximate level of annual
funding for the duration of RFP 2015-099?
See response to inquiry #6
59 30 Appendix D-2
Project Plan
Is there a proposed timeline available for the
development/implementation of the different applications?
For example the sequence or the order in which the five
applications may be required to be developed, could be
Contact DOL application in the first year, followed by FROI
and Wage Claim applications in the 2nd year and so on.
See response to inquiry #6
60 25 Appendix C –
Systems
Requirements
UAM, Can the users switch between any of these five
applications using single sign on? Is the switching allowed
only for admin users or all users?
Yes – all users are allowed to switch between applications. There is a
standard mechanism that allows the user to ‘log’ off the current
application and return to the UAM to view a list of available
applications.
61 25 Appendix C –
Systems
Requirements
Are there any mockups, wireframes or stylesheets available
for overall layout, navigation, look and feel?
We will provide the header, graphics and css files for the current
NHDOL website. These will provide the base for the applications look
and feel. Layout and navigation are to be designed by the vendor.
62 25 Appendix C –
Systems
Requirements
Do mobile devices need to be supported? The only application that requires design considerations for mobile
devices at this time is Contact DOL Public-Side.
63 25 Appendix C –
Systems
Requirements
Is there any nightly batch component needed for any of these
applications?
There is a batch process within the FROI and Wage Claim applications
requiring the extracting of selected records from the web database for
transfer to a State FTP server. Future application will require transfers
from the FTP server to the Web database.
There is also requirements for jobs to delete records from the web
database once they have been processed and a set number of days has
passed.
RFP 2015-099
DOL Web Development and Support - Questions and Answers
11
# PG.
NO.
SECTION
REFERENCE
QUESTION ANSWER
64 25 Appendix C –
Systems
Requirements
Are the required Web services already developed? The web services to interact with the UAM are currently in
development as part of the UAM project. Other web services will need
to be developed by the vendor as defined in the business requirements
and functional design.
65 25 Appendix C –
Systems
Requirements
Are any other interfaces, in addition to File pickups, needed
with any internal/ external applications?
Not at this time.
66 25 Appendix C –
Systems
Requirements
Can the applications such as FROI or Wage claims be
submitted by Third Party vendors? Are the applications
contemplated in the RFP required to handle that aspect as
well?
These applications are intended to process FROI and Wage Claim
transactions on an individual basis. The FROI application is expected to
be used by HR staff within the employers of NH. The Wage Claim
application is expected to be used by an employee of an employer or
claimant.
67 25 Appendix C –
Systems
Requirements
Data Conversion & Migration: Is there any data conversion
and migration needed for any of these applications?
It is requested in Deliverable 2 for an estimate and thoughts on the
effort required to provide prior Contact DOL inquiries and responses in
a process that is searchable.
68 53 Appendix G – Testing
What is the expected user volume in production? See response to inquiry #49
69 53 Appendix G – Testing
What is the expected database size in production? See response to inquiry #49
70 66 Project Budget What is the proposed budget for this initiative?
See response to inquiry #6
71 3 Project Overview
Could you please provide specifics/technology stack envisaged for these applications e.g. application server & version thereof; database and version thereof; webserver and version thereof; load balancer, etc. Also, could you provide us with your vision regarding the deployment of these applications i.e. will these applications be deployed on a server farm; whether each application will have separate webserver etc.
The State Server Environment consist of a single database server, a
single external application server, a single internal application server
and a single web services server.
72 Is this a single vendor award? Yes
RFP 2015-099
DOL Web Development and Support - Questions and Answers
12
# PG.
NO.
SECTION
REFERENCE
QUESTION ANSWER
73 As a primary firm registered in NJ, can we also utilize our
affiliate's resources stationed in India? This will be a cost
effective work model.
See response to inquiry #17
74 How much of work is envisaged onsite? Can it be done
offsite as well?
Our expectation is the majority of development will be performed off-
site. Outside resources will have no direct access into the State network
and will be required to work collaboratively with State resources using
technology such as GoToMeeting to troubleshoot and support the
applications.
75 How much of work is expected onsite by the PM? Or what is
the duration and frequency of time the PM is expected onsite
at State premises as mentioned on Page 66, Section H 55.5
These are small straight-forward applications and I anticipate little to no
on-site requirements for a PM.
76 What is the volume of work planned for 2015? See response to inquiry #6
77 Are support services required after delivery of all 5 modules
for a specific period? Or is it required per every occurrence
of issue that the support team/engineer is available
immediately?
The State is expecting the Vendor to support all applications on the site
for the life of the contract. These Vendor support resources should have
prior knowledge of the applications they are supporting. In prior
contracts the developers of the applications were also the supporters
throughout the contract and we will be expecting similar application
support knowledge and experience under this contract.
78 For how long (in days or months) is the total warranty
expected?
See RFP
79 Could you please include answers to all vendor questions
discussed in conference call in the Q&A document?
We informed Vendors they would need to submit their inquiries
electronically in writing for official response, so we will only be
responding to inquiries submitted.
80 Please post the Word copy of RFP and all Addendum and
Attachments if possible on website.
The State prefers not to release the entire RFP as a Word document. The
State will publish response tables in a Word extract.
81 Can the previous contract be published on the website
against this RFP listing page?
See response to inquiry #6
82 Is the Appendix H required to be completed and submitted
with response?
No
83 The wage claim module design documents are not released,
can we raise questions pertaining to it if any, later?
See response to inquiry #5
RFP 2015-099
DOL Web Development and Support - Questions and Answers
13
# PG.
NO.
SECTION
REFERENCE
QUESTION ANSWER
84 Is the Vendor allowed to submit the Financial Statements
separately within the due date of response to a State official
as it is sensitive information?
Financial statements may be submitted in a separate sealed envelope but
within the sealed package along with the proposals to the attention of
the State contact person (Joe Nadeau).
85 Page 5, Section 4-Instuctions - Is double side printing
allowed of the response?
Yes
86 Page 10, Section VIII mentions attaching a copy of RFP in
the response content ordering. Is it correct to understand it is
just the 91 pages or are other Attachment documents
a. Deliverable? 1A, 1B....etc. also required to be
submitted?
i. Are we to attach
all Attachment documents in Section IX: Appendix? What is
expected to be submitted by the vendor in Section IX a part
of the response?
The Vendor is required to provide copies of all documents in their
original form associated with the RFP posted to the Purchased and
Property website. This would include deliverables, reference
documents, addendums, etc.
These document copies are only required as part of the Vendor’s
original copy of their proposal.
No. Section IX is for additional materials or company literature that
may help explain the narrative answers.
87 Page 15, Section 5.3 - What is expected of Evaluation -
Product Demonstration, as this is an enhancement or support
service?
The template used for this RFP was derived from an RFP seeking a
COTS solution. There is no expected product demonstration. If the
Vendor is selected to provide demonstrations it will be to demonstrate
their ability to provide the services as defined in the RFP.
88 Is a COTS envisaged that selected functions maybe
customised and used?
We are expecting a custom developed solution that meets the
requirements in the RFP.
89 Page 22, Section A.3.point (c), is it correct to understand that
Proof of Insurance need be submitted/complied with only at
time of contract? We may agree that we abide by Appendix
H and we can submit Proof of Insurance if signing a
contract. Is this fine?
Yes to all
90 Ref: Page 28, What are the legacy systems that interface with
Module 3, 4 (FROI & Wage Claim)? We would like to have
some details explained (environment, function) etc. in case it
has to be accommodated in any development effort.
The web interface to the NHDOL legacy system for the deliverables
under this RFP are strictly limited to a transfer to the State’s FTP server.
RFP 2015-099
DOL Web Development and Support - Questions and Answers
14
# PG.
NO.
SECTION
REFERENCE
QUESTION ANSWER
91 Page 39, Section E -2 - Our consultants whom we intend to
propose are on other projects currently hence is it allowed
that we supply representative samples of resumes. At time of
actual contract we shall deploy exact match or near similar
candidates
a. Please specified the profiles for which specifically
actual resumes are required
The State will be seeking the actual resumes of the Vendor key staff
that will be on the NHDOL Web project.
92 Page 44-45, Section F-2 - Why is it that the hours per
resources are required in Tables - E2 & F2 when the cost
pricing is an NTE in Table F1?
The State has determine this information to be valuable in past RFPs
and has made it standard practice in all RFPs.
93 Page 49, PCC DSS Payment Application Data Security
Standard – does it have to be acknowledged and signed?
None of the current deliverables or currently planned future deliverables
require payment collection, so any PCI compliance language does not
require acknowledgment or signing. We do anticipate possible future
applications requiring collection of payments so we do include PCI
experience and knowledge as a weighted criteria.
94 Page 66, Section H-25.3 -What is the total budget of the
contract (3 years) out of this RFP?
See response to inquiry #6
95 Page 71, Section H-25.10.3 How long is the warranty
required? Is it 30 days (defined days) after each module
delivered ?
Deliverables 1 & 2 may have a combined warranty period because of
their dependency to each other. Deliverables 3, 4 and 5 will each have
their individual warranty periods. These warranty periods are described
in H-25.10 of the RFP.
96 Page 72, Section H-25.11 What are the support services
required ? Is it going to be any general web application
support service in a per hour rate format?
Support services are break/fix services.
97 Page 82, Section H.25. 15.2-Limitation on Liability – Is it
allowed that we can change the terms to a 100% of the
Contract fee against the cap set at 1.5 times the Contract.
The state will not change this language
98 General Is it correct to understand the .Net version to be used is 4.5?
Any specific version of Microsoft .Net to be used for
development
The state servers have .NET framework 4.5 loaded; however, the
imitation is that the WSD group only has Visual Studio 2010 which
uses .NET Framework 4.0.
99 General How would the User Account Management module data
interact with the web application? See response to inquiry #55
RFP 2015-099
DOL Web Development and Support - Questions and Answers
15
# PG.
NO.
SECTION
REFERENCE
QUESTION ANSWER
100 General What are the types of files being transferred from legacy
IBM system and the Document Management system? Please
confirm if it is only text files?
The FROI and Wage Claim deliverables contains a requirement to
extract records from the respective tables, generating text files and
transferring these text files to an FTP server for pick-up by a legacy
system process. The legacy system process is outside the scope of any
deliverable within this RFP.
101 General How are emails being sent from the website? The application will use an email relay server.
102 General How is single sign-on implemented? Single sign-on refers to a public user who must authenticate into
multiple agency web sites. This single sign-on application which can be
shared across all agencies for authentication into their web sites allows
for an individual to have s single user name and password for all access
into all State of NH web site applications.
103 General Is single sign-on available for both external and internal
users? Yes. Every State resource has a State-wide account they used to submit
time sheets, leave requests, maintain their HR data. NHDOL internal
users will be using this same state-wide account to access into the
NHDOL internal applications.
104 General Does the landing page for internal users vary according to
the user/role or is it a single landing page for all the users? It is a single landing page for all internal users.
105 Public Side Deliverable
1.A
Page 5-Business requirement –Section 5.1 Point 1.4 - Are
the FAQs static contents?
106 Public Side Deliverable
1.A
Page 5-Business requirement – Section 5.1 Point 1.5 to 1.6
Any option/provision for the users to edit the inquiry after
submitting the same?
No
107 Public Side Deliverable
1.A
Page 5-Business requirement – Section 5.1 Are there any
audit trails required? Only those event tracking records defined in the business requirements
and functional designs.
108 Admin Side Deliverable
2.A
Page 6-Business requirement – Section 5.1 Point 1.2 Is
there any dashboard for the Admin users who will respond
to the inquiries?
No
109 Admin Side Deliverable
2.A
Page 12-Business requirement – Section 5.1 Point 1.14
Maintain Business Application Address Services – Is this a
common service?
Yes, We see this being used by multiple applications in the future.
RFP 2015-099
DOL Web Development and Support - Questions and Answers
16
# PG.
NO.
SECTION
REFERENCE
QUESTION ANSWER
110 Admin Side Deliverable
2.A
Page 12-Business requirement – Section 5.1 Point 1.15
Event Logging Services – Is this going to be a common
service?
Yes, We see this being used by multiple applications in the future.
111 Admin Side Deliverable
2.A
Page 12-Business requirement – Section 5.1 Point 1.15 Error
Logging Services – Is this going to be a common service? Yes, We see this being used by multiple applications in the future.
112 Admin Side Deliverable
2.B
Page 8 – Functional Design Section 5.1.15 Permissions –
Kindly confirm if it is right to assume that the permissions
are set in User account management module (UAM)
Your assumption is confirmed. Permissions to internal users of
Deliverable 2 are provided by the System Admin through the UAM
application.
113 First Report of
Injury Deliverable
3.A
Page 6-Business requirement Section 5.1 Point 1.2 How and
when does the status of an FROI record change? This is laid out in the business requirements
114 First Report of
Injury Deliverable
3.A
Page 7-Business requirement Section 5.1 Point 1.2.8 - What
does incoming data mean? Incoming data in this instance would mean data entered in by the user
on the FROI web form.
115 First Report of
Injury Deliverable
3.A
Page 10-Business requirement Section 5.1 Point 1.7.1 What
is the difference between internal and external users? An internal user would be the FROI Admin and an external user would
be a public user submitting FROI records. Most external users are HR
staff working for NH employers tasked with submitting injury reports
for their employees.
116 Wage Claim Deliverable
4.A
Page 6-Business requirement Section 5.1 Point 1.2 How and
when does the status of a Wage claim record change? See response to inquiry #5
117 School to
Work (STW) Deliverable
5.A
Page 11-Business requirement Section 5.1 Point 1.10.1 –
Please explain what will happen if the STW request is not
processed in the time span set by the Admin?
Page 11-Business requirement Section 5.1 Point 1.10.1 – describes the
removing or deleting of records from the database. A STW request that
has not been processed would not meet the criteria for being deleted.
The time span set by the Admin is the time span between when the
STW request is processed to the point where it should be
removed/deleted.
118 20 Main RFP:
Appendix
A-Section A-1
Who is the contractor that developed the original 2001
system? Technology Management Resources (TMR)
119 20 Main RFP:
Appendix
A-Section A-1
Who is the contractor who has been redefining and
redeveloping applications since
2012?
Stellarware Inc
RFP 2015-099
DOL Web Development and Support - Questions and Answers
17
# PG.
NO.
SECTION
REFERENCE
QUESTION ANSWER
120 25 Main RFP:
Appendix
C-Section C-1
Scope of Work
“Applications will be developed in asp.net….”
What version of .NET?
Is C# acceptable?
.NET Framework 4.0 with Visual Studio 2010. C# is preferred.
121 25 Main RFP:
Appendix
C-Section C-1
There appears to be an incumbent vendor vis-à-vis the
User Account Management module.
Does the department intend to retain the services of
the UAM developer to support the application? Will
the UAM developer be available to provide guidance
on integrating with the UAM?
The incumbent vendor contract expires 06/30/2015. The contract does
not provide for the Vendor to continue support of the UAM or provide
guidance to other Vendor resources.
122 25 Main RFP:
Appendix
C-Section C-1
“Vendor will provide support…”
Will the successful vendor be given VPN access to
servers to facilitate development and support
activities?
No… access to the State environment will need to be in the presence of
a State DoIT resource either in-person or through the use of a
technology such as GoToMeeting.
123 25 Main RFP:
Appendix
C-Section C-3
Table C-3, last row on page
Table C-3 mentions web application support as a
deliverable.
Is this support for vendor-developed software or is
does this imply support for modules other than
developed by the bidding vendor?
See response to inquiry #3
124 49 Main RFP:
Appendix
G-Section G-
1-PCI DSS
Payment
Application
DSS
Is there a PCI vendor that NH already works with for
credit card processing? None of the current deliverables or currently planned future deliverables
require payment collection, so any PCI compliance language does not
require acknowledgment or signing. We do anticipate possible future
applications requiring collection of payments so we do include PCI
experience and knowledge as a weighted criteria.
125 1. In percentage terms, approximately how much of
the current business requirements of the department
were provided by the original system?
There were no documented business requirements from the original system, but we did use the original system to derive base functionality requirements.
126 What is the budget for the entire project? See response to inquiry #6
RFP 2015-099
DOL Web Development and Support - Questions and Answers
18
# PG.
NO.
SECTION
REFERENCE
QUESTION ANSWER
127 Is funding for the entire project currently available, or
do funds have to be allocated each fiscal year? See response to inquiry #6
128 4. If funds need to be allocated each fiscal year, in
which fiscal year is each of the 5 deliverables expected
to be delivered?
See response to inquiry #6
129 RFP
GENERAL
QUESTIONS
Can you provide the table definition for conversion
data? Unable to provide the definitions at this time.
130 RFP
GENERAL
QUESTIONS
6. We understand that the state operating
environment is .NET:
a. Which version(s) of the .NET framework are
supported?
We are currently working with .NET Framework 4.0 with Visual Studio
2010.
131 RFP
GENERAL
QUESTIONS
6. We understand that the state operating
environment is .NET:
b. Which version(s) of MVC are supported?
None. The application should be developed using webforms.
132 RFP
GENERAL
QUESTIONS
6. We understand that the state operating
environment is .NET:
c. Is there a preference for either C# (C-Sharp) or
VB.NET?
C#
133 RFP
GENERAL
QUESTIONS
6. We understand that the state operating
environment is .NET:
d. There appears to be some confusion regarding the
use of Javascript. For example, Deliverable 2B, section
5.1.2, states that the application must continue to
function even when Javascript is turned off. Yet
Deliverable 1B make no statement regarding the use
of Javascript, implying that, for deliverable 1B, there is
no restriction on the use of Javascript.
All applications must function when Javascript is turned off.
134 RFP
GENERAL
QUESTIONS
(1) Are all of the deliverables to be restricted as to the
use of Javascript? All applications must function when Javascript is turned off.
RFP 2015-099
DOL Web Development and Support - Questions and Answers
19
# PG.
NO.
SECTION
REFERENCE
QUESTION ANSWER
135 RFP
GENERAL
QUESTIONS
If the use of Javascript is restricted, is it acceptable to
have different pages for the same functionality, one
employing Javascript, the other restricting the use of
Javascript?
No.
136 GENERAL
QUESTION
A requirement that is stated in several places is the
following:
“As the user is entering text, the form should display a
continuous remaining character count, indicating to
the user exactly how many characters they have left
before reaching the maximum characters allowed”.
Does this feature need to be available even if
JavaScript is turned off?
No. If JavaScript is turned off then the application only needs to display
the number of characters allowed with the control.
137 Ref. R1: Web
Application
Development
Item 7. Source Control
Mentions 4 specific source control systems. Can Visual
SourceSafe be used for source control?
The State uses Harvest as its standard source control strategy and it also
uses Harvest as its central repository of all software/source code.
A State resource will manage the checking out an checking in of source
code from Harvest and then making it available to the Vendor. The
Vendor will need to coordinate with this State resource for the check-in
and check-out of source code.
138 Standards Item 10 Development Standards
Forbids the use of inline SQL. Is it acceptable to use
parameterized queries in an application?
All database work must be done with stored procedures per WSD
standards. Any exceptions would need to be justified.
139 Ref. R2: WSD
Supplemental
Standards
Item 4. Source Control
Mentions the use of CAHarvest for source control.
Can Visual SourceSafe be used for source control?
See response to inquiry #137
140 Ref. R3: WSD
Application
Database
Standards
Item 10 Triggers
There is no specific mention of database triggers.
Is the use of database triggers permitted?
Yes – but they must be well documented.
141 Ref. R3: WSD
Application
Database
Standards
Item 11 Assemblies
Other than for encryption and decryption, is the use of
database assemblies encouraged or discouraged?
They are neither encouraged nor discouraged. If the assembly is
justified and is proven to add to the functionality of the application than
it would be allowed. The assembly would be required to follow all
development standards.
RFP 2015-099
DOL Web Development and Support - Questions and Answers
20
# PG.
NO.
SECTION
REFERENCE
QUESTION ANSWER
142 Ref. R3: WSD
Application
Database
Standards
General question
What version(s) of SQL Server are
supported/required?
2008
143 Ref. R7: State
Server
Environment
Process
Flow
Descriptions
General question
The referenced document specifically mentions the
use of web services on the application server. Is it the
intent of the state that all new applications be based
upon SOA (Service Oriented Architecture)?
Yes.
144 Ref. R8: UAM
Technical
Summary
General questions
1. Will the state provide the successful vendor with a
functional copy of UAM and its related database to
facilitate off-site development?
Yes
145 Ref. R8: UAM
Technical
Summary
2. Is the Technical Summary accurate as provided?
Will the state provide the successful vendor with an
updated reference to UAM?
Yes
146 Del. 3A-FROI
Business
Requirements
-
Section 3
What does the following statement refer to:
“Standard paging will be ten (10) pages unless
otherwise specified.”
This is a standard requirement we tried to place into all business
requirements whether it pertained or not. This requirement sets the
standard on a scrolling page to 10 records per page, such as a search
page, where 300 records could meet the criteria.
147 Del. 1A-
Contact DOL
Pub- business
Reqs.-
Section 6.1
(Acceptance
Criteria)
Criteria ID #1 Measurement states: “Stellareware to
provide State with Penetration Security Analysis
report indicating a State acceptable level of security.”
Please elaborate on the role that Stellarware will play
in penetration testing of the selected vendor’s
software.
See response to inquiry #47
The contract awarded vendor will be responsible for Penetration
Security Testing.
RFP 2015-099
DOL Web Development and Support - Questions and Answers
21
# PG.
NO.
SECTION
REFERENCE
QUESTION ANSWER
148 Del. 1B-
Contact DOL
Pub.-
Functional
Design- 5.5.1
Stellarware
Testing
Section 5.5.1 reads as follows:
“Stellarware will test to assure application meets all
identified business requirement functions/features to
assure compliance before being submitted to NHDOL
for State Testing. Stellarware will also provide proof of
application passing security analysis before being
submitted to NHDOL for testing.” Please elaborate on
the role of Stellarware with regard to the testing of
the selected vendor’s software.
See response to inquiry #47
The contract awarded vendor will be responsible for testing of the
application to assure it meets all requirements..
149 Del. 1B-
Contact DOL
Pub.-
Functional
Design- 5.7.3
Application
Setup
Section 5.7.3 states:
“The presentation and application layer will have
separate Visual Studio projects. Each layer will be
compiled separately. The compiled version for
presentation layer will be copied to the public server
and the compiled version of the application layer will
be copied to the application server where the
web.config file will be configured to use the unique
user account to access the SQL 2008 database hosted
on the database server.” Please elaborate on this
framework.
The environment has three servers. Database, application and web. The
database server hosts all databases utilizing MS SQL 2008. The
application houses WCF/Web services the application will use to
communicate between the application front end and the database. The
web server will host the web application front end.
150 Del. 4A-
Wage Claim-
Business
Requirements
-
1.2.2 Comment states: “See event logging interface
with the NHDOL UAM Technical Documentation.”
We were not able to find reference to the event
logging interface in the UAM documentation. Will this
be provided prior to the bid closing?
See response to inquiry #5
151 E-1.1.1 We are interested in responding to your Request for
Proposal for Web Development & Support. In the RFP
it mentions experience working in New Hampshire.
Can you tell me if preference is given to organizations
located in New Hampshire?
Discuss the firm’s commitment to the public sector, experience with
this type of Project Implementation and experience in New Hampshire.
I found the above sentence and we do not give preference to
organizations in New Hampshire or organizations that have done
business in New Hampshire. The above sentence was on oversight and
most likely generated from an improper find and replace on the original
template.
RFP 2015-099
DOL Web Development and Support - Questions and Answers
22
DOL RFP 2015-099 Vendor Conference Roster
Abilis
Alkyha Defense and Logistics Inc (A.D.L. INC.)
BlumShapiro
ClarusTec, Inc.
Collaborative Consulting, LLC
Kyran
Left To My Own Devices Computer Solutions
Member 3GS LLC
Next Generation Technology, Inc
Oxagile
Revenue Solutions, Inc.
SevenOutsource
Stellarware Inc
Voyager Systems, Inc
Zco Corporation
BIDDER _______________________________________ ADDRESS _________________________________
BY _______________________________________________________________________________________
(this document must be signed)
_____________________________________________ TEL. NO.___________________________________
(please type or print name)
FINAL
Use
r
Acc
oun
t
Management (UAM)
Functional Design Phase
Functional Design Document
10.01.2013
Version 1.0
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
2
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
3
TABLE OF CONTENTS
1. INTRODUCTION................................................................................................................. 5
1.1 USING THIS DOCUMENT ................................................................................................... 5
1.2 PURPOSE .......................................................................................................................... 5
1.3 BUSINESS OWNERS AND CONTACTS................................................................................. 5
1.4 SIGNOFFS ......................................................................................................................... 5
1.5 REVISION HISTORY .......................................................................................................... 5
1.6 REFERENCED DOCUMENTS .............................................................................................. 6
1.7 DEFINITIONS, ACRONYMS AND ABBREVIATIONS ............................................................. 6
2. PROJECT OVERVIEW: ..................................................................................................... 7
3. ASSUMPTIONS, CONSTRAINTS AND SCOPE: ........................................................... 7
4. PROCESS FLOWS. .............................................................................................................. 8
4.1 CURRENT PROCESS WORKFLOW ...................................................................................... 8
4.2 DESIRED/PROPOSED PROCESS WORKFLOW ...................................................................... 8
5. FUNCTIONAL DESIGN ..................................................................................................... 8
5.1 FUNCTIONS/FEATURES ............................................................................................. 8
5.1.1. SecureAuth .............................................................................................................. 8
5.1.2.1 Management ............................................................................................................ 8
5.1.2.2 Implementation ....................................................................................................... 8
5.1.2.3 Realms ..................................................................................................................... 9
5.1.2.4 Cookie ..................................................................................................................... 9
5.1.2.5 Data Sharing ........................................................................................................... 9
5.1.2.6 User Messages ...................................................................................................... 11
5.1.3 Applications - Administrative ................................................................................... 11
5.1.3.1 Application Data ................................................................................................... 11
5.1.3.2 UserDisabled ........................................................................................................ 12
5.1.3.3 Disabled ................................................................................................................ 12
5.1.3.4 UserDisabled/Disabled Process ........................................................................... 13
5.1.3.5 Data Modification ................................................................................................. 13
5.1.4 Internal Applications ................................................................................................ 13
5.1.4.1 User Login ............................................................................................................ 13
5.1.4.2 Create Application Session ................................................................................... 13
5.1.4.3 Administration Menu ............................................................................................ 14
5.1.4.4 User Menu ............................................................................................................. 14
5.1.4.5 Request Permissions ............................................................................................. 15
5.1.4.6 Applications Page ................................................................................................. 16
5.1.5 External Applications................................................................................................ 16
5.1.5.1 User Login ............................................................................................................ 16
5.1.5.2 Create New Account ............................................................................................. 16
5.1.5.3 Create Application Session ................................................................................... 17
5.1.5.4 Jump Page ............................................................................................................. 17
5.1.5.5 Requested Page ..................................................................................................... 17
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
4
5.1.5.6 Profile Page .......................................................................................................... 19
5.1.5.7 Application Unavailable/Error page .................................................................... 21
5.1.5.8 Applications Page ................................................................................................. 21
5.1.5.9 Request Permissions ............................................................................................. 21
5.1.6 Applications/UAM Communications ........................................................................ 21
5.1.6.1 User Check ............................................................................................................ 21
5.1.6.1.1 Parameters ........................................................................................................ 21
5.1.6.1.2 Returned dataset ............................................................................................... 22
5.1.6.1.3 Status Values ..................................................................................................... 22
5.1.6.1.4 Log Out ............................................................................................................. 22
5.1.6.1.5 Terminate Session ............................................................................................. 22
5.1.6.1.6 Application ........................................................................................................ 23
5.1.7 User Management ..................................................................................................... 23
5.1.7.1 AccountType .......................................................................................................... 23
5.1.7.2 AccountStatus ........................................................................................................ 23
5.1.7.3 Search ................................................................................................................... 23
5.1.7.4 Users ..................................................................................................................... 24
5.1.7.4.1 Add .................................................................................................................... 24
5.1.7.4.2 Edit .................................................................................................................... 25
5.1.7.5 User Permissions .................................................................................................. 26
5.1.8 General ..................................................................................................................... 26
5.1.8.1 Configuration File values ..................................................................................... 26
5.1.8.2 User Validation ..................................................................................................... 26
5.1.8.3 Querystring Values ............................................................................................... 26
5.1.8.4 Textarea ................................................................................................................ 26
5.1.8.5 Page Look ............................................................................................................. 26
5.1.8.6 NHDOL Events Requiring Logging ...................................................................... 26
5.1.8.7 Error Handling ..................................................................................................... 27
5.1.8.8 Validation Error Messages ................................................................................... 27
5.2 DATA CAPTURE, STORAGE, CONVERSION, AND EXCHANGE ....................... 27
5.2.1 Database Design ....................................................................................................... 27
5.2.2 Application Session Cleanup .................................................................................... 27
5.3 HARDWARE AND SOFTWARE PLATFORM ......................................................... 27
5.4 OUTPUT / REPORTS .................................................................................................. 27
5.5 TESTING/TRAINING ................................................................................................. 28
5.5.1 Stellarware Testing ................................................................................................... 28
5.5.2 User Acceptance Testing........................................................................................... 28
5.5.3 State Code Review and Acceptance Testing ............................................................. 28
5.5.4 Training..................................................................................................................... 28
5.6 SECURITY ................................................................................................................... 28
5.6.1 Application Security .................................................................................................. 28
5.6.2 Database Security ..................................................................................................... 28
5.6.3 Encryption ................................................................................................................. 29
5.6.4 SSL ............................................................................................................................ 29
5.7 IMPLEMENTATION ................................................................................................... 29
5.7.1 Deployment Package ................................................................................................ 29
5.8 PERFORMANCE AND RESPONSE TIME ................................................................ 29
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
5
5.9 DATA ARCHIVAL AND BACKUP ........................................................................... 29
Data archival and backup will be done in accordance to NH DoIT WSD existing policies. 29
5.10 MISCELLANEOUS/OTHER ....................................................................................... 29
5.10.1 Time Estimate........................................................................................................ 29
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
6
1. INTRODUCTION
1.1 Using this Document
The Functional Design for software systems should be customized to the needs of the project building the system.
This template is one of many documents related to this software development project. It is organized such that it can
be a single stand-alone document or combined with other Functional Design Phase documents, i.e. Business
Requirements, Solution Alternatives, based on the particular needs of the project. Please refer to Section 1.6
Referenced Documents for a listing of additional project-specific documentation.
1.2 Purpose
This document describes in non-technical terms the system’s functions and features that are needed to satisfy the
business requirements. This document will be composed by the DOIT Technical Team with assistance and
validation from Customer/User as needed. The Functional Design will provide further explanation of how all of the
Business Requirements will be met. When completed, Customers/Users will understand how the system will
operate so that it supports the business needs. The Functional Design document provides sufficient information for
DOIT to evaluate and recommend potential solutions (i.e., commercial off-the-shelf – COTS, or custom
development) to the Customer/User.
1.3 Business Owners and Contacts
Name Email Phone Role
Joe Nadeau [email protected] 603-271-6872 Project Manager Mary Hillier [email protected] 603-271-8308 NHDOL Web Administrator Kathryn Barger [email protected] 603-271-3599 Director of Workers Comp Division Kathy Kane [email protected] 603-271-6194 Assistant Director of Workers Comp
Division Michele Small [email protected] 603-271-3119 Administrator of Inspection Division
1.4 Signoffs
Name Date Signature
1.5 Revision History
Date Reason for change(s) Author(s)
10/02/2013 Rebecca Gamache
1.6 Referenced Documents
Document Version/Date Author(s)
Business Requirements Document 06/28/13 Joe Nadeau/Mary Hillier SecureAuth Documentation October 19, 2012 R. Gamache
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
7
HZNSNHVHS Environment Diagram.pdf February 6, 2013 R. Gamache HZNSNHVHS Environment Process Flow
Descriptions.doc
February 6, 2013 R. Gamache
UAM Processes October 14, 2013 R. Gamache UAMDatabase.pdf October 14, 2013 R. Gamache
1.7 Definitions, Acronyms and Abbreviations
ASP.NET Web application framework used for this project
Entity Framework ASP.NET framework using LINQ for SQL databases
External SecureAuth The State’s customized application of SecureAuth used for authenticating DOL
external users against account data stored and managed through the database
associated with the External SecureAuth application.
IIS Internet Information Services: web server application used on the Windows server
Internal SecureAuth The State’s customized application of SecureAuth used for authenticating DOL
internal users against State network active directory credentials.
Jump Page Application page displayed to the user prior to logging into the NHDOL
application
Landing Page Application page displayed to the user after logging into the NHDOL application
LINQ ASP.NET library used for querying the database
LDAP Lightweight Directory Access Protocol
MVC Model-View-Controller: ASP.NET programming model
NHDOL New Hampshire Department of Labor
NHDOL Application A portion of the NHDOL site that is hosted on the application server and collects
information from users
NHDOL Static Site A portion of the NHDOL site that is hosted on the content server and does not
collect information from users
SecureAuth State's single sign on solution
SQL Relational database
Stellarware Contracted vendor to develop this UAM module
UAM User Application Management module
Web Services As used here, stand alone applications that provide communication between Web
applications and the database.
NH DoIT New Hampshire Department of Information Technology
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
8
2. PROJECT OVERVIEW:
NHDOL has requested a module that is part of a larger project and manages the user accounts, sessions and
applications on the NHDOL web site. This solution will allow NHDOL system administrators to set permissions on
accounts, enable and disable user accounts and view account activity. It will also allow NHDOL system
administrators to manage application availability and information. These applications, which are not yet developed,
will be able to tie into this solution, using parameters that define and control access to users and application
functionality and data.
3. ASSUMPTIONS, CONSTRAINTS AND SCOPE:
Development of this solution will be done in compliance with all state standards, pass an application security
analysis and also pass a code review by State staff on state standards and best practices. At the time of this
document, the state's database standards have not been finalized. Industry standards and best practices for SQL
databases will be used instead.
The solution will use the NHDOL page design template.
The solution will require browsers with cookies enabled and will work without javascript. The version without
javascript may handle certain tasks slightly differently due to limited browser functionality.
Internal users will authenticate using interfaces with the Internal SecureAuth application. The SecureAuth
application will authenticate the internal users against their State network active directory credentials. This means
the log in attempts by internal users will follow and take advantage of the State network settings for lock-outs etc.
This means this UAM module does not need to handle locking of user accounts when repeated authentication
attempts fail.
External users will authenticate using interfaces with the External SecureAuth application. The External SecureAuth
application will authenticate the external users against their account credentials stored and managed on the External
SecureAuth database. The External SecureAuth application will manage and maintain generic external user profile
data which will be made available to DOL applications through queries. This portion of the External SecureAuth
application will manage log in attempts by external users relinquishing this UAM module from any lock-out
processing.
Stellarware, as developer of this solution, will integrate this solution with SecureAuth. State will be responsible for
administration and configuration settings involved in managing SecureAuth.
As more applications are developed for DOL the set of permissions in this module will expand. It is also possible
that the functionality of this application will expand.
This solution will be developed independently of any specific NHDOL Web application. References may be made to
NHDOL web applications currently in development or slated for future development to help illustrate desired
functionality.
External web applications will be hosted on a separate Web server from the NHDOL static web site and NHDOL
internal web applications.
Search screen paging will default to ten (10) records per page unless otherwise specified.
The production environment will use a single database server. Database interactions between both the external and
internal web applications will be executed through either WCF or Web Services on the Application Server.
Inquiries Safety FROI App 1 App 2
UAM
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
9
Stellarware will develop the WCF or Web Service module required for all interfaces with the NHDOL applications
database.
NHDOL static web site (www.nh.gov/labor) will serve as the primary point of entry for external users. Secondary
entry points to access the NHDOL applications will be allowed.
NHDOL will provide all content for messages displayed to user either on screen or through email, as in the
activation process.
Stellarware will provide scripts for installation of database and application components on the State’s infrastructure.
State will install and implement the administration application and database on their servers.
State will be responsible for maintenance and backups of the solution and database.
State will maintain the repository of source code for version control.
The following issues will need to be addressed in future application and/or UAM development:
Dropdown/lookup list maintenance for UAM and applications
Applications accessing dropdown/lookup lists
Applications accessing user addresses
Multiple user addresses
4. PROCESS FLOWS.
4.1 Current Process Workflow
The current application process is not being used to determine the functionality of the application.
4.2 Desired/Proposed Process Workflow
The process flows represent the general flow of the application at various points. These will be described in
greater detail throughout the document. See UAMProcesses.pdf
5. FUNCTIONAL DESIGN
5.1 FUNCTIONS/FEATURES
5.1.1. SecureAuth
5.1.2.1 Management
The management of the SecureAuth environment is the sole responsibility of NH DoIT.
5.1.2.2 Implementation
To implement SecureAuth for users accessing DOL applications the following will be done in the
configuration file:
Authentication mode set to forms
External : <forms
loginUrl=https://dev.sson.nh.gov/secureauth41/SecureAuth.a
spx name=".bosKey" protection="All" path="/" timeout="30"
domain="nh.gov"/>
Internal: the internal SecureAuth realms have not been finalized at the time this document
was written. The necessary information will be provided to NHDOL when available.
httpCookies requireSSL set to true
Machine key added
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
10
External: <machineKey
validationKey="08B552069684FA0771A6734A50629424FAF77EFAB84
95C7C97384F51E26C9FCB5444F69C1F8EEE9D005204DF08CE77FE70ACE
45107119FAD5C5388EC43989234"
decryptionKey="674F9747954667895E0C2AB1EC9ADA5A84DCD6CD1BF
5944F" validation="SHA1"/>
Internal: the internal SecureAuth realms have not been finalized at the time this document
was written. The necessary information will be provided to NHDOL when available.
Authorization set to allow all users
To access SecureAuth the application will need to redirect the user to SecureAuth with a Querystring
parameter of ‘target’ that is the return url. FormsAuthentication.RedirectToLoginPage("target=<URL WHERE USER
IS RETURNING TO>”)
Production values for SecureAuth URL’s will be made available to NHDOL by NHDoIT when needed.
5.1.2.3 Realms
External applications will use the existing SecureAuth realms provided by the Business One Stop
application. This implementation is a self-service account management. Users will be able to create their
own accounts, change passwords and update data.
Internal applications will use a new SecureAuth implementation that uses the NHDOL active directory to
authenticate users. This implementation will only use the active directory to authenticate users.
5.1.2.4 Cookie
The cookie that is created by SecureAuth is only valid for a certain amount of time. At the time this
document was written the value was 10 minutes. The only data available in the cookie is the username.
For external users the username is the users email address and for internal users the username is the state
login username.
5.1.2.5 Data Sharing
NH DoIT is in the process of developing WCF services for applications to connect to SecureAuth and
retrieve data. Each application will be assigned an identification number and encryption salt. This
information, along with SecureAuth authentication parameters, will be passed from the UAM to the
SecureAuth WCF Service. The following services will be provided:
Retrieve UserID by UserName
Retrieve user record by UserID
Retrieve user records by search of either username, first name, last name or email
Each call will require the UAM to pass additional credentials and the SecureAuth source. NH DoIT will
provide all necessary connection information when the WCF services are completed. Below are the
proposed calls.
Return a user id based on the username passed in.
Parameters: applicationId Type: GUID *required
secureAuthSource Type: string *required, encrypted
authUsername Type: string *required, encrypted
authPassword Type: string *required, encrypted
iv Type: string *required
username Type: string *required
Result: userID Type: GUID
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
11
Returns a single record for a user based on the user.
Parameter: applicationId Type: GUID *required
secureAuthSource Type: string *required, encrypted
authUsername Type: string *required, encrypted
authPassword Type: string *required, encrypted
iv Type: string *required
userId Type: GUID *required
Results: One record set
Format: See Below
Returns one or more records for users based on one or more parameters passed in. At least one or
more of these parameters must be passed in.
Parameters: applicationId Type: GUID *required
secureAuthSource Type: string *required, encrypted
authUsername Type: string *required, encrypted
authPassword Type: string *required, encrypted
iv Type: string *required
username Type: String **
firstName Type: String **
lastName Type: String **
email Type: String **
Results: One or Many record sets
Format: See Below
The format for the data (record sets) that can be returned in reponse to calls to functions defined in
items 5.1.4 and 5.1.5 will be XML. This will ensure that most requesters will be able to utilize the
data.
Each node for the recordset will have the following format :
<?xml version="1.0" ?>
<users>
<user>
<userid></userid>
<username></username>
<firstname></firstname>
<lastname></lastname>
<email></email>
<phone1></phone1>
<phone2></phone2>
</user>
</users>
Note : repeat user nodes for multiple user records.
5.1.2.6 User Messages
When users leaves the UAM for SecureAuth to create an account will be presented with the following
message which they will have to confirm:
The Department of Labor web site is sending you to the State of New Hampshire single sign-on
application to create a State-Wide account.
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
12
Please be aware creating an account is not the equivalent of logging in. When you have completed
creating your account you must exit the Create Account application and click the Log-In selection on the
NH Department of Labor site to log-in.
Thank you for your patience.
5.1.3 Applications - Administrative Applications are added programmatically by developers, not through a user interface in the UAM internal site.
Stored procedures and the necessary SQL scripts will be created to add application data. This will be done as
part of the UAM development for developers of future NHDOL applications. UAM administrators can modify
the application data only.
5.1.3.1 Application Data
The following information will be collected about the application. The page display, validation and error
message only apply to the UAM administrative users updating the application data.
Field Description Page Display Field Type Validation Error Message ApplicationID System
generated
identification
N/A N/A N/A N/A
Code Abbreviated
name for
application
Code Required.
^.{1,20}$
Code is required.
Code cannot be
greater than 20
characters in length. Title Full title of
the
application
Title Textbox Required.
^.{1,75}$
Title is required.
Title cannot be
greater than 75
characters in length. Description Description
of
application.
Description Textarea Required.
^.{1,1000}$
Description is
required.
Description cannot
be greater than 1000
characters in length. Internal Flag to
determine if
application is
internal.
Default = 0
Internal Appl
ication
Radio Buttons
(yes/no)
Required Internal is required.
UserDisabled System is
shut down for
all users
except
specified
administrative
users.
Default = 0
Disable
Application
Radio Buttons
(yes/no)
Required Disabled is required.
Disabled Application is
shut down for
all users.
Default = 0
Shut
Down Applic
ation
Radio Buttons
(yes/no)
Required Shut Down is
required.
DisabledMessageTitle Message title Disabled/Shu Textarea Required. Disabled/Shut Down
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
13
to display to
users when
system is
disabled.
t Down
Message
Title
^.{1,200}$
Message Title is
required.
Disabled/Shut Down
Message Title
cannot be more than
200 characters in
length. DisabledMessage Message to
display to
users when
the system is
disabled.
Disabled/Shu
t Down
Message
Textarea Required.
^.{1,2000}$
Disabled/Shut Down
Message is required.
Disabled/Shut Down
Message cannot be
more than 2000
characters in length. Note (EventLog) Update the
event log for
reason
application is
being shut
down
Reason Textbox Requried
^.{1,200}$
Reason is required.
Reason cannot be
more than 200
characters in length.
URL URL for
application
URL Textbox Required.
^(http|https):\/\/
[\w\-_]+(\.[\w\-
_]+)+([\w\-
\.,@?^=%&am
p;:/~\+#]*[\w\-
\@?^=%&
;/~\+#])?
URL is required.
The URL must be in
the fomat http(s):\\ xxx[.xxx].xxx.
JumpPageMessage Message to
display to
users on the
application
jump page
regarding the
application.
Jump Page
Message
Textarea Required.
^.{1,2000}$
Jump Page Message
is required.
Jump Page Message
cannot be more than
2000 characters in
length.
5.1.3.2 UserDisabled
The application can be shut down for all users except UAM Administrative users. The application will
only be shown on application menu or listing for UAM administrative users.
5.1.3.3 Disabled
The application can be shut down for all users. The UAM will display the disabled title and message to
the users. The application will not appear on any application menu or listing.
5.1.3.4 UserDisabled/Disabled Process
Only one of the disabled options can be selected at a given time. The application should automatically
switch the selection when the user tries to activate both the UserDisabled and Disabled option. If both are
selected and the application cannot automatically switch the selection the following error message must be
returned to the user "Select either the Disable Application or the Shut Down Application feature.”
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
14
Once either of the options are selected the disabled title, message, and reason control will be made
available the user. The validations for these controls are only valid when either of the disabled options are
selected.
An entry into the event log will be made when an application is disabled and when the application is
enabled. Use the following table to determine the appropriate information to include in the event log
entry.
Type Event Note UserDisabled Application Disabled Reason entered into field Disabled Application Disabled All Users Reason entered into field Application
Enabled
Application Enabled Application has been enabled for all users.
5.1.3.5 Data Modification
When any of the application data fields are modified then an event log entry will be made. The update
will be for each field not for each update. The event log Event = Data Modifaction and Note = "field
name has been updated. Value = previous value of field". The developer will provide the field name and
the previous value.
5.1.4 Internal Applications
5.1.4.1 User Login
The user will proceed directly to SecureAuth before accessing the UAM. The SecureAuth process is
external to this application and is already explained in this document. See 5.1.1
Check Cookie: Cookie is valid if it exists. Extract data from cookie and use it to retrieve user data from
SecureAuth.
Check user (after SecureAuth authentication) : Does the user exist. The UAM will not check for specific
permissions only that the user has permissions to the application. If user is disabled then the user will be
shown the following message :
"The Department of Labor web site has detected an issue with your account. This issue is preventing the
site from any further processing under this account. Please contact the NH Department of Labor Web
administrator at 603-271-8308 or at [email protected] for assistance in rectifying this issue
We apologize for the inconvenience.”
The email address is an active link.
Log Entry: Create a log entry for the user log in. Event: UAM Login and Note = “User logged in”. The
application ID for this entry is for the UAM.
Display appropriate menu page.
5.1.4.2 Create Application Session
A user application session will be created for each user within the UAM. This session will be used to
authenticate the user for the NH DOL applications. The user application session is created and maintained
by the system without any user interaction. Each time the user application session is checked the
LastAccessed date will be updated to the current date/time.
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
15
5.1.4.3 Administration Menu The system admin menu page will only be displayed to internal users who are system administrators. The
page will contain a menu that includes application management, user management and applications the
use has access to.
The system admin menu page will display a link to go to the application menu page.
The system menu page will display a Log Out link.
The system menu page will display a link to view all applications.
5.1.4.4 User Menu The application menu page will be displayed to all internal users who are not system administrators upon
successful login. The page will list only the internal applications the user has permissions to access.
An internal user will be able to select an application from the menu and the UAM will direct the user to
the target application.
Each request within the internal application will be evaluated by the UAM to ensure the user has an active
account and the correct permissions for the application and requested functionality. A log entry will be
created. Event: Application Login and Note = "User logged in” Application ID will be application user
is accessing.
The application menu page will display a Log Out link. If the user is a system administrator, the menu
page will also display a link to go to the system administrator menu page.
The application menu page will display a link to view all applications.
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
16
5.1.4.5 Request Permissions
Display the following to the user when he/she does not have the necessary permission to access the
application :
“The Department of Labor web site has detected an issue with your account. This issue is preventing the
site from any further processing under this account. Please contact the NH Department of Labor Web
administrator at 603-271-8308 or at [email protected] for assistance in rectifying this issue
We apologize for the inconvenience.”
Future development of the UAM will include an interactive application users can use to request
permission to specific applications.
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
17
5.1.4.6 Applications Page
This page will display all available applications with notation on the applications the user has access to.
Each application will display the title and description. The title will be a link to the application. The use
can also navigate to this page from the menu page.
This page will display a link to log out.
5.1.5 External Applications
5.1.5.1 User Login
The SecureAuth process is external to this application and is already explained in this document. See
5.1.1
The following steps are part of the jump page logic :
Validate application
Check for existing session: Using the session identification retrieve user information.
Validate user (see Check User below)
Check Cookie: Cookie is valid if it exists. Extract data from cookie and use it to retrive user data from
SecureAuth.
Check user: Does the user exist, is it active and does the user have the correct permissions. The UAM
will not check for specific permissions only that the user has permissions to the application. If the
application does not have specific permissions then the UAM will consider any user a valid user for
the application. If user is disabled then the user will be shown the following message :
"The Department of Labor web site has detected an issue with your account. This issue is preventing
the site from any further processing under this account . Please contact the NH Department of Labor
Web administrator at 603-271-8308 or at [email protected] for assistance in rectifying
this issue
We apologize for the inconvenience.”
The email address is an active link. If the user does not exist a new account will need to be created
(see 5.1.5.2). If the account has been requested then the user will be redirected to the requested page
(see 5.1.5.4)
Log Entry: Create a log entry for the user log in. Event: UAM Login and Note = “User logged in”. The
application ID for this entry is for the UAM.
Disabled: if the application is disabled for all users send user to application unavailable page.
Log Entry: Create a log entry for the user log in. Event: Application Login and Note = “User logged in” .
Application ID will be application user is accessing.
Create user application session: see 5.1.5.3
5.1.5.2 Create New Account
This process is automatic without any input from the user.
The information retrieved from SecureAuth will be used to create an account. The following information
will be used:
Field Value UserID System generated SecureAuthID Retrieved from
SecureAuth Organization Null Title Null
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
18
Internal 0 AccountStatusID Value for ‘Requested’ AccountTypeID Value for ‘Unknown"
UserID will be returned to the application for future use.
Enter event log : event = "New User" and note ="New User Created"
Assign user any default permissions for the application.
View/Edit profile data (see 5.1.5.6)
Redirect user to the Requested page (see 5.1.5.5)
5.1.5.3 Create Application Session The UAM will maintain session data for each active authenticated user on the internal and external
applications.
When a session is created, the UAM will generate a session ID that is used as a key for identifying a
session. The session ID will be passed to the NHDOL applications to access stored session data in the
UAMSessions table:
Application Session ID: System created id value.
UAM User ID: foreign key referencing the user record.
UAM ApplicationID: foreign key referencing the application the user is currently accessing.
IP Address: IP address of the user.
Last Access: date/time stamp the user last accessed the application. This stamp updates with each
request made within the session.
Salt: value used to encrypt IP address
The UAM will monitor user activity and reset the session expiration setting based on the maximum
session time-out value stored in the configuration file.
The UAM will use all requests initiated from within the UAM or NHDOL applications as a method to
monitor user activity for the purpose of resetting the session expiration time.
5.1.5.4 Jump Page
The jump page will display specific application information including the title, description, and jump page
message.
If the user is not logged in then it will also display SecureAuth instructions pertaining to creating an
account and logging into the system.
URL to the jump page will be as follows : https://url?a = xxx where xxx is the encrypted application ID.
5.1.5.5 Requested Page
This will serve a dual purpose: to send the activation email to the user and to to finalize the activation.
If the user just requested the account then the application will create and send an email to the user. The
link contained in the email will activate the account. The email information is below :
To : user email
From : NHDOL group email (tbd later)
Subject : NH Department of Labor account activation
Body
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
19
“A NH Department of Labor Web Account has been requested using this email address. To confirm
your email address and activate your NH Department of Labor Web Account, click on the link
below.
<NH Department of Labor Activation Link>?a=xxx;u=xxxx (a = application ID and u = user ID;
both will be encrypted)
After you have activated your account, you will need to log in to use NH Department of Labor
Online Reports and Services.
If you did not request a NH Department of Labor Web Account, please contact the NH Department
of Labor Web administrator at 603-271-8308 or at [email protected].”
Once the email has been sent the following will be displayed: “Your NH Department of Labor Web Account is not yet active.”
“An email has been sent to the email address you used when setting up your account login credentials.
The email contains an activation link. You will need to open the email and click on the link to activate
your account. Once you have activated your account, you will need to log in again to access the
application title page.”
“If you do not receive the activation email within the next 15 minutes, please check with your email
provider to be sure that no blocking is in place. If your email service provider has not blocked the
email, contact the NH Department of Labor Web Administrator at 603-271-8308 for assistance.”
If the user just logged in (initial request was done in a previous session) then the page will display
instructions on how to finish the account setup based on the previous email. The page will also display a
link to have another email sent.
When the user clicks on the activation link in the email they will be directed to this page. The page will
then retrieve the user id and application id value from the query string and decrypt.
If the user is already active the following message will be displayed: “account name has already been
activated. Please proceed to link”. Account name will be provided by the developer and link is an active
link to the applications page that will display all available applications to the user.
If the user status is requested:
Set account to active
Create event log entry: Event – Account Activated: Note – Account activated
If the application is not valid (does not exist) then the user will be displayed the following:
“Congratulations! Your account has been successfully activated.
If the application is valid the system will check the permissions needed:
No permissions listed: user can access the application and will be shown the following
message “Congratulations! Your account has been successfully activated. You may now
log into application title” where application title is an active link to the jump page with the
application id.
Default permissions: system will apply default permission to the user and display the
following: “Congratulations! Your account has been successfully activated. You may now
log into application title” where application title is an active link to the jump page with the
application id.
User must request permission system will display the following. “Congratulations! Your
account has been successfully activated. To request permission to application title please
contact the NH Department of Labor Web administrator at 603-271-8308 or at
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
20
5.1.5.6 Profile Page
The profile page will allow the user to maintain profile data. The data used from SecureAuth (first name,
last name, email address) cannot be changed in this interface.
When any of the profile data fields are modified then an event log entry will be made. The update will be
for each field not for each update. The event log event = Data Update and Note = "field name has been
updated. Value = previous value of field". The developer will provide the field name and the previous
value.
The following information provided by SecureAuth will be displayed to the user but will not be editable :
First Name
Last Name
Email Address (username)
The following information will be displayed to the user for modification.
Field Description Page Display Field Type Validation Error Message AccountTypeID List of available
account types.
When user is
first created
default to
‘Unknown
Account Type Dropdown Required Account Type is
required.
Organization Name of
organization
Organization Textbox Required
^.{1,75}$
**This is only
required if
‘Business’ is
selected from
Account Type
^.{0,75}$
Organization is
required.
Organization
cannot be more
than 75
characters in
length.
Title Users’ title Title Textbox ^.{0,50}$ Title cannot be
more than 50
characters in
length.
Addresses
The underlying database is designed to allow a user to enter in multiple addresses; however, at this time a
user will only enter in one address.
The validation of the format will depend on the country selected. The default country is USA. When a
country is selected the controls will be switched for the appropriate selection.
The user is not required to enter an address. However, if the user enters an address then the validation
below will be enforced.
USA
Field Page Display Field Type Validation Error Message AddressTypeID Address Type Drop Down Required Address type is required. Address1 Address Textbox Required
Address is required.
Address, line 1, cannot be
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
21
^.{1,40}$ greater than 40 characters in
length. Address2 Textbox ^.{0,40}$ Address, line 2, cannot be
greater than 40 characters in
length. Address3 Textbox ^.{0,40}$ Address, line 3, cannot be
greater than 40 characters in
length. Address4 City Textbox Required
^.{1,40}$
City is required.
City cannot be greater than 40
characters in length. StateProvinceID State Dropdown Required State is required. CountryID Country Dropdown Required Country is Required. ZipCode Zip Code Textbox Required
^([0-9]{5})$|^([0-
9]{5}\-[0-9]{4})$
Zip Code is required.
Zip Code must be in the format
99999 or 99999-9999.
Canadian
Field Page Display Field Type Validation Error Message AddressTypeID Address Type Drop Down Required Address type is required. Address1 Address Textbox Required
^.{1,40}$
Address is required.
Address, line 1, cannot be
greater than 40 characters in
length. Address2 Textbox ^.{0,40}$ Address, line 2, cannot be
greater than 40 characters in
length. Address3 Textbox ^.{0,40}$ Address, line 3, cannot be
greater than 40 characters in
length. Address4 City Textbox Required
^.{1,40}$
City is required.
City cannot be greater than 40
characters in length. StateProvinceID Province Dropdown Required Province is Required. CountryID Country Dropdown Required Country is Required. ZipCode Postal Code Textbox Required
[0-9 A-Z a-
z]{3}\s[0-9 A-Z a-
z]{3}
Postal Code is required.
Postal Code must be
alphanumeric in the following
format XXX XXX.
All Other Countries
StateProvinceID will default to ‘other’.
Field Page Display Field Type Validation Error Message AddressTypeID Address Type Drop Down Required Address type is required. Address1 Address Textbox Required
^.{1,40}$
Address is required.
Address, line 1, cannot be
greater than 40 characters in
length. Address2 Textbox ^.{0,40}$ Address, line 2, cannot be
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
22
greater than 40 characters in
length. Address3 Textbox ^.{0,40}$ Address, line 3, cannot be
greater than 40 characters in
length. Address4 Textbox ^.{1,40}$ Address, line 4, cannot be
greater than 40 characters in
length. CountryID Country Dropdown Required Country is Required. ZipCode Postal Code Textbox ^.{0,10}$ Postal Code cannot be more than
10 characters in length.
Address Type
The address type table will hold values to be determined by DOL. This list will need to be provided
before the project moves to testing. Managing this list is considered a future enhancement of the UAM.
With this design any additions will need to be added by a DBA.
5.1.5.7 Application Unavailable/Error page
This page will display the disabled title and message. This page will also be used to display user friendly
error messages when needed.
5.1.5.8 Applications Page
This page will display all available applications with notation on the applications the user has access to.
Each application will display the title and description. The title will be a link to the jump page for that
application. This page will be displayed when the user tries to access an unknown application or has
logged out of the application but not the UAM. This page will also display a link for the user to edit
profile data and to log out. The use can also navigate to this page from the jump page.
This page can also be accessed by users not logged in and will display all available external applications.
5.1.5.9 Request Permissions
Display the following to the user when he/she does not have the necessary permission to access the
application : . Please contact the NH Department of Labor Web administrator at 603-271-8308 or at
[email protected] to request permission to application title. Developer will supply the
application title in the message.
Future development of the UAM will include an interactive application user can use to request permission
to specific applications.
5.1.6 Applications/UAM Communications
The application will communicate with the UAM through WCF/web services.
5.1.6.1 User Check
This check will be done by every application to verify the user, the user permissions and an active session.
The application is only required to make this call once within the timeout period.
If the user session is valid and active, application is valid (active and in user’s session) and the user is
valid the users application session last accessed date will be updated. The appropriate data will be
returned to the application.
If the application or user is not valid the user’s session will be terminated and the appropriate data will be
returned to the application.
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
23
If the session is not valid an error log entry will be made and the appropriate data will be returned to the
application.
5.1.6.1.1 Parameters
The following parameters will be passed from the applications :
Session id
Application id
User id
5.1.6.1.2 Returned dataset
The UAM will return the following data to the application
Status (see 5.1.6.1.3)
Status Message (see 5.1.6.1.3)
Application ID
User ID
User Permissions (may have multiple and need to return all or may have none because not all
application will have defined permissions.)
5.1.6.1.3 Status Values
Status Value Status Message Description 1 Successful Successful 2 Invalid session Session ID received does not
match one on record 3 Session timed out Session is more than the
allotted session time. 4 Invalid application Application does not exist 5 Application disabled Application has been
disabled for all users 6 Application disabled Application has been
disabled except for system
administrators 7 Invalid user User does not exist 8 Disabled user User has been disabled 9 Log Out The user has been logged out
of UAM
If the user is disabled the UAM will terminate the user application session.
5.1.6.1.4 Log Out
The application will send the session id, user id and application id to the UAM. An event log entry
will be made: Event - Log out; Note – User logged out of application title. The developer will
provide the application title name.
The application will need to finish designated processes before sending the log out request to the
UAM.
The user has logged out of the application but not out of the UAM. The application will need to
redirect the user to the UAM application page. The user can then select another application to user,
edit/manage the profile data or log out of the UAM.
If the user chooses to then log out of the UAM the UAM will terminate the session and an event log
entry will be made: Event - Log out; Note – User logged out of UAM.
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
24
5.1.6.1.5 Terminate Session
The application will terminate a session by deleting the corresponding record in the application
session table.
When a session is terminated then a record in the event log will be added. Event: User session
terminated; Note: User session terminated by UAM for reason. Reason will be either, user log out,
disabled user or session timeout. There may be other reasons for session termination that are not
listed.
5.1.6.1.6 Application
When an application receives a response from the UAM it will need to verify the user id, session id
and application id.
5.1.7 User Management
Only UAM system admistrators wil be allowed to manage user accounts.
5.1.7.1 AccountType
The account type table will hold the following values to start: Business, Individual, Both, Unknown.
Managing this list is considered a future enhancement of the UAM. With this design any additions will
need to be added by a DBA.
5.1.7.2 AccountStatus
The account status table will hold the following values to start: Active, Requested, Disabled. Managing
this list is considered a future enhancement of the UAM. With this design any additions will need to be
added by a DBA.
5.1.7.3 Search
System administrators will be able to search users by a combination of the following: user name, first
name, last name, email address, organization, status, and location (internal or external). The user must
select either internal or external and the user must enter in at least one other search criteria.
The search results will display the following columns: last name, first name, email address, organization,
last login date and account status (Active, Disabled or Requested). The user can select any one of the
records to open the user for edit (see 5.1.7.4.2). The search results can be sorted by any of the columns
and downloaded to an Excel spreadsheet on the user's computer. Search results will accommodate paging
and the user can change the number of records displayed for each page.
The search screen will look similar to the image below.
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
25
5.1.7.4 Users
5.1.7.4.1 Add
System administrators will be able to add internal users to the UAM application. First they must
search the SecureAuth (internal only) system for users based on email address, first name or last
name. The system administrator will be required to provide one of these parameters. There should
also be a check to see if the user already exists in the UAM.
From the list of returned users the system administrator can select one user to add. The system
administrator will then create the user profile. See 5.1.5.6 Profile.
Once the user profile is created the system administrator will then be able to select the application(s)
the user is to have access to. For each application selected the user must then select the appropriate
permissions for the user.
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
26
5.1.7.4.2 Edit When the system administrator selects an internal account to view, the UAM will display the data
stored within the Internal SecureAuth and the NHDOL account. The UAM will also display all
logged activity for the account and allow the system administrator to sort the results of the activity
log by any single log attribute. The system administrator will also be able to filter the log by
searching the selected user's log based on user ID, IP address, date or application/function. The
results can be sorted by any single log attribute. All data from a user's log can be downloaded to an
Excel spreadsheet on the system administrator's computer.
The system administrator will be able to edit the following information for an internal user: NHDOL
user account data, account status and NHDOL application permissions.
5.1.7.5 User Permissions Permissions are assigned to users by system administrators or by default on user account set-up. The
system administrator can view all available permissions through the Admin menu in the main menu bar.
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
27
They will be able to edit the description only since the other fields are used programmatically. Permissions
are added programmatically by the developer through a series of SQL scripts or stored procedures.
To assign or remove permissions from a user, the system administrator must search for and select the user
to view the user's profile. By clicking on the Permissions tab in the selected user's profile, the system
administrator will see a list of permissions. Checkmarks indicate the permissions assigned to the current
user. Adding or removing a checkmark on permission will assign or remove the selected permission.
Permissions are structured by application. Permissions will not be physically deleted from the system
only marked as inactive.
5.1.8 General
5.1.8.1 Configuration File values
The following list may be expanded as the application is built.
Email address (From) for account activation (tbd what address).
Timeout value (in minutes) can not exceed 20 minutes.
System administrator email address
System administrator phone
5.1.8.2 User Validation
Each page of the application will validate that the user, session, and permissions are valid before
proceeding. This pertains to after the user has logged in.
5.1.8.3 Querystring Values
Any query string values will be encrypted to ensure security.
5.1.8.4 Textarea
For any control using a textarea there must also be a physical counter for the user to see how many
characters they have used and the limit.
5.1.8.5 Page Look
All pages will use the existing NH DOL "Look and Feel". The necessary graphics, HTML code and css
files will be provided by NH DoIT WSD.
Every page will display the logged in users name with an option to log out.
5.1.8.6 NHDOL Events Requiring Logging
Creation of user record
Creation of a UAM application
Creation of UAM permissions
Log into the UAM
Log in to the UAM or application for an internal or external user
Log out of the UAM or application for an internal or external user
Disabling of an internal or external user by a system administrator - this event requires an
additional note or comment that is stored in the log
Modification of NHDOL user profile data by a system administrator or the user on an internal or
external user
Activation of an external user account by a system administrator
Modification of the account status - the previous and new statuses are stored in the log
Modification of user permissions
Modification of maintainable data for an application by a system administrator
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
28
Shut down of an application - this event requires an additional note or comment that is stored in
the log
Start up of an application
5.1.8.7 Error Handling When the user encounters an error, the application will display a custom error page using the design
template. The error message will indicate that an error has occurred and the system administrator has been
notified. The error message and stack trace will be salted and encrypted then logged in the database. (See
5.6.2 Database Security for encryption information.) To accommodate the salted encryption of the error
message and stack trace, each value will be truncated to 5500 characters prior to salting and encryption.
The system administrator will be emailed the details of the error. The system administrator email address
will be stored in the configuration file (web.config).
If the application can not log the error to the database then the log entry will be written to file.
5.1.8.8 Validation Error Messages
All page error messages, including validation error messages, will be located in one place with red text.
When validation error occurs the text of the label to the corresponding control will also be red.
5.2 DATA CAPTURE, STORAGE, CONVERSION, AND EXCHANGE
5.2.1 Database Design
See UAMDatbase.pdf for the full database design
5.2.2 Application Session Cleanup
A daily database job will be created to clean up any old user application sessions.
5.3 HARDWARE AND SOFTWARE PLATFORM
The client application is to be managed by a Windows 2008 servers located in the DOIT managed server facility.
There are three servers within the environment: database, application and web server. See
HZNSNHVHS_Environment.pdf
The database server is a Windows 2008 server with SQL 2008. The database and all data related jobs will reside on
this server.
The application server is a Windows 2008 server with IIS 7.5. All business logic and WCF/web services will reside
on this server.
The web server is a Windows 2008 server with IIS 7.5. The client application will reside on this server.
The client application will be developed in ASP.NET using Visual Studio/Visual Basic. The application will use the
MVC programming model and will access the SQL 2008 database using the Entity Framework and LINQ through
Web Services.
5.4 OUTPUT / REPORTS
No additional output/report have been requested at this time.
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
29
5.5 TESTING/TRAINING
5.5.1 Stellarware Testing Stellarware will test to assure application meets all identified business requirement functions/features to assure
compliance before being submitted to NHDOL for State Testing.
Stellarware will also provide proof of application passing security analysis before being submitted to NHDOL
for testing
5.5.2 User Acceptance Testing The application will be submitted to NH DOL for full user acceptance testing.
5.5.3 State Code Review and Acceptance Testing The application will be submitted to NH DoIT for code review and penetration testing to assure application
meets the submitted State standards.
5.5.4 Training Stellarware will provide documentation on the details needed for NHDOL applications to interface with the
UAM.
5.6 SECURITY
5.6.1 Application Security The application configuration file (web.config) will have the database connection string and app setting sections
encrypted. The ASP.NET IIS Registration Tool will be used for encryption.
5.6.2 Database Security Stored procedures will be used to select and insert data.
SQL User Account
Application access to the database will use a unique SQL Server user account that is assigned to a role with
execute permissions on stored procedures. The password for this account will be at least 10 characters and
contain a combination of uppercase, lowercase, alphanumeric and special characters. The username can be set by
NHDOL or one will be used that is not a default and not easily determined. The password will be randomly
generated. The account credentials will be encrypted using the ASP.NET IIS Registration Tool and stored in the
application configuration file (web.config).
Separate SQL user accounts will be used for internal database, external database access and data processing jobs.
Encrypted Fields
Fields requiring encryption will be encrypted using the sample method provided by the state. The key will
contain a combination of uppercase, lowercase, alphanumeric and special characters and be encrypted using the
ASP.NET IIS Registration Tool and will be stored in the application configuration file (web.config).
Encrypted values for the ErrorLog.StackTrace and ErrorLog.ErrorMessage fields will use both an application
key and a unique IV/salt value. The key and IV/salt values will be generated by the cryptography class. The
IV/salt value will be stored with the record. For the Inquiry field, validation will take place for the actual size of
the data but the database field size will be adjusted for the encrypted value size based on the following algorithm
(bytes):
UAM
NH Department of Labor
Functional Design Phase Functional Design Document
Office of Information Technology, Web Support Division
30
1) Enc Size = (OriginalFieldSize + Block - (OriginalFieldSize Mod Block)
2) FullFieldSize = ((EncSize + 3 - (EncSize % 3)) /3) X 4
For the ErrorMessage and StackTrace fields, the values will be truncated to 5500 characters prior to salting and
encryption. (The resulting full field size is 7340 characters and the maximum number of characters allowed in
varchar(MAX) is 8000.)
5.6.3 Encryption
All encrypted data in the application will be encrypted using AES 256 bit encryption.
5.6.4 SSL
All application communication will be done over SSL. Each page of the application will check for and enforce a
SSL connection.
5.7 IMPLEMENTATION
5.7.1 Deployment Package The compiled application and source code will be added to an archive file. Database modifications will be
handled through scripts and NHDOL will implement these items on the appropriate servers. The package will
include setup instructions.
5.8 PERFORMANCE AND RESPONSE TIME
Not applicable.
5.9 DATA ARCHIVAL AND BACKUP
Data archival and backup will be done in accordance to NH DoIT WSD existing policies.
5.10 MISCELLANEOUS/OTHER
5.10.1 Time Estimate The time estimate for this project is outlined in UAMTimeEstimate.pdf.
Applications
PK ApplicationID int
Code varchar(20)
Title varchar(75)
Description varchar(1000)
Internal bit
UserDisabled bit
Disabled bit
DisabledMessageTitle varchar(200)
DisabledMessage varchar(2000)
URL varchar(2000)
JumpPageMessage varchar(2000)
UAM Database
User
PK UserID int
UserStoreID uniqueidentifier
Organization varchar(75)
Title varchar(50)
Internal bit
FK1 AccountStatusID int
FK2 AccountTypeID int
AccountStatus
PK AccountStatusID int
AccountStatus varchar(10)
Active bit
AccountType
PK AccountTypeID int
AccountType varchar(40)
Active bit
UserAddress
PK UserAddressID int
UserID int
Address1 varchar(40)
Address2 varchar(40)
Address3 varchar(40)
Address4 varchar(40)
FK1 StateProvinceID int
ZipCode varchar(10)
FK2 CountryID int
FK3 AddressTypeID int
StateProvince
PK StateProvinceID int
Code varchar(2)
Name varchar(40)
FK1 CountryID int
Display bit
Active bit
Country
PK CountryID int
Code varchar(3)
Name varchar(40)
Display bit
Active bit
ApplicationPermission
PK ApplicationPermissionID int
FK1 ApplicationID int
Permision varchar(80)
Description varchar(200)
Default bit
UserPermissions
PK UserPermissionID int
FK1 ApplicationPermissionID int
FK2 UserID int
Active bit
ApplicationSession
PK ApplicationSessionID int
FK2 UserID int
FK1 ApplicationID int
IPAddress varchar(44)
LastAccessed datetime
Salt binary(32)
EventLog
PK Event ID int
EventDate datetime
UserID int
FK1 ApplicationID int
IPAddress varchar(44)
Table varchar(30)
RecordID int
Event varchar(80)
Note varchar(200)
Salt binary(10)
ErrorLog
PK ErrorLogID int
ErrorDate datetime
FK1 ApplicationID int
UserID int
IPAddress varchar(44)
Location varchar(80)
ErrorMessage varchar(max)
StackTrace varchar(max)
Salt binary(10)
Encrypted fields:
IP Address (EventLog, ErrorLog,
ApplicationSession): actual length 15
ErrorMessage (ErrorLog): actual length 5500
StackTrace (ErrorLog): actual length 5500
Encrypted field lengths were determined by the
following (in bytes):
Enc Size = (OriginalFieldSize + Block -
(OriginalFieldSize Mod Block)
FullFieldSize = ((EncSize + 3 - (EncSize %
3)) /3) X 4
AddressType
PK AddressTypeID int
AddressType varchar(50)
Active bit
External User Authentication
Valid
application ID?
Display
available
application list
Does the cookie
exist?
UAM Jump
Page
Retrive data
from cookie
and data from
SecureAuth
Does the user
exist in UAMCreate new
account.
Login user.
See External New Account processNo
Yes
No
No
Yes
Yes
Valid User?
Yes
No
Requested
Account?
A valid user is one that is
active and has permissions
to the application.
Requested
Account
User Friendly
MessageNo
Yes
The user is either disabled
or does not have permission
to the application. Display
appropriate message.
Account has not yet been validated via email.
See External New Account Process starting at
step 2
Existing
Session?
This will show the page for a user who has not
yet logged in.
UAM Jump
PageNo
This will show the page for a user that has
logged in.
User will access the UAM jump page from a link on the static site.
This process assumes that the user has created an account with SecureAuth and has logged in.
External New Account
The user will get to this process only after he/she has
logged into SecureAuth and he/she does not have an
existing account within the UAM.
Create User
Account
The initial account will only hold
the data available from
SecureAuth which is retrieved
as part of the authentication
process. The account status
will be ‘Requested’.
Update Event
Log
Log user account creation and
log in. If user account was
created on a previous visit
only the log in will be logged.
Profile Data
User will update additional
profile data.
Email account
activation to
user
Email will provide user with a
link to complete account
Confirmation
Display to users confirmation
the account activation email
was sent and instructions on
how to proceed.
This is the process after the user clicks on the link in the
activation email.
Valid App?
Valid User?
Get
parameters
from query
string
User account exists
and the status is
‘Requested’
User Friendly
Message
Display appropriate
message for an
active user or
generic message.
Update user
account to
active.
Log account
activation
Account
activation
message
Default
permissions
?
Assign user
default
permissions to
application.
App
permissions
?
Account
activation
message.
A valid application is one that exists.
Account
Activiation
Message
No permissions are needed to access the
application.
The application has specific permissions
that are defaulted to new users.
No
No
No
No
This will also instruct users how to
request permission to the application.
External User LoginThe user will get to this process only after he/she has been authenticated. This is the continuation of the External User
Authentication process.
Log user UAM
login
App
Disabled?
Total shutdown of application
only
Create user
application
session
Disabled
Message
Log user Login
to application
Go to
application
Application UAM Interaction
Application
request
verification
Valid
Session?
Valid User?
Valid
Application?
Update user
application
session data
Return to
application
Return to
application
Return to
application
Return to
application
Terminate
Session
Terminate
Session
Active
Session?
Return to
application
Terminate
Session
Does the session exist and is
it active?
Is the active session within
the timeout period?
Does the application exist and
is it active?
Does the user exist and is
it active?
This request will always return to the
application. If the user can continue with the
application the request will return application
and user information. If the user cannot
continue with the application then the request
will send data pertaining to the reason.
Log user
session
termination
Log user
session
termination
Log user
session
termination
Log invalid
session
Log into
SecureAuth
Does the cookie
exist?
Retrive data
from cookie
and data from
SecureAuth
Does the user
exist in UAM
Log user login/
create user
application
session
Internal users will start by logging into SecureAuth. Once
authenticated SecureAuth will create a cookie and redirect
the user back to the UAM.
No
Yes
Valid User?
Internal User Authentication
User friendly
message.
User friendly
message.
Is user
Admin?
Admin Menu
Application
Menu
The user has not yet been
created in the UAM.
User friendly
message.
User is disabled.
FINAL
User and Application Management Module
Functional Design Phase
Business Requirements Document
06/28/2013
Version 1.0
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
2
TABLE OF CONTENTS
1. INTRODUCTION ............................................................................................................................ 3
1.1 USING THIS DOCUMENT .................................................................................................................................. 3 1.2 PURPOSE ......................................................................................................................................................... 3 1.3 BUSINESS OWNERS AND CONTACTS ............................................................................................................... 3 1.4 SIGNOFFS ........................................................................................................................................................ 3 1.5 REVISION HISTORY ......................................................................................................................................... 3 1.6 REFERENCED DOCUMENTS ............................................................................................................................. 4 1.7 DEFINITIONS, ACRONYMS AND ABBREVIATIONS ............................................................................................ 4
2. PROJECT OVERVIEW: ................................................................................................................ 5
3. ASSUMPTIONS, CONSTRAINTS AND SCOPE: ....................................................................... 5
4. PROCESS FLOWS. ......................................................................................................................... 6
4.1 CURRENT/EXISTING PROCESS WORKFLOW .................................................................................................... 6
5. BUSINESS REQUIREMENTS: ..................................................................................................... 6
5.1 BUSINESS REQUIREMENTS MATRIX ................................................................................................................ 6
6. ACCEPTANCE CRITERIA ......................................................................................................... 25
6.1 ACCEPTANCE CRITERIA MATRIX .................................................................................................................. 25
7. ISSUES LOG .................................................................................................................................. 25
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
3
1. INTRODUCTION
1.1 Using this Document
This document is one of many related to the NHDOL Web redevelopment project. This particular document defines
the NHDOL business requirements for managing the internal and external users on the department’s Web
applications, the applications on the web site and the user permissions to these applications. Please refer to Section
1.6 Referenced Documents for a listing of additional project-specific documentation.
1.2 Purpose
The purpose of this document is to describe the business requirements for User and Application Management
(UAM) module for the NHDOL Web site.
Upon completion and approval of the business requirements described in this document, DoIT and the developer
will define in detail all the system functions necessary to satisfy the business requirements. These details will be
documented within a Functional Design Document specific to this application.
The functional design document should include application screen shots. The state is providing drafts of possible
screens for consideration within this document.
1.3 Business Owners and Contacts
Name Email Phone Role Joe Nadeau [email protected] 603-271-
6872 Project Manager
Mary Hillier [email protected] 603-271-8308
NHDOL Web Administrator
Kathryn Barger [email protected] 603-271-3599
Director of Workers Comp Division
Michele Small [email protected] 603-271-3119
Administrator of Inspection Division
1.4 Signoffs
Name Date Signature Kathryn Barger
Michele Small
Rebecca Gamache
Joe Nadeau
1.5 Revision History
Date Reason for change(s) Author(s)
06/28/2013 Initial version Mary Hillier/Joe Nadeau
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
4
1.6 Referenced Documents
Document Version/Date Author(s)
External SecureAuth Documentation October 19, 2012 R. Gamache
Internal SecureAuth Documentation June 17, 2013 R. Gamache
HZNSNHVHS Environment Diagram.pdf February 6, 2013 R. Gamache
HZNSNHVHS Environment Process Flow Descriptions.doc February 6, 2013 R. Gamache
NHDOL Internal User Authentication Process Flow Diagram June 17, 2013 Joe Nadeau
NHDOL External User Authentication Process Flow Diagram June 17, 2013 Joe Nadeau
1.7 Definitions, Acronyms and Abbreviations
DoIT NH Department of Information Technology
DOL NH Department of Labor
NHDOL NH Department of Labor
SecureAuth State of NH single sign-on solution, a commercial off-the-shelf product.
Internal SecureAuth The State’s customized application of SecureAuth used for authenticating DOL internal users
against State network active directory credentials.
External SecureAuth The State’s customized application of SecureAuth used for authenticating DOL external users
against account data stored and managed through the database associated with the External
SecureAuth application.
UAM User and Application Management
Internal User An employee of NH DOL or other designated individual who has access to and permissions to
use NH DOL internal Web applications.
External User Any individual who uses or needs to use public facing NH DOL Web applications. Some NH
DOL applications will not require any account or credentials and some applications will
require a user account and special permissions.
LDAP Lightweight Directory Access Protocol used as interface between Internal SecureAuth
application and the State’s Active Directory.
Active Directory Microsoft Windows Directory Service – used here for its LDAP authentication abilities.
WSD Web Services Division of DoIT.
Web Services As used here, stand alone applications that provide communication between Web applications
and the database.
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
5
2. PROJECT OVERVIEW:
The project defined in this document is one module of a larger project for the development of Web applications
furthering the web presence of the NH Department of Labor. This module, the User and Application
Management module (UAM), will provide for the management of user accounts and applications on the
NHDOL web site.
UAM will provide the necessary tools for NHDOL system administrators to manage accounts by setting
permissions on accounts, enabling and disabling user accounts and viewing account activities. UAM will also
provide tools to manage application availability, information such as application titles and descriptions, table
data used for drop down lists and other tasks as appropriate.
The UAM module will manage all interactions between internal and external users and versions the State’s
single sign-on application which uses SecureAuth as its core software for authentication. The internal user
SecureAuth application interfaces will provide for logging in (user authentication) and retrieval of State
network active directory account data. The external user SecureAuth application interfaces will provide for
account set up within SecureAuth, logging in (user authentication) and retrieval of SecureAuth user account
data.
This UAM module will also manage user sessions and setting and checking of users access permissions to
NHDOL applications/functions.
3. ASSUMPTIONS, CONSTRAINTS AND SCOPE:
The requirements defined in this document pertain to both public or external users and internal users. Public or
external users will be referred to as external users going forward for the purpose of consistency.
The basic information needed for the application to interact with SecureAuth is provided in the SecureAuth
Documentation referenced in Section 1.6.
Internal users will authenticate using interfaces with the Internal SecureAuth application. The SecureAuth
application will authenticate the internal users against their State network active directory credentials. This
means the log in attempts by internal users will follow and take advantage of the State network settings for
lock-outs etc. This means this UAM module does not need to handle locking of user accounts when repeated
authentication attempts fail.
External users will authenticate using interfaces with the External SecureAuth application. The External
SecureAuth application will authenticate the external users against their account credentials stored and
managed on the External SecureAuth database. The External SecureAuth application will manage and
maintain generic external user profile data which will be made available to DOL applications through queries.
This portion of the External SecureAuth application will manage log in attempts by external users
relinquishing this UAM module from any lock-out processing.
As more applications are developed for DOL the set of permissions in this module will expand. It is also
possible that the functionality of this application will expand.
These business requirements are being developed independently of any specific NHDOL Web application at
this time. References may be made to NHDOL web applications currently in development or slated for future
development to help illustrate desired functionality.
External web applications will be hosted on a separate Web server from the NHDOL static web site and
NHDOL internal web applications. The applications will use a single SQL server 2008 database.
Communication between web applications and the database will be handled using web services and web
services will reside on a separate application server. Web applications will only access the database through
web services.
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
6
The production environment will use a single database server. Database interactions between both the external
and internal web applications will be executed through either WCF or Web Services on the Application Server.
Developers are responsible for the development of WCF or Web Service coding for all interfaces with the
NHDOL applications database.
A basic description of the planned system architecture and related information is provided in the documents
“HZNSNHVHS Environment Diagram” and “HZNSNHVHS Environment Process Flow Descriptions” (see
Section 1.6).
NHDOL static web site (www.nh.gov/labor) will serve as the primary point of entry for external users.
Secondary entry points to access the NHDOL applications will be allowed.
4. PROCESS FLOWS.
4.1 Current/Existing Process Workflow
The current application process is not being used to determine the functionality of the application.
5. BUSINESS REQUIREMENTS:
5.1 Business Requirements Matrix
The requirements matrices that follow present a numbered list of the requirements with a brief description, a priority
and any comments. The priorities are:
M - the requirement is mandatory
D - the requirement is desirable
F - the requirement is to be postponed to the future
N - although discussed, no longer a requirement
I – Informational text and not a requirement
As used in the following requirements, the term ‘sysadmin’ means a user who has been granted System
Administrator permissions on UAM.
Functions/Features
No. Description Priori
ty
Comments
1.1 General Requirements
1.1.1 As part of the functional design the developer will include
documentation providing technical details and instructions needed
for future NHDOL applications to be designed and developed
utilizing this User and Application Management (UAM) module.
M
1.1.2 After State acceptance testing is completed, the developer will
revise the functional design documentation with the latest technical
details and instructions needed for future NHDOL applications to be
designed and developed utilizing this User and Application
Management (UAM) module.
M
1.1.3 External users shall have no access to internal DOL
Applications/Functions M
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
7
1.1.4 Internal users shall have no access to external DOL
Applications/Functions M
1.2 External Users Interface with External SecureAuth Requirements
1.2.1 The following requirements will cover managing the interface with
the State’s single sign-on External SecureAuth application, creating
and maintaining external user session data and interfacing with DOL
business applications. The UAM will utilize a dynamic UAM
business application jump page form as a user interface for
providing authentication instructions and options to users as an
interim step prior to passing control to a DOL business process
application. External SecureAuth interfaces include Create an
Account, Log-In and Querying External SecureAuth data.
I
1.2.2 An external source, outside the UAM possibly DOL static site or
another State site, will send requests to the UAM with incoming
parameters. The UAM shall validate these incoming parameters for
completeness and accuracy and provide error messages and error
handling as appropriate.
M .
1.2.3 The UAM will interrogate the user’s authentication status and
permissions to the desired DOL Application. M
1.2.4 When the user is identified as authenticated and has permissions to
the desire DOL business application the UAM shall direct the user
to the DOL application with all appropriate parameters.
M This referred to DOL
business application is a
future to-be-developed
application and is not
included within these
business requirements.
1.2.5 When the user is identified as authenticated, but lacks authority to
access their target application the UAM shall check whether the
application/function requires special permissions and if true direct
the user to the Permission Request application (see 1.22 Special
Permission Request and Approval Processing).
M This referred to Permission Request application is a future application
but should be considered when
designing this UAM (see 1.22
Special Permission Request and
Approval Processing).
1.2.6 When the user is identified as authenticated, but lacks authority to
access their target application the UAM shall check whether the
application/function requires special permissions. When no special
permission is required the UAM shall display a message informing
the user of an issue with their account and instructions to contact the
DOL web administrator. The UAM shall immediately terminate the
user’s session data.
1.2.7 When the user is identified as not authenticated the UAM shall
present the external user a UAM Business Application jump page
dynamically generated based on an incoming parameter value
identifying the DOL Application/Function they wish to access (see
1.21 UAM Business Application Jump Page).
M This referred to DOL
application is a future to-be-
developed application and
not included within these
business requirements.
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
8
1.2.8 The UAM shall evaluate the external user’s function selection and
interface with the appropriate External SecureAuth application
through predetermined URLs stored and maintained within the
UAM (See 1.14 Predetermined Configuration File Values).
Create an Account shall direct the user to the appropriate External
SecureAuth URL. This portion of the External SecureAuth
application does not generate a cookie or return a request back to the
UAM or provide any notification to the UAM when the user has
completed this External SecureAuth function.
Log-In shall direct the user to the appropriate External SecureAuth
URL. This portion of the External SecureAuth application will
generate a cookie on the users desktop and generate a request back
to the UAM when the user has successfully completed this External
SecureAuth function.
M
1.2.9 Upon every request sent to the UAM it shall check for a SecureAuth
cookie on the user’s workstation. The presence this SecureAuth
cookie indicates the user has successfully authenticated in
SecureAuth and should move forward to complete the DOL
authentication process (see 1.3 Complete External User
Authentication Set-Up).
M
1.2.10 When an external user has successfully completed the authentication
process the UAM shall check the user’s permissions for access their
target DOL application.
M
1.3 Complete External User Authentication Set-Up
1.3.1 The following covers the sequence of requirements when an external
user authenticates.
1.3.2 When a valid SecureAuth cookie is found the UAM shall retrieve
the username (email address) from inside the cookie. M
1.3.3 The UAM shall query External SecureAuth to obtain the External
SecureAuth GUID using the username from the cookie. The GUID
shall be the primary key for the DOL External User Account.
M Querying External SecureAuth will require use of web services
developed by DoIT WSD.
1.3.4 The GUID shall be used to determine whether the user has an
existing DOL account and when no existing DOL account is found
the UAM shall generate a new DOL Account (see 1.4 Set-Up
External Skeleton DOL Account).
M
1.3.5 The UAM shall insert a history log reflecting the DOL account Log-
In prior to sending control the Edit External DOL Profile Data to
assure the Log-In is recorded in the event the user terminates their
session before completing the Edit External DOL Profile Data form.
M
1.3.6 After inserting the history log the UAM shall will need to determine
if the external skeleton DOL account was set up in this session and
if true provide a process to enable the user to complete their DOL
profile data (See 1.5 Edit External DOL Profile Data).
M
1.3.7 The UAM shall check the user’s DOL Account status and when
“Disabled” shall process appropriately (see 1.8 Disable DOL
Account Processing).
M
1.3.8 The UAM shall check the user’s DOL Account status and when
“Requested” shall process appropriately (see 1.9 Requested
External DOL Account Processing).
M
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
9
1.3.9 The UAM shall check the user’s DOL Account status and when
“Active” the UAM shall set up and store session data within the
UAM (See 1.10 UAM User Session Requirements).
M
1.3.10 The UAM shall extract required External SecureAuth Account data
using the GUID and store as needed in the Session Data (see
External SecureAuth Documentation).
M
1.3.11 The UAM shall display the external user’s name reflecting an
authenticated user status. M
1.3.12 The UAM shall display a “Log Out” reflecting an authenticated user
status and providing the user the option to log out. M
1.4 Set-Up External Skeleton DOL Account
1.4.1 The UAM shall initially set up a skeleton account based only on
External SecureAuth profile data to allow for history logging in the
case when a user may exit the site prior to completing the DOL
Profile data form.
M
1.4.2 The UAM shall set the DOL User Account status to “Requested”. M
1.5 Edit External DOL Profile Data
1.5.1 See 2.0 DOL External User Profile Data for a table identifying
base data the State desires to capture and maintain beyond the
generic user profile data managed by External SecureAuth.
M
1.5.2 The UAM shall present the user with a form to insert or modify their
DOL account data. M
1.5.3 The UAM shall provide for an external user to supply a USA,
Canadian, or International address. M
1.6 Internal Users Interface with Internal SecureAuth Requirements
1.6.1 The following requirements will cover managing the DOL Internal
Users interface with the State’s single sign-on Internal SecureAuth
application for DOL internal business applications.
M
1.6.2 The UAM shall be the entry point for all Internal users accessing the
DOL internal applications. M
1.6.3 Upon entry into the Internal DOL Application site the UAM shall
send a request to the Internal SecureAuth applicaton for the user to
authenticate with their State network log-in credentials.
The Internal SecureAuth application will generate a cookie on the
user’s desktop and send a request back to the UAM when the user
has successfully completed their SecureAuth authentication.
M
1.6.4 The URL for the Internal SecureAuth Application will be stored and
maintained within the UAM (1.14 Predetermined Configuration
File Values).
M
1.6.5 Upon every request sent to the UAM it shall check for a SecureAuth
cookie on the user’s workstation. The presence of this SecureAuth
cookie indicates the user has successfully authenticated using the
Internal SecureAuth and should move forward to complete the DOL
Internal authentication process (see 1.7 Complete DOL Internal
UAM Authentication Set-Up).
M
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
10
1.6.6 When an external user has successfully completed the authentication
process the UAM shall determine whether the user is a System
Administrator or not and forward control to the appropriate Internal
DOL Menu page.
M
1.6.7 All internal Non-System Administrator users will be directed to the
application menu page after they log in and have been authenticated
(see 1.18 Application Menu Page Requirements).
M
1.6.8 All System Administrator users will be directed to the system admin
menu page after they log in and have been authenticated (see 1.19
System Admin Menu Page Requirements).
M
1.7 Complete DOL Internal UAM Authentication Set-Up
1.7.1 The following covers the sequence of actions required when an
internal user authenticates. I
1.7.2 When a valid SecureAuth cookie is found the UAM shall retrieve
the username (userid) from inside the cookie. M
1.7.3 The UAM shall query Internal SecureAuth to obtain the Internal
SecureAuth GUID using the username from the cookie. The GUID
shall be the primary key for the DOL Internal User Account.
M Querying Internal SecureAuth will require use of web services
developed by DoIT WSD.
1.7.4 The GUID shall be used to determine whether the user has an
existing DOL account and when no existing DOL account is found
the UAM shall display a message instructing the user there is an
issue with their account and they should contact the DOL web
system administrator.
M
1.7.5 The UAM shall check the user’s DOL Account status and when
“Disabled” shall process appropriately (see 1.8 Disable DOL
Account Processing).
M
1.7.6 The UAM shall check the user’s DOL Account status and when
“Active” the UAM shall set up and store session data within the
UAM (See 1.10 UAM User Session Requirements).
M
1.7.7 The UAM shall extract required Internal SecureAuth Account data
using the GUID and store as needed in the Session Data (see
Internal SecureAuth Documentation).
M
1.7.8 The UAM shall display the internal user’s name reflecting an
authenticated user status. M
1.7.9 The UAM shall display a “Log Out” reflecting an authenticated user
status and providing the user the option to log out. M
1.7.10 Internal users for NH DOL web applications will not manage any
Active Directory information thru UAM. M
1.8 Disable DOL Account Processing
1.8.1 At a minimum the UAM shall check a DOL User Account status for
“disabled” whenever a DOL application requests a permission
check.
M
1.8.2 A user whose account has been disabled shall not be allowed access
to any NHDOL Web application/function. M
1.8.3 UAM shall clear all session data immediately for a user identified as
Disabled. M
1.8.4 The UAM shall display a message instructing the user that an issue
with their account has been detected along with the DOL web
system administrator phone number.
M
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
11
1.9 Requested External DOL Account Processing
1.9.1 The following process shall be executed on the first authentication
directly following the External SecureAuth account creation and
repeated authentications whenever an external user logs
in/authenticates and their account status remains as “Requested”.
M
1.9.2 The UAM shall send an activation email to the external user with a
link that if clicked will trigger the UAM to activate the account. M
1.9.3 The UAM shall display the following message:
Your DOL account is not active at this time, an activation email has
been sent to the email address you provided. Please read this
activation email and follow the instructions to activate your account.
M
1.9.4 The UAM upon receiving the response from the activation link shall
integrate the DOL Account Status.
- When the DOL Account status is “Requested”, activate the account
and provide a successfully activated message to the user.
- When the DOL Account status is already activated provide a
message to the user informing them their account is already
activated.
- When the DOL Account status is neither “activated” or
“Requested” provide a message to the user informing them there is
an issue with their account and they should contact the DOL web
administrator for assistance.
M
1.10 UAM User Session Requirements
1.10.1 The following provides the minimum requirements for setting up
and managing a DOL web session for all users. M
1.10.2 The UAM shall maintain session data for each active user
authenticated on the DOL internal or external application web site. M
1.10.3 The UAM shall generate a session ID to be used as a key for
uniquely identifying a session. This Session ID will be passed to and
from the UAM to DOL Applications for access to UAM Session
Data.
M
1.10.4 The UAM session ID shall be complex and random making it very
difficult for anyone to predict its identity. M
1.10.5 The UAM session data shall be stored and maintained in a secure
fashion to safeguard it from unauthorized access. M
1.10.6 The UAM shall monitor all user activity and reset their Session
Expiration Date/Time based on the maximum session time-out value
stored in a configuration file.
M
1.10.7 The UAM shall monitor Session Expiration Date/Times and
terminate sessions appropriately. M
1.10.8 The UAM shall use any and all communications initiated from
within the UAM or DOL application as its method to monitor user
activity for the purpose of resetting Session Expiration Date/Times.
M
1.10.9 The UAM shall only consider a session authenticated when Session
Data exists matching the parameter Session ID and the Session
Expiration Date/Time has not expired.
M
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
12
1.11 Check Permissions on User Accounts
1.11.1 The following requirements will cover managing the process of
permission check requests submitted to the UAM by DOL
Applications. This process will require the acceptance of parameters
from the “Initiating DOL Applications”, processing the request and
then returning control to the “Initiating DOL Applications” with the
resulting parameters.
M
1.11.2 The UAM shall accept incoming parameter values from DOL
Applications and validate for completeness and accuracy and send a
request back to the Initiating DOL Applications with appropriate
parameters allowing for error messages and error handling.
M
1.11.3 The UAM shall verify the user is authenticated otherwise send a
request back to the Initiating DOL Applications with appropriate
parameters allowing for error messages and error handling.
M
1.11.4 The UAM shall reset the user’s Session Expiration Date/Time based
on this request. M
1.11.5 The UAM shall check the user’s DOL Account status for “Disabled”
and if true process appropriately (see 1.8 Disable DOL Account
Processing).
M
1.11.6 The UAM shall check user permissions for access to
application/function based on incoming parameters. M
1.11.7 When an error occurs in the permission check process the UAM
shall send a request back to the Initiating DOL Applications with
appropriate parameters allowing for error messages and error
handling.
M
1.11.8 When user to application/function permission check validates
approval the UAM shall send a request back to the Initiating DOL
Applications with appropriate parameters.
M
1.11.9 When user to application/function permission check fails to validate
approval the UAM shall send a request back to the Initiating DOL
Applications with appropriate parameters allowing for error
messages and error handling.
M
1.12 System Administrator Functions on External User Accounts .
1.12.1 The following requirements will cover managing the process of
searching external user accounts by criteria submitted by a System
Administrator and allow for a variety of functions to be performed
on a selected external user account. This feature will require an
interface with the State’s External SecureAuth application for the
searching and extraction of data not managed within the DOL User
Account Management application.
M
1.12.2 Shall be able to search external users by any combination of the
following account attributes; Last Name, First Name, Email
Address, Organization Name and Account Status
(Enabled/Disabled).
M
1.12.3 Shall display the results of all searches showing the following
account attributes; Last Name, First Name, Email Address,
Organization Name, Last Login Date, Account Status
(Enabled/Disabled).
M
1.12.4 Shall be able to export all data from the account search form to an
excel spreadsheet for download to the System Administrators local
drive.
M
1.12.5 Shall be able to sort the results of all searches by any single account
attribute. M
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
13
1.12.6 Shall be able to activate an external account as an alternative method
to an external user not responding to their activation email. M
1.12.7 Shall be able to browse an external account allowing the System
Administrator to view all of a selected external user’s account data
stored within External SecureAuth and the DOL UAM.
M
1.12.8 Shall be able to view a selected external account’s history log data
allowing the System Administrator to view all logged activity by the
account (per Event Recipient DOL Account ID). Shall be able sort
the results of these history logs by any single history log attribute.
M
1.12.9 Shall be able to view user history log data based on selected search
criteria of DOL User Account ID, IP Address, Date, or
Application/Function allowing the System Administrator to view all
activity for the selected criteria. Shall be able sort the results of these
history logs by any single history log attribute.
M
1.12.10 Shall be able to export all data from the external account’s history
log search results to an excel spreadsheet for download to the
System Administrators local drive.
M
1.12.11 Shall be able to select an external account for editing of the external
user’s account data stored within the DOL UAM. M
1.12.12 Shall be able to select an external account for editing of the external
user account status (enabled/disabled) stored within the DOL UAM. M
1.12.13 Shall be able to select an external account for editing of the external
user account permission data stored within the DOL UAM (see 1.13
Application/Function Permission Requirements).
M
1.13 Application/Function Permission Requirements
1.13.1 The following covers minimum requirements related to setting up
user permissions. M
1.13.2 Shall only allow external users to be assigned permissions to
external NHDOL applications/functions. M
1.13.3 Shall only allow internal users to be assigned permissions to internal
NHDOL applications/functions. M
1.13.4 The UAM shall be able to differentiate between users having
different levels of permissions. M
1.13.5 Only System Administrators shall be allowed to assign permissions
directly to user accounts. M Future applications will be designed
to provide internal users approval
capabilities on special permission
request.
1.13.6 Future to-be-developed DOL applications/functions may be
designated for default access by all authenticated DOL users with an
“Active or Enabled” DOL account status.
M
1.13.7 Future to-be-developed DOL applications/functions may require a
special permission request by the external users for access. These
special permission requests will be processed through a Permission
Request application outside the scope of this current UAM
requirements document (see 1.22 Special Permission Request and
Approval Processing).
M This referred to Permission Request
application is a future application
but should be considered when designing this UAM (see 1.22
Special Permission Request and
Approval Processing).
1.13.8 An application may have multiple functions and the UAM shall
allow the setting of permissions at a functional level within an
application.
M
1.13.9 Future applications being developed may involve non-standard
functions and the UAM must accommodate these non standard
functions.
M Search,, View, Add, modify and
approve/reject are considered standard functions currently.
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
14
1.14 Predetermined Configuration File Values
1.14.1 The following values or parameters shall be accessible and
maintainable by a System Administrator within the UAM. M
1.14.2 The value to identify the time period for maintaining a user session
active without any activity. This value could be expressed in
seconds or minutes.
M
1.14.3 The cross reference of SecureAuth function to target URL shall be
controlled using entries in a table providing easy administration for
future changes of SecureAuth URLs.
M
1.15 DOL Events Requiring History Logging
1.15.1 The following identifies events or actions the State desires to
capture and maintain History Logging on. Other events may be
required to fulfill the requirements of this document as determined
by the developer.
M
1.15.2 UAM shall insert a history log for the initial creation of a DOL
External User Account. M
1.15.3 UAM shall insert a history log entry identifying the creation of a
DOL Internal User Account. M
1.15.4 UAM shall insert a history log when an internal or external user logs
in through the DOL UAM. M
1.15.5 UAM shall insert a history log when an internal or external user logs
out of the DOL application session. M It is understood that not all users
will log out.
1.15.6 UAM shall insert a history log when a system administrator disables
an internal or external user account. The UAM shall require entry of
a note or comment when disabling an account which should also be
captured with the log.
M
1.15.7 UAM shall insert a history log for the direct modification of user
profile maintainable data items by a system administrator or the user
themselves on an internal or external user Account.
M
1.15.8 UAM shall log an entry into the history log when an internal or
external user account is activated by a system administrator. M
1.15.9 UAM shall log an entry into the history log when an internal or
external user account status is modified. The values of the before
and after `status shall also be captured in the log.
M
1.15.10 UAM shall log an entry into the history log when internal or
external user account permissions are modified. M
1.15.11 UAM shall insert a history log for the direct modification of
maintainable data items by a system administrator to application
information.
M
1.15.12 UAM shall insert a history log when a system administrator shuts
down an application. The UAM shall require entry of a note or
comment when shutting down an application which should also be
captured with the log.
M
1.15.13 UAM shall insert a history log when a system administrator brings
up an application. M
1.16 System Administrator Functions on Internal User Accounts
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
15
1.16.1 The following requirements will cover managing the process of
searching internal user accounts by criteria submitted by a System
Administrator and allow for a variety of functions to be performed
on a selected internal user account. This feature will require an
interface with the Internal SecureAuth application for the searching
and extraction of data not stored or managed within this DOL User
and Application Management module.
I
1.16.2 Shall be able to search internal users by any combination of the
following account data items; UserID, Last Name, First Name,
Email Address, Organization Name and Account Status
(Enabled/Disabled).
M
1.16.3 Shall display the results of all searches showing the following
account data items; UserID, Last Name, First Name, Email Address,
Organization Name, Account Status (Enabled/Disabled).
M
1.16.4 Shall be able to export all data from the account search results page
to an excel spreadsheet for download to the System Administrators
local drive.
M
1.16.5 Shall be able to sort the search results page by any single data item. M
1.16.6 Shall be able to create an internal account (see 1.17 Create DOL
Internal Account). M
1.16.7 Shall be able to browse an internal account allowing the System
Administrator to view all of a selected internal user’s account data
stored within the applicable State’s Active Directory and the DOL
UAM.
M
1.16.8 Shall be able to view a selected internal account’s user history log
data allowing the System Administrator to view all logged activity
by the account (per Event Recipient DOL Account ID). Shall be
able sort the results of these history logs by any single history log
data item.
M
1.16.9 Shall be able to view user history log data based on selected search
criteria of DOL User Account ID, IP Address, Date, or
Application/Function allowing the System Administrator to view all
activity for the selected criteria. Shall be able sort the results of these
history logs by any single history data item.
M
1.16.10 Shall be able to export all data from the all history log search results
to an excel spreadsheet for download to the System Administrators
local drive.
M
1.16.11 Shall be able to select an internal account for editing of the user’s
account data stored within the DOL UAM. M
1.16.12 Shall be able to select an internal account for editing of the user
account status (enabled/disabled) stored within the DOL UAM. M
1.16.13 Shall be able to select an internal account for editing of the user
account permission data stored within the DOL UAM (see 1.13
Application/Function Permission Requirements).
M
1.17 Create DOL Internal Account
1.17.1 The following requirements cover the process for a DOL Web
System Administrator to create a DOL Web Internal account from a
selected State Active Directory account.
M
1.17.2 The UAM shall require the System Administrator to provide the
exact UserId (ie msmith) of the State active directory account for
generation of DOL Internal Web account.
M
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
16
1.17.3 The UAM shall interface with the Internal SecureAuth application
using this UserId to pull the required State active directory account
data needed to set up the DOL Internal web account. The Internal
SecureAuth application will require the use of web service queries
developed and provided by DoIT Web Services division (See
Internal SecureAuth Documentation).
M
1.17.4 The UAM shall follow the generation of an Internal DOL Account
with passing control to the edit Internal DOL Account profile data
for completion by the System Administrator, followed by passing
control to the edit Internal DOL Account permissions for completion
by the System Administrator
M
1.18 Application Menu Page Requirements
1.18.1 The application menu page will be the default menu page for all
DOL Internal users not identified as a System Administrator type. M
1.18.2 The application menu page will contain a menu of only DOL
internal applications the internal user has permissions to access. M
1.18.3 The internal users shall be able to select an application from the
menu and the UAM shall transfer the user to the associated DOL
Applicable.
M
1.18.4 The UAM shall recheck permissions to the DOL Internal application
following the user’s selection from the menu. M
1.18.5 The UAM shall recheck the internal user account status
(enabled/disabled) following the user’s selection from the menu. M
1.18.6 The following options will be available to all users:
Logout/Login – toggle: if logged in, Logout option appears and vice
versa.
M
1.18.7 The Application Menu Page will contain an option to transfer to the
System Administrator Menu Page when the user is a DOL Web
System Administrator.
M
1.18.8 The Application Menu Page will contain an option to transfer to the
All Application Page (see 1.20 All Application Page
Requirements).
M
1.19 System Admin Menu Page Requirements
1.19.1 The System Administrator menu page will be the default menu page
for all DOL System Administrator type users. M
1.19.2 The System Administrator menu page will contain a menu of DOL
System Administrator applications/functions. M
1.19.3 The System Administrator menu page will contain an option to
transfer to the Application Menu Page. M
1.19.4 The following options will be available to all users:
Logout/Login – toggle: if logged in, Logout option appears and vice
versa.
M
1.19.5 The System Administrator Menu Page will contain an option to
transfer to the All Application Page (see 1.20 All Application Page
Requirements).
M
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
17
1.20 All Application Page Requirements
1.20.1 A separate page will need to be created to display to the users all the
available applications in the system. The listing will include only
application title and description. The page will include a brief
explanation that the user should contact his/her supervisor to request
permissions/authorization for use of these applications.
M
1.21 UAM Business Application Jump Page
1.21.1 The UAM business application jump page shall display the title of
the application. This title shall be stored and maintained within the
UAM.
M
1.21.2 The UAM business application jump page shall display an overview
of the DOL business application providing an understanding as to
who should be using the application and the purpose of the
application. This overview shall be stored and maintained within the
UAM.
M
1.21.3 The UAM business application jump page shall display any special
notes/comments about the DOL business application that the user
should be aware of. These notes/comments shall be stored and
maintained within the UAM.
M
1.21.4 The UAM business application jump page shall interrogate the users
authentication status and display standard instructions and options
for the user to log-in or create an External SecureAuth and DOL
web account.
M
1.22 Special Permission Request and Approval Processing
1.22.1 The following requirements are for an application or applications for
future development. They are included as part of this document
solely for consideration when designing the core UAM module.
F
1.22.2 This requirements section describe the State’s preliminary vision of
a process for providing external users the ability to request access
permissions to “Special Applications” on the DOL web application
site. These “Special Applications” are any applications that require
more than the standard default permissions. This process will also
involve the internal user’s review of these requests along with the
approval, rejection or revocation of permissions associated with
these requests. These requirements are preliminary and should be
considered in the current design of the UAM if applicable.
F
1.22.3 The internal users involved in the approving or rejecting these
permission requests on Special Applications could be a System
Administrator or a regular internal application user.
F
1.22.4 The form for requesting access to the “Special Application” shall be
dynamically generated so it can be used for multiple or all “Special
Applications”.
F
1.22.5 The form for requesting access to the “Special Application” shall
provide a title and description of the application. F
1.22.6 The form for requesting access to the “Special Application” shall
provide a description of who would need access to this specific
Special Application and why they would need access and any other
pertinent information.
F
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
18
1.22.7 The form for requesting access to the “Special Application” shall
prompt the requester for a descriptive reason why they need access
to the Special Application and any other pertinent information.
F Information provided with the
request by the external user as to
who and why access is needed to
these Special Applications will be a factor in the approval/rejection
process.
1.22..8 The form for requesting access to the “Special Application” shall
prompt the requester for contact information. F
1.22.9 The external user should be issued an email upon successful
submission of their request providing confirmation of their
successful submission.
F
1.22.10 Sometimes knowing the email address of the requestor is enough
information to satisfy the who and why factor in the
approval/rejection process.
ie. An email address under a Workers Comp carrier domain would
be all is needed to approve an external user’s access to Workers
Comp Insurance carrier State forms.
F
1.22.11 Selected internal users with expertise related to the subject matter of
the Special Application will require access permissions to the review
and approve/reject process application.
F
1.22.12 Selected internal users with access permissions to the review and
approve/reject process application shall be able to search for these
Special Application requests by Status (Requested, Approved,
Rejected).
F
1.22.13 When an internal user either approves or rejects an access request an
email should be generated to the external user informing them of the
action and a description of the reason if applicable.
F
1.22.14 When an internal user reviewing a request requires more
information they should be able to issue the requester an email with
text requesting the information needed.
F
1.22.15 The internal user should be able to record additional information to
the “Special Application” request providing a history of the
exchanges between the internal user and requester or the
accumulation of additional information.
F
1.23 Miscellaneous System Administrator Functions
1.23.1 System administrators shall be able to shut an application down with
an appropriate message. Users trying to access an application that
has been shut down will be shown the message as entered/given by
the system administrator shutting down the application.
M
1.23.2 System Administrators shall be able to block access to applications
from non-System admin users and provide an appropriate message
explaining the non-access status
D An example is when a new version of an application is being
implemented and during the
implementation period it is necessary to block access and
provide a message to users
attempting to access it.
NH DOL would like an analysis of
the costs associated with this feature before a final decision is made
regarding priority.
1.23.3 System Administrators shall be able to bring up an application that
has been shut down. M
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
19
Data Capture, Storage, Conversion and
Exchange
No. Description Priori
ty
Comments
2.1 General Requirements
2.1.1 All data taken in for storage in the database will be validated on both
the browser side and server side. M
2.1.2 Data validation for all fields will include checking incoming data
against field length, data type, format and screening for special
characters.
M
2.1.3 The application will display appropriate error messages to the user
whenever incoming data does not meet requirements. M
2.2 External SecureAuth External User Profile Data
2.2.1 The base profile information stored within the State’s External
SecureAuth application will be accessible to the DOL UAM
application through the External SecureAuth Interface Code.
I
2.2.2 Data name: GUID
Value Description: a primary key to External SecureAuth profile
data
Length: ?
I
2.2.3 Data name: username
Value Description: email address
Length: 216 characters
I
2.2.4 Data name: firstname
Value Description: users first name
Length: 40 characters
I
2.2.5 Data name: lastname
Value Description: users last name
Length: 40 characters
I
2.2.6 Data name: homephone
Value Description: users home phone number
Length: 20 characters
I
2.2.7 Data name: domesticphone
Value Description: users domestic phone number
Length: 20 characters
I
2.3 DOL External User Profile Data
2.3.1 The following identifies base data attributes the State desires to
capture and maintain beyond the generic user profile data managed
by External SecureAuth. Other data items may be required to fulfill
the requirements of this document as determined by the developer.
I
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
20
2.3.2 Data name: GUID
Description: GUID identifier from External SecureAuth
Length: ?
Maintainable by Sys Admin: No
Required: Yes
M Primary key to DOL External User
Profile Data
2.3.3 Data name: Developer’s Choice
Description: DOL user account status (Active, Disabled, Requested)
Length: Developer’s Choice
Maintainable by Sys Admin: Yes
Required: Yes
M Used to determine if the account
active, disabled or pending request approval
2.3.4 Data name: Developer’s Choice
Description: DOL user account type
Length: Developer’s Choice
Maintainable by Sys Admin: Yes
Required: Yes
M Used to identify the account as an
individual type, business organization
type or both
2.3.5 Data name: Developer’s Choice
Description: DOL user account organization
Length: Developer’s Choice
Maintainable by Sys Admin: Yes
Required: Conditional on type (Required for Business or Both)
M Organization the user is affiliated
with
2.3.6 Data name: Developer’s Choice
Description: DOL user account title within organization
Length: Developer’s Choice
Maintainable by Sys Admin: Yes
Required: No
M
2.3.7 The UAM shall provide an option for an external user to supply a
USA, Canadian, or International address.
Data name: Developer’s Choice
Description: DOL user account street address 1
Length: Developer’s Choice
Maintainable by Sys Admin: Yes
Required: No
M For UAM external users, address information will be optional,
however, within NH DOL web
applications there will be many forms and reports collecting multiple
addresses. Consideration should be
given to future application
development and their address needs.
2.3.8 Data name: Developer’s Choice
Description: DOL user account street address 2
Length: Developer’s Choice
Maintainable by Sys Admin: Yes
Required: No
M
2.3.9 Data name: Developer’s Choice
Description: DOL user account city address 1
Length: Developer’s Choice
Maintainable by Sys Admin: Yes
Required: No
M
2.3.10 Data name: Developer’s Choice
Description: DOL user account state address 1
Length: Developer’s Choice
Maintainable by Sys Admin: Yes
Required: No
M
2.3.11 Data name: Developer’s Choice
Description: DOL user account zip code
Length: Developer’s Choice
Maintainable by Sys Admin: Yes
Required: No
M
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
21
2.3.12 The UAM shall provide an option for an external user to supply a
USA, Canadian, or International address.
Data name: Developer’s Choice
Description: DOL user account Canadian Address
Length: Developer’s Choice
Maintainable by Sys Admin: Yes
Required: No
M A good reference for
Canadian addressing:
Reference for Canadian mailing addresses: http://www.canadapost.ca/tools/pg/manual/PGaddress-e.asp Also see: http://pe.usps.com/search/jsp/search/advSearch.jsp?QueryText=international&btnSubmit.x=9&btnSubmit.y=10&ResultStart=1&ResultCount=20&serverSpec=56.0.145.56%3A9920&LastQuery=&SortSpec=Score+desc&Coll=PE_PUB28_HTML_5&Action=FilterSearch
2.3.13 The UAM shall provide an option for an external user to supply a
USA, Canadian, or International address.
Data name: Developer’s Choice
Description: DOL user account International Address
Length: Developer’s Choice
Maintainable by Sys Admin: Yes
Required: No
M Since we cannot reasonably
anticipate all possible address
schema outside of the US and
Canada and expect very few
others, please allow for a ‘free
form’ international address of
up to five lines.
2.4 DOL Application Profile Data
2.4.1 The following identifies base data attributes the State desires to
capture and maintain on NHDOL applications. Other data items may
be required to fulfill the requirements of this document as
determined by the developer.
Other data items are expected to be required based on jump page
design, All Application Landing Page design, Special Permissions
Request and Actions Process.
I
2.4.2 Data name: Developer’s Choice
Description: DOL Application Name
Length: 50
Maintainable by Sys Admin: No
Required: Yes
M
2.4.3 Data name: Developer’s Choice
Description: DOL Application Title
Length: 75
Maintainable by Sys Admin: Yes
Required: Yes
M
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
22
2.4.4 Data name: Developer’s Choice
Description: DOL Application Description
Length: 250
Maintainable by Sys Admin: Yes
Required: Yes
M
2.4.5 Data name: Developer’s Choice
Description: Display on menu indicator
Length: Developer’s Choice
Maintainable by Sys Admin: Yes
Required: Yes
M
2.4.6 Data name: Developer’s Choice
Description: Internal/External Application Flag
Length: Developer’s Choice
Maintainable by Sys Admin: No
Required: Yes
M Indicator to identify the applications
as an External application.
May be eliminated per developer
2.5 DOL User History Log Data
2.5.1 The following identifies base data attributes the State desires to
capture and maintain on DOL User History Logs. It is assumed
other data items will be required to fulfill the requirements of this
document. The State wishes to track all significant user actions
taken. It may also be applicable to utilize separate logs for tracking
changes and actions taking place.
M
2.5.2 Data name: Developer’s Choice
Description: DOL User Account ID
Length: same as DOL Account ID
Maintainable by Sys Admin: No
M This account ID data relates
to the user taking the action.
2.5.3 Data name: Developer’s Choice
Description: IP address used by user to gain access
Length: Developer’s Choice
Maintainable by Sys Admin: No
M This account data relates to
the user executing the event
when applicable.
2.5.4 Data name: Developer’s Choice
Description: Date and Time of event
Length: Developer’s Choice
Maintainable by Sys Admin: No
M
2.5.5 Data name: Developer’s Choice
Description: Event Recipient DOL Account ID
Length: same as DOL Account ID
Maintainable by Sys Admin: No
M This account data relates to
the recipient of action (ie. The
User Account ID of the user
being disabled by a system
administrator).
2.6 DOL Internal User Profile Data
2.6.1 The following identifies base data attributes the State desires to
capture and maintain on DOL Internal User accounts. Other data
items may be required to fulfill the requirements of this document as
determined by the developer.
M
2.6.2 The UAM shall prevent the deleting of a DOL Internal Account. M
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
23
2.6.3 Data name: Developer’s Choice
Description: DOL Internal User Account ID
Length: Developer’s choice
Maintainable by Sys Admin: No
Required: Yes
M
2.6.4 Data name: Developer’s Choice
Description: Account status (enabled/disabled)
Length: Developer’s Choice
Maintainable by Sys Admin: Yes
Required: Yes
M
2.6.5 Data name: Developer’s Choice
Description: Account organization unit
Length: Developer’s Choice
Maintainable by Sys Admin: Yes
Required: Yes
Drop Down: Yes
M
2.6.6 Data name: Developer’s Choice
Description: User’s job title
Length: Developer’s Choice
Maintainable by Sys Admin: Yes
Required: Yes
M
2.6.7 UAM must keep some user identifier and an indication that the user
is an internal user.
Data name: Developer’s Choice
Description: Internal User Indicator
Length: Developer’s Choice
Maintainable by Sys Admin: No
Required: Yes
M
2.7 State Active Directory User Profile Data
2.7.1 Internal users for NH DOL web applications will not manage any
Active Directory information thru UAM.
M
2.7.2 The base profile information stored within the State’s Active
Directory application will be accessible to the DOL UAM
application.
I
2.7.3 Data name: UID
Value Description: a primary key to Active Directory profile data
Length: Developer’s Choice
I
2.7.4 Data name: UserID
Value Description: UserID of active directory user
Length: Developer’s Choice
I
2.7.5 Data name: firstname
Value Description: users first name
Length: Developer’s Choice
I
2.7.6 Data name: lastname
Value Description: users last name
Length: Developer’s Choice
I
2.7.7 Data name: Email Address
Value Description: Email address of active directory user
Length: Developer’s Choice
I
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
24
Hardware and Software Platform
No. Description Priori
ty
Comments
3.1 The application must run on a Windows 2008 Server M
3.2 The application must interface with a Windows 2008 database
server running SQL2008 through web services running on an
application server.
M ‘SQL2008’ means Microsoft
SQL Server 2008
3.3 The application shall be written and developed in Microsoft .Net M
Output/Reports
No. Description Priori
ty
Comments
4.0 M
Testing/Training
No. Description Priori
ty
Comments
5.1 Vendor must test to assure application meets all identified business
requirement functions/features to assure compliance before being
submitted to State for State Testing.
M
5.2 Vendor must provide State proof of application passing security
analysis testing before being submitted to State for State Testing. M
5.3 Must pass State code review on compliance with State standards M
5.4 Must pass State acceptance testing to assure application meets all
identified business requirement functions/features M
Security Requirements
No. Description Priorit
y
Comments
6.1 Must comply with all State security standards M
6.2 Must comply with all State (DoIT WSD) application standards M
6.3 Must comply with all database industry standards M
6.4 Must comply with all database best practices M
6.5 The use of SecureAuth requires application use SSL M DoIT will have to confirm
this.
6.6 All data taken in to database tables related to UAM will be
validated in accordance with the requirements identified in the
Public and Admin Side requirements for Contact NHDOL.
M
Implementation
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
25
No. Description Priorit
y
Comments
7.0 Detailed plan for application roll out will be created to insure a minimum
amount of operational interruption. M
Performance and Response Time Requirements
No. Description Priorit
y
Comments
8.0 M
Data Archival, Backup and Recovery
Requirements
No. Description Priorit
y
Comments
8.1 N/A – State operations responsibility
8.x
6. ACCEPTANCE CRITERIA
6.1 Acceptance Criteria Matrix
Criteria Id. Description Measurement Requirement(s)
Validated
1 Application must pass penetration
testing
Stellareware to provide State with
Penetration Security Analaysis
report indicating a State acceptable
level of security.
Pass penetration testing perform by
State DoIT staff.
5.2
2 Application must pass code review
by State
Pass code review performed by
State DoIT WSD Staff
5.3
3 Must pass State Acceptance Testing
Plan. This plan will be developed to
test all business requirements are
met.
All functions and features
described in this document are
provided according to functional
design specifications unless
otherwise noted.
5.4
7. ISSUES LOG
User and Application Management Module
NH Department of Labor
Functional Design Phase Business Requirements Document
DoIT, Agency Software Division - Labor
26
The issues log is a table that tracks any issues that arise after this document is approved and signed. Its purpose is to
update the document while leaving the original content intact. The issues log can be maintained in an Excel
worksheet and “pasted” into this Word document.
The issues log should include the following details:
Issue Number
Date Logged
Requirement Number (a reference to the original requirement that is impacted)
Issue description
Resolution description
Date Resolved
Decision Made By
The issues log worksheet can also be used to track all requirements, design/development, and/or solution alternatives
issues that occur after the corresponding documentation is signed.