crash idp hardware/software recommendation
Post on 12-Sep-2021
1 Views
Preview:
TRANSCRIPT
CRASH IDP
Hardware/Software
Recommendation Crash Reporting and Analysis for Safer Highways (CRASH)
CRASH Identity Provider Recommendation
VERSION 1.6
Revision Date: January 7, 2013
1
Table of Contents Section 1 .......................................................................................................................... 3
Document Information ................................................................................................................................. 3
1.1 Contributors ........................................................................................................................................ 3
1.2 Version Control ................................................................................................................................... 3
Section 2 ........................................................................................................................................................ 4
Overview ....................................................................................................................................................... 4
Purpose ..................................................................................................................................................... 4
2.1 Scope ................................................................................................................................................... 4
Document Conventions ............................................................................................................................ 4
Section 3 ........................................................................................................................................................ 5
Identity Provider Configuration .................................................................................................................... 5
What is an Identity Provider (IdP)? ........................................................................................................... 5
3.1 Hardware ............................................................................................................................................ 5
3.1.1 Single vs. Multiple (Core) Processors ............................................................................................... 5
3.2 Software .............................................................................................................................................. 6
3.2.1 Apache Tuning ................................................................................................................................. 6
3.2.2 JVM Tuning ....................................................................................................................................... 6
Section 4 ........................................................................................................................................................ 7
TxDOT IdP Platform Configuration ................................................................................................................ 7
Introduction .............................................................................................................................................. 7
Hardware .................................................................................................................................................. 7
Software .................................................................................................................................................... 8
Section 5 ...................................................................................................................................................... 10
User Management Infrastructure ............................................................................................................... 10
Introduction ............................................................................................................................................ 10
Shibboleth Components ......................................................................................................................... 10
How does Shibboleth work with CRASH? ............................................................................................... 11
Step 1 (User ⇔ Browser ⇔ Service Provider): ................................................................................... 12
Step 2 & 3 (Browser ⇔ Discovery Service): ........................................................................................ 12
Step 5: (Discovery Service ⇔ Browser ⇔ Service Provider): ............................................................. 13
Step 6: (Service Provider ⇔ Browser ⇔ Identity Provider): .............................................................. 13
Step 7: (Identity Provider ⇔ Browser): .............................................................................................. 13
CRASH IdP Hardware/Software Recommendation
2
Step 8: (User ⇔ Browser ⇔ Identity Provider): ................................................................................. 13
Step 9: (Identity Provider ⇔ Browser ⇔ Service Provider): .............................................................. 13
Section 6 ...................................................................................................................................................... 16
FAQ .......................................................................................................................................................... 16
Troubleshooting ...................................................................................................................................... 17
Definitions: .............................................................................................................................................. 19
Links ........................................................................................................................................................ 20
CRASH IdP Hardware/Software Recommendation
3
Section 1
Document Information
1.1 Contributors
Role Organization Name
Owner TxDOT-TRF-TE-SCPDA
Contributor TxDOT-TRF-TE-SCPDA Margo McCormick, Lyndon Clements,
Ron Holt, Harold Campbell Jr., Susan
Kirkpatrick, Missy Rodgers, Debbie
Williams, Jennifer Castillo, Bea Pyle,
Judy LeViseur
Contributor Technology Consortium Mark McCalister, David Palacios, Dan
McLaughlin
1.2 Version Control
Date Version Author(s) Section(s) Update(s)
12/1/2011 1.0 TxDOT All Final Review
2/1/2012 1.1 TxDOT All Final Review
2/16/2012 1.2 TxDOT All Final Review
6/14/2012 1.3 TxDOT 5 Remove www. From url
address, Update Landing Page
Picture
10/19/2012 1.4 TxDOT 4 Update Apache Tomcat
11/20/2012 1.5 TxDOT All Final Review
1/7/2013 1.6 TxDOT All Final Review
CRASH IdP Hardware/Software Recommendation
4
Section 2
Overview
Purpose
The purpose of this document is to describe the recommended hardware and software matrix for
installing and configuring an identity provider (IdP) for use in conjunction with the Crash
Reporting and Analysis for Safer Highways (CRASH) application. Additionally, the document
provides some detail for working configurations in use by the Texas Department of
Transportation (TxDOT) for multiple environments in the systems development life cycle.
2.1 Scope
This document covers the recommended base hardware and software list that comprises an
identity provider for use by CRASH pilot agencies. Each agency will need to analyze and design
the preferred hardware and software configuration that is best suited to provide service to their
stakeholders.
Document Conventions
Italic type is used for URLs, filenames, file extensions, and environment variables.
CRASH IdP Hardware/Software Recommendation
5
Section 3
Identity Provider Configuration
What is an Identity Provider (IdP)? This is a server(s) that handles authentication of users, allows a user(s) token with trusted
information to be securely sent through the browser to a remote resources. Each CRASH pilot
agency is responsible to set up its own IdP to authenticate their users. NOTE: the
recommendations herein are simply meant to give you an idea of what types of systems you
should be looking at. Many other hardware/software variations can be used successfully; for the
latest hardware and software recommendations, refer to the online copy of the recommendations
at https://spaces.internet2.edu/display/SHIB/IdPPlatform.
3.1 Hardware The following hardware is sufficient for deploying an IdP that provides a basic example of how
Shibboleth is used (on the order of 25-40 logins per minute):
Pentium III class processor in the 1GHz range
512MB RAM
150MB storage
Any Ethernet card
The following hardware is suited for a production deployment supporting around 150
simultaneous requests.
Xeon/Opteron class processor (mid-level spec)
2GB RAM
Gigabit Ethernet card
To increase the availability, the production machines should have their hard drives mirrored
(RAID 1). The use of multiple servers and load balancing hardware is also suggested.
3.1.1 Single vs. Multiple (Core) Processors Unlike most web applications, the IdP is CPU-bound because of the large number of
cryptographic operations performed. Most multi-core systems sacrifice some CPU speed because
of thermal issues in order to get more cores on the CPU. Since Java 5, most JVMs now scale
across cores, but our recommendation is that faster cores over more cores is still the better option.
This results in lower response times (because the crypto operations are performed more quickly),
but slightly less overall throughput.
CRASH IdP Hardware/Software Recommendation
6
3.2 Software
Generally the IdP is run within Tomcat with an Apache HTTP server front-end. Apache 2 and
Java 6 are recommended. Be sure to tune both Apache and the JVM used by Tomcat
appropriately.
3.2.1 Apache Tuning
The most influential tuning within Apache is the MPM used and how it's configured. The Apache
MPM worker is strongly encouraged. We recommend very few servers and a fair number of
threads within each (maybe 3-5 servers and 75-100 threads).
3.2.2 JVM Tuning
Proper tuning of the JVM is the single most important factor in IdP performance (assuming you
don't choke connections with unreasonably restrictive Apache configurations).
Assuming a Sun JVM, the following tasks should be carried out to complete configuration:
Use the server VM instead of the client by using the -server flag.
Increase the amount of heap initially allocated using -Xms###M (where ### is the
amount of memory to allocate, probably something around 256-512).
Increase the maximum amount of memory that can be used using -Xmx###M (where
### is the amount of memory to allocate, probably something around 1024-1536; don't
go above 1800, as in most boxes this is the upper limit of JVM size; solaris and 64bit
OSs may be able to go higher)
If your hardware does have multiple processor cores, turn on the throughput garbage
collector using the -XX:+UseParallelGC flag.
CRASH IdP Hardware/Software Recommendation
7
Section 4
TxDOT IdP Platform Configuration
Introduction
NOTE: the following information is intended to provide a real world example:
The current CRIS IdP installation at TxDOT utilizes VMWare ESX 3.5 Enterprise Edition for
virtualization and Windows 2003 R2 Standard Edition as the guest OS for the Virtual Machines.
Tomcat 6.0 clustering is used to host an identically configured pair of IdP’s using Active/Passive
fail-over. The Virtual Machines used to run the pair of IdP’s are located on separate ESX hosts to
provide hardware level redundancy. A two tier load balancing approach was used for distributing
requests to the IdP’s. The first tier is a pair of Cisco Application Control Engines (“ACE”)
configured for Active/Passive fail-over; their primary purpose is to provide SSL Offloading, Web
Tier Active/Active clustering, and Layer 7 filtering. The second tier consists of a pair of Apache
2.2.x Web Servers configured as Reverse Proxies for an extra layer of security in an
Active/Active load balanced configuration with sticky sessions. In addition, Apache is also used
to provide the following services:
Tomcat application load balancing using mod_jk.
Detailed Access/Error handling, logging, and debugging of all client-to-application
communications.
Acts as third layer of redundancy in case there is a catastrophic failure with the Cisco ACE
hardware.
Hardware
Cisco Application Control Engine
SSL Offloading, Web Tier Load Balancing, Layer 7 Filtering.
VMWare ESX 3.5 Cluster Host #1
Hosts Virtual Machine for Active IdP.
IBM System x3950
4 x Dual Core Intel Xeon 3.3 Ghz
32GB RAM
SAN Storage
2 x Quad Port 1GbE
2 x Dual Port 4GB HBA
CRASH IdP Hardware/Software Recommendation
8
VMWare ESX 3.5 Cluster Host #2
Hosts Virtual Machine for Passive IdP.
IBM System x3950
4 x Dual Core Intel Xeon 3.3 Ghz
32GB RAM
SAN Storage
2 x Quad Port 1GbE
2 x Dual Port 4GB HBA
Software
Operating Systems
Production & UAT
Windows 2008 R2 Standard Edition
2 x vCPU
4GB RAM
Development
CentOS 5.x
2 x vCPU
4GB RAM
Web Servers
Apache 2.2.x + Apache Tomcat Connector (mod_jk)
Application Servers
Apache Tomcat 7.x
http://tomcat.apache.org/download-70.cgi
Java Virtual Machine (JVM)
Oracle (Sun) JDK 6.0.x
https://www.oracle.com/technetwork/java/javase/downloads/index.html
Identity Provider
Shibboleth IdP 2.x
https://wiki.shibboleth.net/confluence/display/SHIB2/Home;jsessionid=0372B94F013A2
1BBF71757D1CF6BE0F7
Note: IdP server role is an application server. The types of data stored on the server are IdP
installation and log files.
CRASH IdP Hardware/Software Recommendation
9
CRASH System Requirements
Operating System
Desktop & Laptop
Windows XP/Vista/7 SP3
Software
Adobe Flash player version 10.2 or greater
http://get.adobe.com/flashplayer/
Adobe reader version 9.x or greater
Easy Street Draw (ESD) Version 5.1.2162.
http://www.easystreetdraw.com/downloads/activex/TxDot/ESDX_5_1_2162.msi
*(1 time download usually requires administrative rights)
Internet Explorer 7 or greater is supported
Preferred screen resolution 1024 x 768
CRASH IdP Hardware/Software Recommendation
10
Section 5
User Management Infrastructure
Introduction The CRASH application is protected by Shibboleth, an open-source initiative by the Internet2
consortium, is a web-based Single Sign-On (SSO) infrastructure. It is based on SAML, a
standard for the exchange of authentication data. Shibboleth allows users to authenticate using a
local identity/authentication service (Identity Provider, or IdP) to gain access to remote resources
and services (Service Providers, or SPs). Upon the user’s successful authentication by the local
IdP, Shibboleth sends attributes about the user to the remote SPs. The remote SPs can use these
attributes in deciding whether or not to grant access to the user. For more information on
Shibboleth, refer to the Internet2 consortium’s FAQ.
Shibboleth Components A successful deployment of Shibboleth involves three critical software components:
Identity Provider (IdP)
This is the server that handles the authentication of users.
Each agency is responsible to set up its own IdP to authenticate their users. The CRIS
User Management Subsystem does not manage user authentication.
Service Provider (SP)
An IdP is useless without Service Providers. SPs are web applications, resources, or other
services which require authentication. The Shibboleth SP software allows most web
servers (namely Apache and IIS) to integrate with an IdP or a number of IdPs.
A cluster of SPs (for load balancing and failover support) are installed in the CRIS
domain and managed by the CRIS technical team. These CRIS SPs integrate with IdPs
installed in agencies to support secure access to the CRASH application and other CRIS
applications.
Discovery Service (WAYF)
The goal of Discovery Service, or "Where Are You From" (WAYF) service is to guide a
user to his Identity Provider (IdP). It serves as a triage between the CRIS SPs and various
agency’s IdPs.
When CRIS SPs detect that a user is not authenticated, they redirect the user to the CRIS
Discovery Service, which presents a list of IdPs of various agencies registered with
CRIS. The user selects the IdP of his agency from the list, then is redirected to his
agency’s IdP for authentication.
The CRIS Technical team installs and manages the CRIS Discovery Service. Each
agency that wishes to use CRASH or other CRIS applications must provide its IdP
coordinates to the CRIS technical team. The CRIS technical team will add the agency’s
IdP to the list of IdPs maintained in the CRIS Discovery Service.
CRASH IdP Hardware/Software Recommendation
11
In summary, each agency that wishes to use the CRASH application must undertake the following
infrastructure setup to enable Shibboleth:
1. Install and configure Shibboleth Identity Provider (IdP) to work with CRIS Service Providers
(SPs), and
2. Provide the IdP to the CRIS technical team, so its IdP can be added to the CRIS Shibboleth
Discovery Service.
How does Shibboleth work with CRASH? The following diagram illustrates how Shibboleth works with CRIS:
CRASH IdP Hardware/Software Recommendation
12
Step 1 (User ⇔ Browser ⇔ Service Provider):
The user opens a web browser and accesses the CRASH application at https://cris.txdot.gov/Crash.
Because https://cris.txdot.gov/Crash is protected by the CRIS Shibboleth Service Provider, the CRIS
Service Provider intercepts the request and checks if the user already has a Shibboleth session and
therefore was authenticated already. If the user is not authenticated, the web server answers with an HTTP
Redirect to the CRIS Discovery Service located at https://cris.txdot.gov/discovery/WAYF.
Step 2 & 3 (Browser ⇔ Discovery Service):
Consequently, the web browser sends a new request to the CRIS Discovery Service, and the CRIS
Discovery Service answers with the web page that allows the user to select an Identity Provider (IdP).
Agencies that wish to use CRASH or other CRIS applications must communicate with the CRIS technical
team so their agency names can be added to the list of agencies under the CRIS Federation in the above
Discovery Service page.
CRASH IdP Hardware/Software Recommendation
13
Step 4: (User ⇔ Browser ⇔ Discovery Service):
On the CRIS Discovery page, the user selects the CRIS Federation from the drop down box, which brings
up a list of registered agencies. The user selects his/her agency from the drop down box and clicks on the
‘Select’ button to submit his selection to the Discovery Service.
Step 5: (Discovery Service ⇔ Browser ⇔ Service Provider):
The CRIS Discovery Service receives the user’s agency selection, looks up the Identity Provider (IdP) for
the selected agency, then it instructs the browser to send a redirect request to the Service Provider
including the selected agency’s IdP url.
Step 6: (Service Provider ⇔ Browser ⇔ Identity Provider):
The Service Provider sends a redirect to the selected agency’s Identity Provider (IdP) to request
authentication of the user.
Step 7: (Identity Provider ⇔ Browser):
The Identity Provider (IdP) checks the authentication request, and because the user is not yet
authenticated, it sends a redirect to the login handler configured in the IdP. Subsequently the browser
sends a request for the username/password web page of the login page of the agency’s authentication
system.
Step 8: (User ⇔ Browser ⇔ Identity Provider):
The user types his username and password credentials and submits them to the agency’s Identity Provider
IdP).
Step 9: (Identity Provider ⇔ Browser ⇔ Service Provider):
The Identity Provider's (IdP’s) authentication engine verifies the credentials against the underlying user
authentication system such as LDAP or Database. After the user is successfully authenticated, the
attribute authority in the IdP will perform the attribute resolution and filtering. The attribute authority of
the agency IdP must be configured to release a list of user’s attributes expected by the CRIS Service
Provider.
CRASH IdP Hardware/Software Recommendation
14
The following user attributes are required by the CRIS Service Provider so the attribute authority of the
agency IdP must release them:
Agency Id - the id assigned to the Agency by the CRIS User Management Subsystem.
IdP User Id - the id of the current user at the Identity Provider, e.g., user’s login id.
First Name - the current user’s first name.
Last Name - the current user’s last name.
Email Address - the current user’s email address.
The following user attributes are optional and the attribute authority of the agency Identity Provider may
release them if these attributes are available:
Middle Name - the current user’s middle name.
Phone Number - the current user’s phone number.
After the attribute authority in the agency identity provider gathers all the user attributes to be released to
the CRIS Service Provider, an HTML page is generated which includes the SAML assertion. Because this
assertion contains not only an authentication statement but also an attribute statement with the user's
attributes, this way of sending the attributes is called "Attribute Push". The assertion is transmitted using
an auto-submit-post form, and the web browser posts the SAML assertion to the Service Provider
immediately. The Service Provider processes the SAML assertion including the authentication and
attribute statements and sends a redirect to the prior requested resource, with user attributes injected into
the request as request headers. The request is then intercepted by the CRIS authorization framework. If
this user is authorized to access the CRASH application, the CRASH Home page will be rendered and
sent back to the browser as shown on the next page.
CRASH IdP Hardware/Software Recommendation
15
If this user is not authorized to access the CRASH application, the request is forwarded to the CRIS
authorization error page by the CRIS Authorization Framework:
CRASH IdP Hardware/Software Recommendation
16
Section 6
FAQ Q: Does the IdP Server need to reside in our DMZ or can it reside in our internal network?
Will there need to be any URL, DNS or Domain name configurations to support the IdP
installation?
A: The IdP will reside on your internal network. No DNS, URL or domain configuration changes
will be required.
Q: Can the IdP be installed on a workstation?
A: TxDOT does not recommend using a workstation as a server, since there is typically not a good
back up support for a workstation.
Q: Do I have to use Virtual Software to install my agency IdP?
A: TxDOT recommends Virtual Software but is not required.
Q: Does the browser need to be configured to allow cookies?
A: Yes, cookies need to be enabled to allow your Internet browsers to sign in and save your Internet
settings.
Q: Do I need to have administrative rights on my computer?
A: The Technical Contact should have unrestricted access to create, delete, and modify an agency
setting. (Configuration has to be set-up normally by the IT)
Q: Does the CRASH User need administrative rights to install Easy Street Draw to their own
machine?
A: Yes, unless the agency has delegated these rights to certain few. There is a 1 time Active X
download that will need to happen to install ESD. Now a work around would be two options:
Option 1: Group Policy by agency to install ESD MSI (provided by TxDOT) to all
machines
Option 2: Physically touch each machine within your agency and install ESD MSI
CRASH IdP Hardware/Software Recommendation
17
Q: My Easy Street Draw shows and “Evaluation” watermark?
A: When the diagram is showing evaluation all over and when CRASH is asking to: Buy, Activate,
etc…
Select “Activate” and then input:
ESD Genric Activation: 60810454 Password: P54taw
Troubleshooting Trouble Connecting:
Each agency’s IdP resides behind their firewall and if it has stopped or someone inadvertently
stopped the IdP, the user would not have access to CRASH.
Authentication Failed etc…:
Authentication Failed is never a TxDOT issue. It’s always goin to be a bad username/password
or a bug/misconfiguration of the IdP.
The easiest thing for you to do is for every user that’s not working, delete them out of Configure
and ask them to login again and expect to fail. This is the initial step to start seeding the user, and
after 5-10 mins the AAM should open Configure, click User panel and locate the user and assign
to the appropriate group. The system will take care of automatically creating their user the correct
way. This method is called “seeding” a user; if eliminates the need of knowing domain address.
All the required information is populated when the user tries to login. Have user login in a
second time and expect to succeed.
Trouble Logging In:
First, make sure they aren’t using a bad bookmark. Email them the link to
https://crisuat.dot.state.tx.us (Test) / https://cris.txdot.gov/Crash (Production) and have them go to
it directly, no bookmarks.
Also make sure that they are closing the browser if they are trying to test logging in as a different
users. For security reasons, if you log out of CRASH and try to log back in as a different user,
then the IdP is expecting you to re-authenticate as the previous user. You can’t switch users
without closing all browser windows or you will get a profile exception from Shibboleth.
It also possible that the problem is LDAP related and that the users are missing attributes that are
required by CRASH.
Authentication Denied:
If you are getting “Authentication Denied” then it’s always going to be a problem at the remote
agency. Either the user ID is locked out or they are entering the wrong username/password.
CRASH IdP Hardware/Software Recommendation
18
Authorization Denied:
If you are getting “Authorization Denied” then it’s one of two things:
1. They are missing required Roles in Configure. If they have the correct Roles and they’ve
NEVER used CRASH before, then someone probably manually created their user wrong
(usually they forgot to scope the user ID). Just delete the user out of Configure and ask them
to login again; the CRASH system will automatically recreate their user and you should be
abale to grant them the appropriate Roles. If their user isn’t recreated automatically and they
are still getting the “Authorization Denied” then they are most likely missing required
attributes.
2. Their SAML2 token from their Agency is missing attributes that are required by CRASH.
After they get the “Authorization Denied” message have them change the URL in the address
bar to https://crisuat.dot.state.tx.us/Shibboleth.sso/Session
They should get a page that returns similar to the following:
NOTE: All the Attributes, with the exception of shibb_phone_number are required. If they are missing
any then have them go back to the IT department administrator have their user ID fixed in LDAP.
Miscellaneous
Client address: 144.45.7.132
Identity Provider: Https://crisuat.dot.state.tx.us/txdotidp/shibboleth
SSO Protocol: urn:oasis:names:tc:SAML:2.0:protocol
Authentication Time: 2011-06-29T1600:00:24.940Z
Authentication Contex Class:
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
Authentication Context Decl: (none)
Session Expiration (barring inactivity): 408 minute(s)
Attributes
Shibb_agency_id: 1 values(s)
Shibb_email: 1 value(s)
Shibb_first_name: 1 value(s)
Shibb_guid: 1 value(s)
Shibb_idp_user_id: 1 value(s)
Shibb_is_cris_user: 1 value(s)
Shibb_last_name: 1 value(s)
Shibb_phone_number: 1value(s)
If you aren’t getting “Authentication Denied”, your user was auto populated in Configure, and they have
the correct Roles; then it’s possible there is some type of systems issues and you should escalate the issue
to the CRIS Technical Team for investigation.
CRASH IdP Hardware/Software Recommendation
19
Definitions:
ESD “Easy Street Draw” - is designed to meet the specialized drawing requirements of crash
scene diagramming.
IdP - Identity Assertion Provider is an authentication module which verifies a Security token as
an alternative to explicitly authenticating a user within a security realm
VMware - Virtualization Management Software; lets you run multiple virtual machines on a
single physical machine, with each virtual machine sharing the resources of that
one physical computer across multiple environments
Linux OS - an open source operating system, is a freely distributable, cross-platform operating
system based on Unix that can be installed on PCs, laptops, netbooks, mobile and
tablet devices, video game consoles, servers, supercomputers and more.
Metadata - Data about data. Metadata describes how and when and by whom a particular set of
data was collected, and how the data is formatted
DNS “Domain Name System” - is an Internet service that translates domain names into IP
addresses.
Apache Tomcat - an open source web server and servlet container developed by the Apache
Software Foundation (ASF). Tomcat implements the Java Servlet and the
JavaServer Pages (JSP) specifications from Oracle Corporation, and provides a
"pure Java" HTTP web server environment for Java code to run. Includes tools
for configuration and management, but can also be configured by editing XML
configuration files.
Shibboleth - allows users to securely send trusted information about themselves to remote
resources. It is a federated system, supporting secure access to resources across
security domains. Information about a user is sent from a home identity provider
(IdP) to a service provider (SP) which prepares the information for protection of
sensitive content and use by applications
NTP “Network Time Protocol” - an Internet standard protocol (built on top of TCP/IP) that
assures accurate synchronization to the millisecond of computer clock times in a
network of computers
DHCP “Dynamic Host Configuration Protocol” - is a protocol for assigning dynamic IP
addresses to devices on a network.
LDAP “Light Weight Access Directory” - is an application protocol for accessing and
maintaining distributed directory information services over an Internet Protocol
(IP) network
Proxy Configuration - acts as a security barrier, it ensures that the proxy server monitors all
traffic between the Internet and Intranet. This is normally part of security enforcement in
corporate firewalls within intranets.
CRASH IdP Hardware/Software Recommendation
20
Links
Shibboleth - https://spaces.internet2.edu/display/SHIB/IdPPlatform
Identity Provider (IdP)
Service Provider (SP)
Discovery Service (WAYF)
https://wiki.shibboleth.net/confluence/display/SHIB2/Home;jsessionid=0372B94F013A21BBF71757
D1CF6BE0F7
Apache Tomcat 7.x
http://tomcat.apache.org/download-70.cgi
Oracle (Sun) JDK 6.0.x (Java Development Kit)
https://www.oracle.com/technetwork/java/javase/downloads/index.html
Easy Street Draw 5.1.2162
http://www.easystreetdraw.com/downloads/activex/TxDot/ESDX_5_1_2162.msi
Adobe Flash player version 10.2 or greater
http://get.adobe.com/flashplayer/
top related