Page edited by Dave Smith
This page is a draft. Final decisions on information on this page have not been completed. Please comment if you have suggestions or concerns.
- Impact by Product
- Planning by Project
- Impact by ITC
For a number of years, the SSDT and D3A2 project have shared licensing, support, maintenance and infrastructure costs for several Oracle software installations. In particular:
- State-wide IdM (server and per-user licenses)
- Related Oracle Databases and management tools
With the scheduled shutdown of the D3A2 project on June 30, 2013 much of the funding for this infrastructure will not exist.
This document will discuss the impact of shutting down this infrastructure and the SSDT's plans to replace functionality where needed. The document is open to public comment.Impact by ProductOBIEE Shutdown
D3A2 was the only remaining project using OBIEE in any significant manner.
SSDT attempts to use OBIEE for USAS/USPS state software legacy data sources did not go past "Prototype" stages. The prototypes depended on having an SQL database (e.g. USASDW) which does not exist for USPS. Building and maintaining the necessary meta data and connections to ITC database was costly and time consuming. Further, the OBIEE did not fit well into the SSDT's Redesign plans and could create another barrier to the Redesign completion and implementation.
Therefore, the lost of OBIEE is not expected to have any impact and saves approximately $150K in annual software maintenance costs.State-wide IdM
IdM is currently used as the authentication and authorization source for the following projects:
- D3A2 (approximately 22,000 users)
- EMIS-R VRF - Data Collector (approximately 1,400 users)
- EMISFFE (approximately 1,800 users)
With D3A2 shutting down, the most significant motivation for maintaining IdM will not exist.
EMIS-R VRF already supports ITC ADS (MicroSoft Active Directory Services) integration which is used by the majority of ITC's. Any ITC's using IdM would be required to migrate to an ITC managed ADS directory. The SSDT currently believes less than 10 ITC's are using IdM for Data Collector authentication.
EMISFFE depends on IdM exclusively and will have the largest impact. However, the SSDT believes that EMISFFE can be migrated to a OpenID and/or local profile security with limited impact on users and ITCs.
Further, the IdM product is expensive (in staff and consulting) to maintain and requires special skills for provisioning new application. We have never been able to successfully integrate ADS, for example. The SSDT has had more success with it's internal applications (Wiki, JIRA, etc), which allow external user authentication, using tools such as Atlassian's Crowd, and OpenID. Therefore, the SSDT does not see value in adding additional application to IdM in the future, given the more cost-effective alternativies.
Therefore, the SSDT intends to phase out the use of State-wide IdM and migrate to alternatives (see below). This saves approximately $140K in annual software maintenance costs.Other Oracle Hosting
The SSDT has been providing (no-cost) hosting of Oracle APEX applications. With the exception of the "Subsidies" system hosted on the behalf of the MCOECN, the APEX hosting is used lightly. The SSDT would continue to maintain at least one Oracle database server with APEX until remaining applications are migrated. However, the Oracle maintenance will not be continued, so the APEX servers would not be upgraded and applcations running on them would be unsupported.Planning by Project
The NBEC (on behalf of the SSDT) holds the perpetual licenses for the above mentioned Oracle products. The SSDT will cease paying support and maintenance (which expire on June 30, 2013) on the products and phase out use as quickly as possible. During the wind down period, the products will not be upgraded and run without support.EMIS-R Data Collector
The SSDT believes the majority of ITC's are already using a local Microsoft (or other LDAP implementation) for managing Data Collector logins. The remaining ITC's will be encouraged to convert from IdM authentication as soon as practical. The SSDT will assist ITC's where possible by providing extracts of existing users. (Note, passwords are encoded and cannot be retrieved from IdM). A final shutdown date will be selected based on feedback from ITC, but expected to be no later than December 2013.EMISFFE - Flat File Editor
Currently, EMISFFE is entirely dependent on IdM for both authentication and authorization. Currently, ITC's are required to use IdM to manage both user accounts (auth-n) and the IRN(s) to which the user has access (auth-z). To remove this dependency, the SSDT intends separate the authentication from authorization using a combination of local profiles and OpenID credentials.For Authentication:
- Create a local profile in EMIS FFE for each user
- Allow user to login with a local EMISFFE password
- Allow user's to self-register with OpenID credentials
- Allow users to associate one or more OpenID's with the local profile
- During the transition from IdM to local profiles:
- users who successfully authenticate with IdM will automatically have a local FFE profile created which mirrors their IdM profile
- After the first login, users will be able to login using the local profile
- ITC users will be granted a role which allows them to grant or revoke access a user's access to an IRN
- ITC user will be granted (limited) access to manage user profiles. e.g. Changing email, deactivating accounts, forcing a password reset, etc.
- EMISFFE will maintain a relationship between Districts and ITCs based on data from ODE
OpenID is an internet standard which allows a web site (such as EMISFFE) to use external sources (OpenID provider) for authentication without requiring the user to share their password. There are many OpenID providers, such as Google, Yahoo and even the SSDT. The advantage for the user is they get a SSO (Single Sign On) experience, with fewer passwords to remember. Password expiration and recovery is delegated to the OpenID provider.
The advantage for EMISFFE is it would not be required to store a local password (in the long run) once the user has established an OpenID relationship. This results in a more secure application with less software for password management and recovery. The SSDT and ODE (with feedback from ITC's) may need to establish a list of "trusted" OpenID providers, or decide to allow any OpenID provider.
The SSDT already operates a OpenID provider for it's internal applications. If you have signed up for an account on this Wiki or SSDT JIRA then you already have an OpenID from the SSDT (but we haven't widely advertised it). The SSDT's provider could be leveraged to provide authentication. OpenID provides considerably more future flexibility than the current IdM. It's possible that ODE could implement an OpenID provider using the SAFE accounts. Or ITC's could implement an OpenID provider using their local ADS directories (the SSDT/NWOCA uses Atlassian's Crowd for ADS aggregation, and there are other alternatives).
Impact by ITC
ITCIdM in VRFLGCATRECALACAHCCASWOCANWOCANOECANCCWOCOMECOMERESASCOCASEOVECMDECANOACSCMVECAACCESSNCOCCNEOMINNEONETSPARCCTCCSA
Key: = Currently using IdM. = Does not use IdM = No responseFAQWhat is the impact on the MCOECN Kiosk?
None. The MCOECN Kiosk is no longer hosted on SSDT servers or licences.
View Online · View Changes Online Dave Smith 2013-05-23T20:04:31Z
Page edited by Melissa Diemer/**/
- 1 Introduction
- 1.1 Architecture
- 2 Configuration Setup for USASDW Web
- 3 Verifying Installation of the USASDW Web Application.
- 4 USASDW Application Logs
- 5 USASDW Web Logs
This document contains supplementary documentation for installing and configuring the USASDW Web Application.
Please see either the SSDT Web Application Install Guide (Tomcat) or SSDT Web Application Install Guide (Glassfish) for general information about installing a web application (WAR file). This supplement assumes you have reviewed the general guide prior to installing an application.Architecture
The USASDW Web application consists of a Web User Interface and a MS SQL Server database for the back end. Additionally, the USASDW application makes use of LDAP to perform user authentication against your Active Directory domain controller.
Note: The database used with USASDW is the same database used with the SSWAT User Interface. The USASDW installation replaces the SSWAT User Interface, but does not affect the database. Details about your SSWAT database installation can be found by accessing the SSWAT Configuration program. See the SSWAT Installation and Setup guide for details on installing the SSWAT database.Configuration Setup for USASDW Web
There are a number of initial setup steps that must be completed prior to deploying the USASDW web application the first time. The following instructions will help you with completing these steps that are necessary for the USASDW web application to function properly. These setup instructions are for the initial setup of USASDW, subsequent releases will be accompanied with instructions for upgrading your installation.Custom Configuration Setup
The USASDW makes use of the same custom configuration setup that USASWeb uses. For USASDW it is necessary to setup the custom configuration directory in order to configure the web application for access.
To setup the custom configuration directory, do the following: (Note: If you have already setup custom configuration for USASWeb steps 1 - xxx have already been completed)
- Create a directory on local file system where your web container instance is running to contain the custom configuration files for your installation. Example: C:/SSDT.custom or /var/ssdt-custom. This directory must be readable by the username which your web container is executing under.
- Add startup option to the Java command that starts the web container process setting a Java system property “custom.config.dir” to the local directory that was set up in step 1.
- For Tomcat
Example:[Tomcat startup command] -Dcustom.config.dir=C:/custom.config/
- On Windows, system properties can be set in the Tomcat Configuration Manager. On Linux, they can be added by modifying catalina.sh.
- For Glassfish, jvm startup options can be set in the Administration Console by selecting Application Server from the menu and selecting the JVM Settings tab, followed by the JVM Options sub-tab.
- For Tomcat
- Within the custom configuration directory, create a folder for the web application:
- For USASDW the application folder must be named: usasdwweb
- Under the web application directory, place the properties files that will contain the custom properties, in this case: LocalResources.properties and ldap.properties
In order to connect to the database server, it is necessary to configure a JDBC Data Source for the web application prior to its use.Copy jdbc provider .jar file
Step 1 requires copying the .jar file for the datasource provider to the appropriate lib folder for the web container you are using. The file you will need to copy is located in the web application folder under the WEB-INF/lib directory and will be named: jtds-x.x.x.jar where the x's represent a particular version number.
Copy this .jar file to the following location:
- For glassfish, copy to the <GLASSFISH_HOME>/lib folder
- For Tomcat 5.5 copy to the <TOMCAT_HOME>/common/lib folder
- For Tomcat 6.0 copy to the <TOMCAT_HOME>/lib folder
Glassfish provides a way to setup a JNDI data source through their administration console. Follow the steps below to create that data source. This is a one-time setup and will not need to be repeated for subsequent upgrades.
1. Under the Resources menu item, it is necessary to setup a JDBC Resource and Connection Pool, The Connection Pool must be setup first.
2. After selecting the Connection Pool menu item, click "New" to add a new Connection Pool.
3. Enter the pool name and resource type and click "Next"
4. Under the General Settings section, enter the DataSource Classname and a Description for the connection pool. Please note, for the DataSouce Classname, "JtdsDataSource" must have an uppercase "J", while the j's in "jtds.jdbcx" must be lowercase. If you prefer to copy and paste the classname, the correct classname is: net.sourceforge.jtds.jdbcx.JtdsDataSource
5. Under the Connection Validation Section, check the Required checkbox, change the validation method to “table” and under Table Name enter the name of a small table in your database for the validation to issue a select against for validation purposes.
6. Under the Additional Properties section, enter the 7 attributes shown below with values appropriate for your installation.
7. Click "Finish", this completes the setup of the Connection Pool.
8. Click the JDBC Resources menu item and "click "New" to add a new JDBC Resource.
9. Enter the JNDI name for the Resource, select the Connection Pool created in the previous steps, and enter a description for the resource. Click "OK"
This completes the setup of the JDBC Resource in Glassfish.Tomcat
Modify the context.xml document to point to your database installation. Note, when upgrading, it will be necessary to update the context.xml file with your database information each time.
The file to be modified will be under the /conf/Catalina/localhost directory and will have the name usasdw.xml. You will need to change the following to the appropriate values for your installation:
When dealing with non-standard ports and/or named instances , the connection string will need to be altered to include this information. In this situation, the following notation should be used:
If the standard port is used, the port can be excluded, but otherwise must be specified in the url. Additionally, if using a named instance, it is necessary to specify the instance name using the notation shown above. Additional information regarding the jTDS driver can be found at their FAQSetting maximum number of database connections
There is also a maxActive parameter in the usasdw.xml file which is initially defaulted to 10. This setting is the maximum number of active connections that can be allocated from the database connection pool at the same time. If you have a lot of users on simultaneously, you may need to increase this number. In particular, if users receive errors when trying to query which indicate "Timeout waiting for idle object", this parameter should be increased and Tomcat restarted.LDAP Setup
As previously mentioned, USASDW makes use of LDAP to authenticate against Active Directory. Consequently it is necessary to specify some settings to define the domains that USASDW will authenticate against, as well as specify the manner in which they will communicate with the domain controller.Properties Files
In the custom configuration directory for USASDW, it is necessary to place settings in two files.
The first file, LocalResources.properties must contain a comma delimited list of the trusted domains. These are the domains that will appear in the dropdown list on the login page. The order should be the order in which you would like the domains to appear in the list.
The second file is the ldap.properties file. This file contains all of the connection information for the application to be able to authenticate to the Active Directory domain. Each section defines one individual domain.
Example:# Information used to query LDAP for login, list all domains to be used for authentication. # Note: special characters must be escaped in the settings. The following notation can be # used to escape special characters: # # Character Replace with # ------------------ -------------- # (newline) \n # (tab) \t # (comma) \, # (backslash) \\ # (any unicode char) \u0020 org.nwoca.ssdt.usasdw.ldap.domain=domain1 org.nwoca.ssdt.usasdw.ldap.server=dc1.domain1.someplace.org org.nwoca.ssdt.usasdw.ldap.baseDN=DC=domain1\,DC=someplace\,DC=org org.nwoca.ssdt.usasdw.ldap.port=636 org.nwoca.ssdt.usasdw.ldap.useSSL=Y org.nwoca.ssdt.usasdw.ldap.domain=domain2 org.nwoca.ssdt.usasdw.ldap.server=dc1.domain2.someplace.org org.nwoca.ssdt.usasdw.ldap.baseDN=DC=domain2\,DC=someplace\,DC=org org.nwoca.ssdt.usasdw.ldap.port=389 org.nwoca.ssdt.usasdw.ldap.useSSL=N org.nwoca.ssdt.usasdw.ldap.domain=domain3 org.nwoca.ssdt.usasdw.ldap.server=dc1.domain3.someplace.org org.nwoca.ssdt.usasdw.ldap.baseDN=DC=domain3\,DC=someplace\,DC=org org.nwoca.ssdt.usasdw.ldap.port=636 org.nwoca.ssdt.usasdw.ldap.useSSL=Y SSL Communication
While not a requirement, many will want to enable SSL communication between the USASDW application and the domain controller(s) that the application is using to authenticate to. SSL Communication can be enabled by following these steps:
- Create a certificate request for server authentication on the Domain Controller that will be used for authentication.
- Copy the certreq utility from the Enterprise Certificate Authority and related files.
Use a .inf file for the request – example below:[Version] Signature= "$Windows NT$" [NewRequest] Subject = "CN=domaincontroller.mydomain.org" KeySpec = 1 KeyLength = 1024 Exportable = TRUE MachineKeySet = TRUE SMIME = FALSE PrivateKeyArchive = FALSE UserProtected = FALSE UseExistingKeySet = FALSE ProviderName = "Microsoft RSA SChannel Cryptographic Provider" ProviderType = 12 RequestType = PKCS10 KeyUsage = 0xa0 [EnhancedKeyUsageExtension] OID=184.108.40.206.220.127.116.11.1
Use certreq to create the certificate request:certreq –new request.inf request.req
- Create the certificate from the Enterprise CA
- Copy the request created above to the Enterprise CA
- Submit new request to CA
- Issue Certificate and export certificate (example file name: certnew.cer)
- Accept the certificate on the Domain Controller being used for authentication.
- Copy the exported certificate to the Domain Controller
Use the certreq utility to accept the certificate:certreq –accept certnew.cer
- Reboot the Domain Controller. This completes the setup from the standpoint of enabling LDAP over SSL for the Domain Controller.
- On the server that will be hosting the java application, it is necessary to import the certificate being used by the Domain Controller into a java keystore.
- Copy the certificate (certnew.cer from above) to the machine hosting the java application.
Use the keytool utility to import the certificate into a keystoreKeytool –import –alias uniqueAliasName –file certnew.cer –keystore keyStoreFileName
Alter the java startup command to include the path to the keystore created in step 5b.-Djavax.net.ssl.trustStore=C:\mypath\keystoreFileName
- Restart the java application/container
This completes the necessary steps to enable LDAP over SSL communication.Verifying Installation of the USASDW Web Application.
After completing the installation and configuration, you can access the user interface application at the Container URL: http://yourhost:8080/usasdw/
You will need a valid SSWAT account in order to log in. This may be the default administrative account created when the SSWAT database was installed (this will be the Windows username and domain that was used to run the original SSWAT database installation), or any other valid SSWAT username and password.
If you receive errors, contact the SSDT for troubleshooting assistance.USASDW Application Logs
The USASDW Web application creates a log file named “usasdw_webapp.log” for application specific log messages. The location of this log will vary depending on the platform. It will be in the default directory of the user running the web container. On Windows 2003, it will be inthe %SystemRoot%\System32 .
You may modify the log4j.properties file if you wish to specify a more sensible location for this log files.View Online · View Changes Online Melissa Diemer 2013-05-13T15:23:42Z
Page edited by Dave SmithIntroduction
Version 8.5 has been released by ASG and the SSDT has prepared (beginning with the December 2012 release) the ability to support version 8.5.
Support for UDMS Version 8.5 is primarily for ITC's with Itanium servers. If your site is using Alpha servers for UDMS, you are not required to upgrade. The SSDT intends to support dictionaries for both 7.x and 8.x for the foreseeable future. The SSDT recommend that you do not upgrade unless you have specific need for version 8.5.Background
Between version 7.x and 8.5, ASG implemented significant structural changes to the UDMS dictionary structure. In previous versions, an UDMS dictionary consisted of a single file (e.g. UDMSDCT.DAT). In 8.5, a single dictionary is stored in multiple files (e.g. UDMSDCTA.DAT, UDMSDCTX.DAT, etc). The change in dictionary structure had a major impact on the SSDT's UDMS support procedures: UDMS_SEL, UDMS_SECURE, etc. These procedures required significant revision to support the new UDMS structure.Warnings
- Upgrading to UDMS InfoServer 8.5 will require new ODBC Drivers to be installed on on client machines. If you upgrade to 8.5, all Windows clients must also be upgraded. Any stored ODBC queries will either need to be re-written or manually upgraded to use the new driver.
- The dictionary conversion process (described below) must be executed on all UDMS Dictionaries. During the conversion, some locally created views or report definitions may not convert correct and will need to be repaired or rewritten after the conversion.
- Download INSTALL.BCK file from OECN_DOWNLOAD
- Install UDMS InfoServer:
- Identify location of install file
- Execute command replacing <location> with actual location of file: assign <location> media:
- Execute command to invoke backup: backup/log/new_version media:install.bck/save /select=install.udms *.*
- Start installation: @INSTALL_UDMS
- Answer the prompts according to your particular setup
- Set logical UDMS_EXE to directory UDMS was installed in
- Rename the dictionary you wish to convert: for example, rename USPSDCT.DAT USPSDCTX.DAT
- Set logical to point to the dictionary you would like to rebuild: DEFINE UDMS_DCT <DEVICE>:<DIRECTORY>USPSDCTX.DAT
- Execute command: DMSUTL REBLD -Kv (The K and v flags are optional, however these allow for more detail should an error occur)
- Check the log file for any issues/errors. This will be located in the UDMS_EXE directory.
- If no errors occurred you can repeat the steps for the other dictionaries that need to be converted.
- If errors occurred review them and try to either correct it from the resulting dictionary or correct in the original dictionary and do another rebuild.
Note: There will always be a backup of your old dictionary created by the rebuild process. This will be located in the same directory of your original dictionary. It will be renamed to <dictionary name>_<version #>.DAT.After dictionaries have been rebuilt
- Set UDMS_EXE as a system logical pointing to the new UDMS installation
- The following were updated on the December, 2012 release to support both UDMS 7 and 8.5. Older release will not function with 8.5.
- Login as UDMSMGR (UDMSMGR user requires CMKRNL as a default priv to run service)
- Execute command: @UDMS_EXE:UDMSDINI
- Answer the prompts according to your particular setup
- Batch queue for Safari service and InfoServer usually are the same, UDMSD and UDMS$SRV, respectively
- Port number is usually the default as well: 23341
Note: If the batch queue for the Safari service or Safari InfoServer are already created it will stop the current jobs running on the queue and the queue will be re-initialized.
View Online · View Changes Online Dave Smith 2013-04-08T16:09:50Z