Public Wiki

Main Page

SSDT Wiki Updates - Mon, 06/03/2013 - 11:38am

Page edited by Dave Smith

Welcome to the SSDT Public Wiki

This is the SSDT Public Wiki for topics related to software developed by the SSDT on behalf of the Ohio Department of Education. OECN ITC personnel and state software users are welcome to participate in the Wiki.

Please see the "About" page for more information about the purpose of the Wiki and how to participate.

 

RSS Feed Builder

 

Spaces

 

 SSDT Public Wiki      Documentation          CNDC Documentation          EIS Documentation          EMIS Flat File Editor          EMIS V3.0          OECN Documentation          OpenVMS Technical Documentation          USAS Documentation          USAS-R Documentation          USAS Web Documentation          USPS Documentation          USPS Web Documentation      SSDT Developers Wiki          CNDC Project          USAS Team          USPS Team      OECN DNS Services      Ohio SOAP SIF Agents      Software Advisory Committee      State Software Redesign          USAS Redesign          USPS Redesign

Blog Posts

SSDT News

My name is Roy, but I want to be Norm when I grow up. EMIS Aggregations Wake @nwoca End of an(other) Era: EMIS Aggregation Subsystem USPSWeb v1.8-1 Released USPSSOAP v1.8-1 Released

 

  Recently Updated Show More View Online · View Changes Online Dave Smith 2013-06-03T15:38:10Z
Categories: Public Wiki

SSDT Oracle Infrastructure Wind Down

SSDT Wiki Updates - Fri, 05/31/2013 - 1:31pm

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.

 

/**/

Introduction

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:

  • OBIEE
  • 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 six ITC's are using IdM for Data Collector authentication (see table below).

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 support cost, 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 alternatives.

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 applications 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 by December 2013 and no later than June 2014.

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 or associated OpenID
For Authorization:
  • 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
More on OpenID

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 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 VRFLGCA.TRECA,LACA

'

HCCA,SWOCA,NWOCA.NOECA,NCC,WOCO,MEC,OMERESA'SCOCA,SEOVEC'MDECA,NOACSC.MVECA,ACCESS'NCOCC'NEOMIN,NEONET.SPARCC,TCCSA'

 

Key:  = Currently using IdM.  = Does not use IdM  = No response

FAQWhat is the impact on the MCOECN Kiosk?

None.  The MCOECN Kiosk is no longer hosted on SSDT servers or licences. 

If you have a problem while unsupported.  How are you going to support IDM if that occurs?

While there is some risk of a catastrophic failure, it is exceedingly unlikely.  The SSDT has been operating IdM for several years effectively unsupported (without logging a support call or requiring consulting services).  Aside from an occasional reboot and log monitoring, the existing installation requires very little attention.  During the phase out, we will not be provisioning new applications or bulk loading users, which are generally sources of problems for IdM. When D3A2 shuts down, the majority of the load on the servers will evaporate.  The current installation runs on virtual servers, so the there is no significant risk of a hardware failure.  Even in a DR event, IdM would remain a "Tier 1" application and stood up in a DR environment.  In an absolute worse case (unresolvable catastrophic software failure), the SSDT would either put IdM back under maintenance, or could stand up a temporary ADS installation for any remaining ITC's. 

If OpenID is required for EMISFFE login, then we would like more detailed information on how to configure OpenID soon so that EMISFFE authentication is in place prior to December 2013

First, it will not  be required that each ITC implement an OpenID provider.    Once the user has a 'profile' in EMISFFE, they will have an option to associate (one or more)  OpenID's with the profile.  Thereafter, they will be able to login via their OpenID.  It doesn't really matter if their OpenID is provided by Google, Yahoo, the SSDT, an ITC or any other OpenID provider. 

However, if the ITC does become an OpenID provider, it may improve the user's experience by tying the login to their existing ADS account.  This could have benefits for the ITC and users beyond EMISFFE.  

As an example, the SSDT and NWOCA currently use Atlassian Crowd to aggregate eight ADS domains and two local crowd directories (which allow self-registration) to provide SSO for NWOCA and SSDT Wiki's, JIRA, etc.  Crowd also provides and OpenID provider. So any NWOCA or SSDT ADS user plus anyone who as self-registered with our Wiki, already has an SSDT OpenID.  Those user could use their SSDT OpenID to login to EMISFFE (or any other web site that allows OpenID authentication). 

OpenID only provides authentication (who you are) and is not sufficient for authorization (what you can do).  In the case of EMISFFE, it would use the OpenID to relate the user to an EMISFFE profile. But only EMISFFE would control what that profile could do (e.g. which IRN's it could access).

The SSDT is not necessarily recommending Atlassian Crowd. If you are considering an ADS/LDAP aggregation solution for SSO, Crowd should be on your list to evaluate. However, there are a number of commercial and OSS OpenID providers for ADS and LDAP. Crowd works very well for the SSDT's application and user directory mix, but may not be suitable for your situation. In particular, Crowd's main deficiency is that it does not support SAML, which is similar to OpenID, but provides authoritative trust relationships between applications and directories.

 

 

 

 

View Online · View Changes Online Dave Smith 2013-05-31T17:31:53Z
Categories: Public Wiki

May 2013 Release

SSDT Wiki Updates - Wed, 05/29/2013 - 12:20pm

Page edited by Catherine Aldrich

/**/ Introduction

This page contains information regarding the May 2013 release of State Software.  

Please see Acquiring the Release for information on downloading the release.

OECN Package Release

OECN Package Release Notes

USPS Release

USPS Release Notes

USAS/SAAS Release View Online · View Changes Online Catherine Aldrich 2013-05-29T16:20:20Z
Categories: Public Wiki

USASDW Web Install Guide

SSDT Wiki Updates - Mon, 05/13/2013 - 11:23am

Page edited by Melissa Diemer

/**/ Introduction

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)

  1. 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.
  2. 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.
  3. Within the custom configuration directory, create a folder for the web application:
  4. For USASDW the application folder must be named: usasdwweb
  5. Under the web application directory, place the properties files that will contain the custom properties, in this case: LocalResources.properties and ldap.properties
JDBC Resource Setup

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
Setup the datasourceGlassfish

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:

  • dbpassword
  • myserver.domain.com/DATABASE_NAME
  • dbusername

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

url="jdbc:jtds:sqlserver://myserver.domain.com[:<PORT>]/<DATABASE_NAME>;instance=<INSTANCE_NAME>"

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 FAQ

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

Example:

org.nwoca.ssdt.usasdw.trusteddomains=domain1,domain2,domain3

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:

  1. Create a certificate request for server authentication on the Domain Controller that will be used for authentication.
    1. Copy the certreq utility from the Enterprise Certificate Authority and related files.

    2. 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=1.3.6.1.5.5.7.3.1

    3. Use certreq to create the certificate request:

      certreq –new request.inf request.req
  2. Create the certificate from the Enterprise CA
    1. Copy the request created above to the Enterprise CA
    2. Submit new request to CA
    3. Issue Certificate and export certificate (example file name: certnew.cer)
  3. Accept the certificate on the Domain Controller being used for authentication.
    1. Copy the exported certificate to the Domain Controller

    2. Use the certreq utility to accept the certificate:

      certreq –accept certnew.cer
  4. Reboot the Domain Controller. This completes the setup from the standpoint of enabling LDAP over SSL for the Domain Controller.
  5. 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.
    1. Copy the certificate (certnew.cer from above) to the machine hosting the java application.

    2. Use the keytool utility to import the certificate into a keystore

      Keytool –import –alias uniqueAliasName –file certnew.cer –keystore keyStoreFileName

  6. Alter the java startup command to include the path to the keystore created in step 5b.

    -Djavax.net.ssl.trustStore=C:\mypath\keystoreFileName
  7. 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

In addition to the standard Container logs (see Tomcat Logs or GlassFish Logs, USASDW provides application specific log files described below.

USASDW Web 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
Categories: Public Wiki
Syndicate content