addendum 2 rfp 2015 099 dol web development and support ... · vendors and state responses will be...

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


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)


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


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?


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?


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


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?


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?


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


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 , 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


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


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


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


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


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?


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.


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.


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.


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.


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


11

# PG.

NO.

SECTION

REFERENCE

QUESTION ANSWER


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.


Systems

Requirements

Are any other interfaces, in addition to File pickups, needed

with any internal/ external applications?

Not at this time.


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.


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?


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


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.


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?


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?


RFP 2015-099


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


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?


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


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?


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


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


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


16

# PG.

NO.

SECTION

REFERENCE

QUESTION ANSWER


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.


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.


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


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?


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


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?


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



b. Which version(s) of MVC are supported?

None. The application should be developed using webforms.

132 RFP

GENERAL

QUESTIONS



c. Is there a preference for either C# (C-Sharp) or

VB.NET?

C#

133 RFP

GENERAL

QUESTIONS



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


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?


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


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.


The contract awarded vendor will be responsible for Penetration

Security Testing.

RFP 2015-099


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.


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?


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


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




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




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




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




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

mailto:[email protected]





UAM




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




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




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

https://dev.sson.nh.gov/secureauth41/SecureAuth.aspx

https://dev.sson.nh.gov/secureauth41/SecureAuth.aspx

UAM




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




11

Returns a single record for a user based on the user.

Parameter: applicationId Type: GUID *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





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




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




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\-

\@?^=%&amp

;/~\+#])?

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




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




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




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


Future development of the UAM will include an interactive application users can use to request

permission to specific applications.

UAM




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


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




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




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

[email protected]”



UAM




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




21

^.{1,40}$ greater than 40 characters in

length. Address2 Textbox ^.{0,40}$ Address, line 2, 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


^.{1,40}$








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’.


^.{1,40}$





UAM




22






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




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




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




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




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




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




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




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




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)




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


IPAddress varchar(44)

LastAccessed datetime

Salt binary(32)

EventLog

PK Event ID int

EventDate datetime

UserID int



Table varchar(30)

RecordID int

Event varchar(80)

Note varchar(200)

Salt binary(10)

ErrorLog

PK ErrorLogID int

ErrorDate datetime


UserID int


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

Email

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



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





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









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.





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.





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

http://www.nh.gov/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.





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


“Requested” shall process appropriately (see 1.9 Requested

External DOL Account Processing).

M





9


“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





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


“Disabled” shall process appropriately (see 1.8 Disable DOL

Account Processing).

M


“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





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





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 .


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





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


user account status (enabled/disabled) stored within the DOL UAM. M


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


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


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.





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





15


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





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





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


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





18


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





19

Data Capture, Storage, Conversion and

Exchange


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


I

2.2.5 Data name: lastname

Value Description: users last name


I

2.2.6 Data name: homephone

Value Description: users home phone number


I

2.2.7 Data name: domesticphone

Value Description: users domestic phone number


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





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


Description: DOL user account type



Required: Yes

M Used to identify the account as an

individual type, business organization

type or both


Description: DOL user account organization



Required: Conditional on type (Required for Business or Both)

M Organization the user is affiliated

with


Description: DOL user account title within organization



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



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.


Description: DOL user account street address 2



Required: No

M


Description: DOL user account city address 1



Required: No

M


Description: DOL user account state address 1



Required: No

M


Description: DOL user account zip code



Required: No

M





21




Description: DOL user account Canadian Address



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




Description: DOL user account International Address



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


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


Description: DOL Application Name

Length: 50


Required: Yes

M


Description: DOL Application Title

Length: 75


Required: Yes

M

http://www.canadapost.ca/tools/pg/manual/PGaddress-e.asp



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














22


Description: DOL Application Description

Length: 250


Required: Yes

M


Description: Display on menu indicator



Required: Yes

M


Description: Internal/External Application Flag



Required: Yes

M Indicator to identify the applications

as an External application.

May be eliminated per developer

2.5 DOL User History Log Data


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


Description: DOL User Account ID

Length: same as DOL Account ID


M This account ID data relates

to the user taking the action.


Description: IP address used by user to gain access



M This account data relates to

the user executing the event

when applicable.


Description: Date and Time of event



M


Description: Event Recipient DOL Account ID

Length: same as DOL Account ID


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


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





23


Description: DOL Internal User Account ID

Length: Developer’s choice


Required: Yes

M


Description: Account status (enabled/disabled)



Required: Yes

M


Description: Account organization unit



Required: Yes

Drop Down: Yes

M


Description: User’s job title



Required: Yes

M

2.6.7 UAM must keep some user identifier and an indication that the user

is an internal user.


Description: Internal User Indicator



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


I

2.7.4 Data name: UserID

Value Description: UserID of active directory user


I

2.7.5 Data name: firstname

Value Description: users first name


I

2.7.6 Data name: lastname

Value Description: users last name


I

2.7.7 Data name: Email Address

Value Description: Email address of active directory user


I





24

Hardware and Software Platform


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


ty

Comments

4.0 M

Testing/Training


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





25


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


y

Comments

8.0 M

Data Archival, Backup and Recovery

Requirements


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





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.