umacgillivray
commented
9 years ago @rmbradley @mhogeweg @zguo
The Geoportal single sign-on documentation you refer to is associated with sso within the Java application server (i.e. multiple web applications deployed within the same Tomcat sharing the authenticated user).
It sounds like you need something broader than that. There is the Windows approach (Integrated Windows Authentication), and non-Windows approaches such as OpenAM, Oracle OAM, etc. We've integrated with some of these sso solutions, they all have their own specifics.
For Integrated Windows Authentication, the person signed into the PC is the person signed into the web app. There's a Tomcat discussion here: https://tomcat.apache.org/tomcat-8.0-doc/windows-auth-howto.html
There are three options listed: built-in, 3rd party web app plugin, reverse proxy. Haven't tried the built-in option. I tried the first suggested 3rd party library - Waffle, and got it to work with a small code tweek (deployed on a Windows machine). Also tried IIS as a reverse proxy, and got it to work with the same tweek (Geoportal is not expecting the domain to be included within the sso username).
If you want, we can work with you to get one of these approaches working on your end.
rmbradley
gcampanile
Purpose: Rapid Eco-regional Assessments (REA) and other Landscape Approach projects are sharing ESRI’s Geoportal web application environment for metadata and document cataloging to enable global search and discovery of specific geospatial data, map products, and supporting documentation. Most of these products will be accessed internally in the near-term with a gradual presentation and consumption by the general public from participating external platforms. Internal access by BLM and other DOI organizations is very important. Therefore, efforts are underway to simplify the Geoportal log-in process using Single Sign-On (SSO) functionality. Objective: To access secured resources (content) and/or functions (publishing/reviewing/administration) in the geoportal using corporate identities with strong 2 factor authentication by means of a government issued PIV card with client certificates and a PIN.
Executing Single-Sign-On capabilities may meet the needs since users login to their workstations with their PIV cards. If the server/application and the client are part of the same domain, the trusted relationship could use single-sign-on to eliminate a login using username/password (which is not 2 factor compliant). The alternative is to establish a login page that supports smart card authentication. Either solution should meet the objective above. Problem: Initial attempts at getting SSO to work have been unfruitful up to this point. DRS and DIRM personnel have been collaborating on configuring specific and related files for the underlying Apache Tomcat server (version 7) and Geoportal web application (version 1.2.5). According to the Geoportal Wiki documentation on ESRI’s GitHub site (https://github.com/Esri/geoportal-server), we are modifying three specific files to enable the SSO functionality. They are as follows: • server.xml (Tomcat) • web.xml (Geoportal) • gpt.xml (Geoportal) Following the Tomcat LDAP and Single Sign-On Configuration Instructions at (https://github.com/Esri/geoportal-server/wiki/Single-Sign-On), we eventually discovered that the configuration is based on Tomcat LDAP. At the BLM we are using Microsoft Active Directory LDAP. Therefore, the configuration elements are not quite the same.
Server.xml: We found that the following elements/parameters may be required for server.xml: <Realm className="org.apache.catalina.realm.JNDIRealm" connectionURL="ldap://domain-controller."agency.dept.net:389" connectionName="username@agency.dept.net" connectionPassword="password" authentication="simple" debug="99" referrals="follow" userBase="ou=ops,dc=agency,dc=department,dc=net" userSearch="(sAMAccountName={0})" userSubtree="true" roleBase="ou=ops,dc=agency,dc=department,dc=net" roleName="cn" roleSubtree="true" roleSearch="(member={0})" />
NOTE: the Realm created above was inserted inside the elements but outside the elements. Other initial conditions: using port 8080 as this a sandbox and we wanted to keep it simple. (Does SSO require SSL? If so, then this is all for naught and I need to do more work).