CRASH IDP

Hardware/Software

Recommendation

Crash Reporting and Analysis for Safer Highways (CRASH)

CRASH Identity Provider Recommendation

VERSION 2.2

Revision Date: June 5, 2014

CRASH IdP Hardware/Software Recommendation

2

Table of Contents Section 1 ................................................................................................................................................................... 4

Document Information ......................................................................................................................................... 4

1.1 Contributors ................................................................................................................................................ 4

1.2 Version Control ........................................................................................................................................... 4

Section 2 ................................................................................................................................................................... 5

Overview ............................................................................................................................................................... 5

Purpose ............................................................................................................................................................. 5

2.1 Scope ........................................................................................................................................................... 5

Document Conventions..................................................................................................................................... 5

Section 3 ................................................................................................................................................................... 6

Identity Provider Configuration............................................................................................................................. 6

What is an Identity Provider (IdP)? .................................................................................................................... 6

3.1 Hardware .................................................................................................................................................... 6

3.1.1 Single vs. Multiple (Core) Processors ........................................................................................................ 6

3.2 Software ...................................................................................................................................................... 7

3.2.1 Apache Tuning .......................................................................................................................................... 7

3.2.2 JVM Tuning ............................................................................................................................................... 7

Section 4 ................................................................................................................................................................... 8

TxDOT IdP Platform Configuration ........................................................................................................................ 8

Introduction ...................................................................................................................................................... 8

Hardware .......................................................................................................................................................... 8

Software ............................................................................................................................................................ 9

CRASH System Requirements ......................................................................................................................... 10

Section 5 ................................................................................................................................................................. 11

User Management Infrastructure ....................................................................................................................... 11

CRASH IdP Hardware/Software Recommendation

3

Introduction .................................................................................................................................................... 11

Shibboleth Components.................................................................................................................................. 11

How does Shibboleth work with CRASH? ........................................................................................................ 12

Section 6 ................................................................................................................................................................. 17

FAQ ..................................................................................................................................................................... 17

Troubleshooting...................................................................................................................................................... 19

Trouble Connecting: ........................................................................................................................................ 19

Authentication Failed etc…: ............................................................................................................................ 19

Trouble Logging In: .......................................................................................................................................... 20

Authentication Denied: ................................................................................................................................... 20

Authorization Denied: ..................................................................................................................................... 20

HTTP 404 Errors .................................................................................................................................................. 21

How to retrieve IdP Logs ..................................................................................................................................... 22

Definitions: .......................................................................................................................................................... 23

Links .................................................................................................................................................................... 24

CRASH IdP Hardware/Software Recommendation

4

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 2/8/2013 1.7 TxDOT All Final Review 3/5/2013 1.8 TxDOT FAQ IdP Server Recommendations 5/3/2013 1.9 TxDOT FAQ How to Adobe Flash Player 9/19/2013 1.10 TxDOT 4 CRASH System Requirements 9/26/2013 1.11 TxDOT

Troubleshooting HTTP 404 Error/IdP Logs

10/30/2013 1.12 TxDOT FAQ Easy Street Draw 1/29/2014 2.0 TxDOT All Updated all URL with “../secure” 2/11/2014 2.1 TxDOT Troubleshooting Opensaml::SecurityPolicyException

6/5/2014 2.2 TXDOT ALL Reviewed against 9.0 Release Notes

CRASH IdP Hardware/Software Recommendation

5

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

6

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

7

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

8

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

9

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

10

CRASH System Requirements Operating System

• Desktop & Laptop • Windows XP/Vista/7 SP3

Software

• Adobe Flash player version 11 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

11

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

12

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

13

Step 1 (User ⇔ Browser ⇔ Service Provider): The user opens a web browser and accesses the CRASH application at https://cris.txdot.gov/secure/Crash. Because https://cris.txdot.gov/secure/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

14

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

15

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

16

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:

17

CRASH IdP Hardware/Software Recommendation

Section 6

FAQ Q: What is the recommend IdP Server Size?

A: 2 CPU (Xeon or Equivalent) 2 GB RAM 15-20 GB Disk Space (primarily for logs and software install)

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: Will your implementation of Shibboleth allow us to use other SAML based IdM providers? We will likely be evaluating ADFS 2 for other applications and would prefer to use that or possibly other commercial products. If not, what level of support can TXDoT provide with Shibboleth?

A: We should be able to integrate with any SAML2 compliant providers and we have done some

proof of concept work with ADFS. The support level is essentially whatever is needed for CRASH at your agency to be successful.

Q: Can we have Shibboleth in the DMZ, or can we publish it through a reverse proxy such as Forefront TMG? If not, can TXDoT provide assistance with configuring an Apache reverse proxy as mentioned in section 4 of the Hardware/Software Recommendation document?

A: Shibboleth normally resides in the back end accessible only to intranet users. We can assist should

you wish to deploy the configuration in the DMZ

Q: Will an SSL cert from a public CA be required or will you be able to trust self-signed or enterprise PKI certs?

A: Self signed certs or enterprise PKI - 2048 or greater are acceptable.

Q: Does Apache Tomcat or other components of the IdP interfere with IIS? A: The IdP will not interfere with IIS in anyway

Q: Our domain and email may be different. Which field (s) does it capture when self registering

the first time?

A: This is very common and is not an issue. But it is generally captured from the “General” tab of Active Directory (any User repository)

18

CRASH IdP Hardware/Software Recommendation

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

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

Q: Easy Street Draw shows it is not installed when I login in to CRASH?

A: Ensure your browser is not in Protected Mode. If so, Easy Street Draw will need to be added to your trusted sites. Please follow the steps to correct the problem:

Go to Internet Explorer –> Tools -> Internet Options -> Security -> Trusted Sites -> Sites -> Add

https://cris.dot.state.tx.us/secure/ to trusted sites.

19

CRASH IdP Hardware/Software Recommendation

Q: When I click “Save and Preview”, my screen will flash and nothing will open?

A: If Adobe is not on your agency’s trusted sites follow these steps to correct the problem: Go to Internet Explorer –> Tools -> Internet Options -> Security -> Trusted Sites -> Sites ->

Add https://cris.dot.state.tx.us/secure/ to Trusted Sites. And then go to Internet Explorer –> Tools -> Internet Options -> Security -> Trusted Sites ->

Custom Level – Downloads – Allow Prompting for file downloads – be sure this is Enabled Q: My Adobe Flash Player is version 10.1.x, how do I update it to version 11.x?

A: To update Adobe Flash Player, please click the following link:

http://get.adobe.com/flashplayer/ Note: Please ensure that you do not have the debugger version of the Adobe Flash Player

installed. If the debugger version of the flash payer is installed please see the following link to uninstall this version ->

http://helpx.adobe.com/flex/kb/uninstalling-flash-player-debugger.html

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

20

CRASH IdP Hardware/Software Recommendation

Trouble Logging In:

First, make sure they aren’t using a bad bookmark. Email them the link to https://crisuat.txdot.gov/secure/Crash (Test) / https://cris.txdot.gov/secure/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.

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

21

CRASH IdP Hardware/Software Recommendation

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.

HTTP 404 Errors

If the IdP can't make a valid connection to LDAP using the service account the IDP will not start thus triggering the 404 anytime users select their agency from the discovery service.

The service account is on the agency side and is part of the agency configuration. Tomcat will start but not the IDP application that is deployed to Tomcat thus showing the HTTP 404 error.

When the agency has the HTTP 404 Error please have them following the following steps:

1. On a windows server the service is normally noted as "Apache Tomcat" or the like and just like any other service and you can see its status in the services console or in Task Manager.

2. For Linux/Unix images the command "ps -ef|grep java" should identify any running java

processes including Tomcat. These services are started by the registration of the application in the inittab.

22

CRASH IdP Hardware/Software Recommendation

Also verify the below steps:

Shibboleth Configuration Files referring to Active Directory

The configuration which points to your active directory is located as noted below. C:\IDP\<ENV>/shibboleth-idp/conf/attribute-resolver.xml C:\IDP\<ENV>/shibboleth-idp/conf/login.config Where <ENV> = TEST or PROD You'll want to update these in the case of any of the following changes to your environment... 1. Changes to the server names of the Active Directory primary and backups. 2. Changes to the service account that is used for LDAP queries.

A. username B. password (change or expiration or intentional reset) C. location of user in Active Directory

3. Changes to the location of Crash Users within the Active Directory? Like moving them to new Organizational Units?

You will need to restart the service in order for new configuration to be loaded.

How to retrieve IdP Logs Every agency has been installed the same. There will be an IDP directory on one of their drives, usually C:\IDP or D:\IDP. If the agency insisted on using the same VM for both Test and Production then the directory structure will be:

%DRIVE%:\IDP\TEST or %DRIVE%:\IDP\PROD

Under the IDP directory you will see three sub-directories:

• Java • Tomcat • Shibboleth-IdP

If you zip up the logs directories under the Tomcat and Shibboleth-IdP sub-directories that should be all that is needed to determine what is going on.

23

CRASH IdP Hardware/Software Recommendation

Definitions:

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.

DHCP “Dynamic Host Configuration Protocol” - is a protocol for assigning dynamic IP

addresses to devices on a network.

DNS “Domain Name System” - is an Internet service that translates domain names into IP addresses.

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

LDAP “Light Weight Access Directory” - is an application protocol for accessing and

maintaining distributed directory information services over an Internet Protocol (IP) network

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

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

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.

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

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

24

CRASH IdP Hardware/Software Recommendation

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 VM Time http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1318 NTP Server http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-ntp.html

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 11.x or greater http://get.adobe.com/flashplayer/