CRASH IDP Hardware/Software Recommendation

Transcription

1 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

2 Table of Contents Section Document Information Contributors Version Control... 3 Section Overview... 4 Purpose Scope... 4 Document Conventions... 4 Section Identity Provider Configuration... 5 What is an Identity Provider (IdP)? Hardware Single vs. Multiple (Core) Processors Software Apache Tuning JVM Tuning... 6 Section TxDOT IdP Platform Configuration... 7 Introduction... 7 Hardware... 7 Software... 8 Section User Management Infrastructure Introduction Shibboleth Components How does Shibboleth work with CRASH? Step 1 (User Browser Service Provider): Step 2 & 3 (Browser Discovery Service): Step 5: (Discovery Service Browser Service Provider): Step 6: (Service Provider Browser Identity Provider): Step 7: (Identity Provider Browser):

3 Step 8: (User Browser Identity Provider): Step 9: (Identity Provider Browser Service Provider): Section FAQ Troubleshooting Definitions: Links

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/ TxDOT All Final Review 2/1/ TxDOT All Final Review 2/16/ TxDOT All Final Review 6/14/ TxDOT 5 Remove www. From url address, Update Landing Page Picture 10/19/ TxDOT 4 Update Apache Tomcat 11/20/ TxDOT All Final Review 1/7/ TxDOT All Final Review 3

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

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 Hardware The following hardware is sufficient for deploying an IdP that provides a basic example of how Shibboleth is used (on the order of 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 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. 5

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 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 threads) 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 ). Increase the maximum amount of memory that can be used using -Xmx###M (where ### is the amount of memory to allocate, probably something around ; 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. 6

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 x x Dual Core Intel Xeon 3.3 Ghz 32GB RAM SAN Storage 2 x Quad Port 1GbE 2 x Dual Port 4GB HBA 7

9 VMWare ESX 3.5 Cluster Host #2 Hosts Virtual Machine for Passive IdP. IBM System x 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 Java Virtual Machine (JVM) Oracle (Sun) JDK 6.0.x Identity Provider Shibboleth IdP 2.x 1BBF71757D1CF6BE0F7 Note: IdP server role is an application server. The types of data stored on the server are IdP installation and log files. 8

10 CRASH System Requirements Operating System Desktop & Laptop Windows XP/Vista/7 SP3 Software Adobe Flash player version 10.2 or greater Adobe reader version 9.x or greater Easy Street Draw (ESD) Version *(1 time download usually requires administrative rights) Internet Explorer 7 or greater is supported Preferred screen resolution 1024 x 768 9

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

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: 11

13 Step 1 (User Browser Service Provider): The user opens a web browser and accesses the CRASH application at Because 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 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. 12

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

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. Address - the current user s 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. 14

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: 15

17 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 16

18 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: 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. them the link to (Test) / (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. 17

19 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 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: Identity Provider: SSO Protocol: urn:oasis:names:tc:saml:2.0:protocol Authentication Time: T1600: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_ 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. 18

20 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. 19

21 Links Shibboleth - Identity Provider (IdP) Service Provider (SP) Discovery Service (WAYF) D1CF6BE0F7 Apache Tomcat 7.x Oracle (Sun) JDK 6.0.x (Java Development Kit) Easy Street Draw Adobe Flash player version 10.2 or greater 20