crash idp hardware/software recommendation

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


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



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



http://www./


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.


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.

https://spaces.internet2.edu/display/SHIB/IdPPlatform


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.


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


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.



https://wiki.shibboleth.net/confluence/display/SHIB2/Home;jsessionid=0372B94F013A21BBF71757D1CF6BE0F7

https://wiki.shibboleth.net/confluence/display/SHIB2/Home;jsessionid=0372B94F013A21BBF71757D1CF6BE0F7


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




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.


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:


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.

https://cris.txdot.gov/Crash


https://cris.txdot.gov/discovery/WAYF


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.


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.


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:


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


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.

https://crisuat.dot.state.tx.us/



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.

https://crisuat.dot.state.tx.us/Shibboleth.sso/Session

https://crisuat.dot.state.tx.us/txdotidp/shibboleth


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.


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


Oracle (Sun) JDK 6.0.x (Java Development Kit)


Easy Street Draw 5.1.2162


Adobe Flash player version 10.2 or greater


https://spaces.internet2.edu/display/SHIB/IdPPlatform


crash idp hardware/software recommendation

Documents