HomeMy WebLinkAboutCAG2019-320 - Change Order - #1 - Calytera US, Inc. - Amanda Permitting System for Phase 1 Pilot Phase - 01/13/2020CALYTERA PROJECT CHANGE REqUEST
City of Kent
City of Kent - Permitting System for Phase L- Pilot Phase
Calytera
Derek McConnery - Calytera Project Manager
co-1
High January 1,3,2020
Client
Project Name
Change requested by:
Project Manager:
Change Request #
Urgency:uestedDate
Change Title Milestone Adjustment for Phase 1 lnterfaces
Change Request ldentification
Description The complexity and work required to complete the integration between Amanda &
Bluebeam was underestimated. The work required to properly lmplement this
integration will extend beyond the Phase l" timeline as descried in the SOW.
Calytera recommends decoupling the Bluebeam integration from the rest of the
scope of Phase 1. This would mean that the work would continue after System
Verification in Phase 1, run in Parallel to the early tasks of Phase ll, but be completed
sooner than the remainder of the interfaces in Phase 2.
The GIS intertace would happen within Phase l- as originally planned - there is no
change to the scope of timing of the GIS interface tied to this change order.
Justification This S0 change order aligns the project milestones better with the work and
distributes payments more evenly. Processing this change order allows us to
maintain momentum for the project without delaying the Phase 2 work until the
Bluebeam integration is complete.
Priority H igh
uest DetailsChane
Cost There is no additional cost associated with this change order
Existing project milestones will change as follows;
Milestone 5 lnterfaces Analysis and Mapping Specification - 520,000.00 will be split
into two milestones;
o Milestone 5A lnterfaces Analysis and Mapping Specification GIS - 57,500.00
r Milestone 5B lnterfaces Analysis and Mapping Specification Bluebeam -
s12,500.00
Milestone 9 lnterfaces Configuration QA - - 520,000.00 will be split into two
milestones;
Milestone 9A lnterfaces Analysis and Mapping Specification GIS - 57,500.00a
Evaluation
Dona I nI )
CALYTERA PROJECT CHANGE REQUEST
Milestone 98 lnterfaces Analysis and Mapping Specification Bluebeam -
s12,500.00
Schedule There is a minor impact to the schedule caused by this change order, a portion of the
Phase 1 work will not be completed as scheduled. lt is assumed through this change
order that the work associated with the Bluebeam integration will extend into the
Phase 2 timeline. The overall project duration of Phase 0, Phase l and Phase 2 is not
impacted through this change order.
Schedule will continue to be maintained and update by Calytera & City of Kent
Proiect Managers.
Risk There are no significant risks with associated with this change order
Alternatives and
recommendation
This change order has already been verbally agreed to, in not moving forward, we
would need to pause in progress on Phase 2 tasks.
It is recommended we move forward with this change order
lm plementation Options
N/A
ct:
(by signing this form, the client outhorizes Calytero to engoge Vision33 to implement the chonges
identified in this Chonge Order):
Derfsion
Wnn
Rationale: (if denied or on hold)
Approved
Denied
Place on Hold
Section 1: To be completed by the Client
Vt(€ eAwtrJa+tztr,lName (Print)
Title:.t/Tr ileffie
Signature:
Date:I v "47e
Dana ) al 2
CALYTERA PROJECT CHANGE REQUEST
City of Kent
City of Kent - Permitting System - Phase 2
Calytera
Derek McConnery- Calytera Project Manager
CO-1 (Phase 2)
High February 2nd,2020
Client
Project Name
Change requested by:
Project Manager:
Change Request #
Urgency:Date Requested
Titlech lnterface Chan nal contract sco addi of Kent Portal SSOto
Change Request ldentification
Description The City of Kent contract identified 9 total interfaces (2 in Phase I and 7 in Phase ll).
The following interfaces identified in Phase ll are no longer needed and are removed
from the contract scope of work, by approval of this change order:
r State/e-Gov Alliance lnterface
r Address Authority lnterface
The following interface, by approval of this change order will be added to the Phase
ll interface:
. City of Kent Portal SSO
ln accepting this requested change, please be aware of the following
assum ptions;
1-. No additional interface other than what is outlined above in the scope
description is included.
2. Exhibit A describes the high level scope of the SSo integration requested by
the City of Kent which Vision 33 used to estimate the effort required to
complete this integration, and validate a similar level of effort required to
the interfaces originally in scope, so that we could accommodate the
request to swap interfaces This detail will be used to formally document the
scope of this interface during the analysis sessions.
3. Any changes requested to the City of Kent SSO interface not described in this
change order or in the analysis documentation completed in phase 2 will be
considered not in scope and may result in additional change orders.
Justification The contract included 2 interfaces that are no longer needed and did not include the
portal SSO which is needed for consistency within the City of Kent for the online
services they provide the public.
Prio H
Detailsch
Cost Total cost for this change order is S0 and includes the analysis, lnterface
configuration, internal QA testing, support, project management.
Evaluation
Doaa 'l nf Q
CALYTERA PROJECT CHANGE REQUEST
Schedule As part of the detailed analysis of interfaces, Vision 33 will assess the impact to the
project schedule duration as a result of this change. Currently, we do not expect a
significant impact to the project duration. Calytera, Vision 33 & the City of Kent will
work to accurately update the project schedule based on the change in scope.
The project schedule will continue to be maintained and update by Calytera & City of
Kent Project Managers.
Risk Additionalwork effort has a potential to impact duration on the project schedule
Depending on availability, the impact may be mitigated by a dedicated resource
assigned to concu rrently deve lop fu nctional ity.
Alternatives and
recommendation Calytera recommends moving forward with this change order
lmplementation Options
N/A
DecisionBnn
Approved
Denied
Place on Hold
Rationale: (if denied or on hold)
GI:
(by signing this form, the client authorizes Colytera to engoge Vision33 to implement the chonges
identified in this Chonge Order):
Sectlon 1: To be completed by the Client
Name (Print)$r"tz, P^,L+-
Title:f,r*** /tu/^--*-
Signature AE:{
Date:2 /a?/e^r n
I
Dana 2 n{ Q
CALYTERA PROJECT CHANGE REQUEST
Exhibit A; SSO High Level Scope;
City of Kent SSO- Amanda lntegration Meeting
Msting:
Attende€si
01-16-2020 I AM PST
Amy Keophilavong - Clty of Kent
Gregg Sconce - City of Kent
Fang Gao - Vision33
Jo*ph Jung - Vlslon33
Rhonda Lake - Visionfl
We had a great meeting thls mornlng. Thanks for the brainstormlhg sesston and progresslve
design conversations to integrate the City of Kent SSO portal with the Amanda Enterprtse
Platform.
Let me know if I have missed something or would like to add.
Thanksl
Amy
Summary
The meeting was about using the City of Kent SSO portal as the authorlzation and authenticatlon
gateway to the Amanda Enterprise Platform. We revlewed the last meeting notes and connrmed
the hlgh-lev€l dlscusslons of fhe SSO workflow proeess,
In this meeting, we dug deeper to brainstorm solutions to send authenticated users to Amanda,
We have come up with a couple of solutions:
. Web service. Server to server authentication
o Because Amanda is hosted in-house
The web servlce ls the prefefted solution for the Clty of Kent because of the outlook of
lntegrating with many other third-party solutlons, The Clty of Kent lvants a standard practlce of
SSO integrdtion. Gregg will explore the possibility of server to server authentication. Amy will
draft a web service for Amanda to use. Once th€ Amanda proJect ls on schedule, Amy wants to
work with a dedicated developer from Vlsion33 to design, test, and integrate the solution for
Amanda to use the City of Kent SSO for authenticatlon.
We talked about the log-out functionality for the user and determined that the relationship
between SSO and Amanda is for authentication only. Amanda will manage its own log out
functionality for the user. Gregg and Amy agree because given the scenario that the user can be
logged into the Business and Occupation Tax website and be in Amanda at the same time. If the
user logged out of SSO in Amanda, they will also be logged out of the Business and Occupation
Tax website.
Daaa 2 nf Q
CALYTERA PROJECT CHANGE REQUEST
The next following pages will contain details about the web service design conversation we had
in the meeting. I made some assumptions and we can finalize those assumptions later.
Please note that the following design and architecture identified is a rough draft and is not
considered final, lt is to clarify and give an idea qf what wc talked about in th€ meeting. The
story and scenarios are additional background to give an understanding ofthe design
conversation. It may be too much lnformation now, but it's best to have the details beforehand
to help with the design. We will have additional discussions once the praJect is seheduled.
Story
A r€sldent wants to apply for a city permit to bulld a deck on the second story of thelr house.
The resident contacts the City and is told that they can apply online by going to this website
address,
http l //amaawbtlv . ci . kent . vra , u5 ;8980/ citizenportal/
The website requires the resident to log in, The resident is automatically redirected to the City of
Kent SSO portal where the resident enters thelr username and pa$sword, The username and
password are authenticated, and the resident is redirected back to the website to apply for a city
permlt.
Design and Architecture
The City of Kent will give Amanda an encrypted 5SO client token to use when lt ls redlr€ctlng the
resident to the S5O portal. This encrypted token is for SSO to verify that Amanda is a valld
applicatlon ln the SSO system.
*
Figure l. Step I
When the resident's credentials are authenticated, 5SO will generate a verification token and
redirect the resident back to Amanda with a verification token, This verification token is different
from the 5SO client token and the token will be different for every authentication.
ryF*rreL*gBtrsythdc,sr
Doaa A al A
CALYTERA PROJECT CHANGE REQUEST
ilrymv.d$ f rffia*m*rrrr-dlLs
Flgure 2. Step 2
Amanda will take that verification token and call the 5SO web service to send a request for the
aulhenticated resident.
Figure i. StEp 3
The SSO web service verifies the verification token. [f the verification token has expired, 30
second lifespan, the resident will be redirected back to the City of Kent SSO portal to log in
again. This will restart the cycle of authentication and regenerate a new verificalion token and
send it to Amanda for Amanda to verify the token again.
The verlfication token contalns a unique ID ofthe authentlcated resldent. SSO takes that ID to
g€t the resldent's data: flrst name, last name, emall address and phone number. SSO will
generate an authenticatlon token to conclude that the request from Amanda is compl€te. SSO
will package the data and send via web service(?) to Amanda.
AErtr Cly ol K.(l
ssor1,s
Dona E nf Q
CALYTERA PROJECT CHANGE REQUEST
Figure 4. Step 4
Amanda will accept the package and authorize access to the authenticated resident
Details
When the resident Eo€s to the website, Amanda checks if the resident is authenticated to access
Amanda. If the resident is not, Amanda redirects the resident to this website address using the
following URI structure:
https I //s sotst , kentwa . gov/IT+08paC6oApOt'lHCVdQlPKnBEvjSIHXDbt4DDpgYbF3QRWiBaxt
z0skv20kPygC)Ol26TuYAA60ABgUFsvQTf59pmEDgKVvn4Sr',ZnYoEz0ou?sgg+m{lLLpK99
This is the City of Kent gSO portal address
https: /lssotst . kentHa. gov/IT+0Bpac6oApOt4HCVdQlPKnEEvjBIHxobtlDDpgYbF3QRtiJisaxt
Z9s kV2OkPySC)(l126TuYAoGOAB gU F sVQTf 5 9pmE DSKVv n4Sh,ZnYoBzOoU2Sgg+lv1w3 L LpK99
This is the encrypted S5O cllent token that the Clty of Kent wlll give to Amanda to use to
redirect to the SSO portal,
https : //ssotst . kentwa . gov/IT+OBpaC6oAp0{,{HCVdQIPKnBEvJgIHXDbI{DDpgYbFSQRWIBaxt
z0s kvzokPyScxfl 26TuYA06OAB gUF 5VQTf 5gpmEDSKVvn4SwZnYoBzOoU zs8g+{'',b,r3 L Lp(g 9
The SSO client token is generated by the CiW of Kent and is uniquely different to each
application that integrates with SSO, The SSO client token is encrypted and given to Amanda to
use as a handshake between Amanda and SSO. SSO decrypts the SSO client token and uses it
to redirect the resident back to Amanda once their credentials are authenticated,
If the SSO client token ls compromlsed, lt does not hold any value. It is a token for 5SO to know
where to redirect back when the resident's credentlals are authenticat€d.
Dana A nf Q
CALYTERA PROJECT CHANGE REQUEST
If the encrypted SSO client token was manipulated or changed, it does not afrect Amanda or
SSO. SSO will prompt the residentto select one of the options in the, J wantto..., drcp-down
list. See Figure 5. Amanda will be one of the options in the drop-down list.
if the resident does not use the given website address and goes directly to the 5S0 portal,
https:/,/ssotst.kentwa.gov/, the resident can select Amanda in the, I want to... drop-down
llst and wlll be redlrected to Amanda when the resldentt credentlals is authenticated.
KENT
Prrrmrd
T
Ffc Surira!$ & osl?rilon Til
flgure 5. I want ta ... optlons to rcTess City of Kent servlces
When the resident's credentials are authenticated. 5SO wlll generate a verlfication token. The
verlfication token will contain a unigue identifier of the authenticated resident and the lifespan of
the token is 30 seconds.
SSO will redirect the authenticated resident to Amanda with the verlfication token,
Amanda will take the verification token and send it back to SSO using a web service call,
Dona 7 al L
CALYTERA PROJECT CHANGE REQUEST
The SSO web service accepts the request from Amanda and verifies the verification token. If the
verification token expired, SSO web service will redirect the resident back to the SSO portal login
page. If the resident's session in 5SO is still active, the resident does not need to enter their
username and password.
The ASP .Net ldentlty Manager manages the session activlty of the authenticated user, If the
session activlty l$ stale for one hinute, the Manager logs the user out by cl€anlng out the
se$sion.
If the resident's sesslon in SSO in not active, meaning they've been logged out, the resident
must enter their username and password to be r€authenticated.
SS0 will regenerate a new verification token and the process starts over again.
If the verification token is still active, 5SO will extract the token to find the unique identifier. The
unique identifier will help SSO get the following data of the authenticated residenti first name,
last name, email address, and phone number.
5SO will generate an authorhation token to complete the reque$t and be packaged together with
the authenticated resident's data.
Not sure how to send the data package to Amanda. In the workflow diagram I assumed Amanda
web servlce. We can Flnalize that deslgn lat€r.
Once Amanda receives the data package, Amanda will use its authorization functionality to
authoriz€ the authefiticated resident.
Log off procedures for 550 and Amanda
The relationship between Amanda and SSO is to only authenticate users.
We have agreed that there will not be any functionality to log the user out of S5O from Amanda.
Amanda will manage its own log out functionality.
SSO will automatically log out the resldent when there ls no session a€tlvity ln the Identlty
Manager.
Dona a nf a