Initial commit

 -- The mercifully short story:

    # An academic by profession, but with lots of consulting experience as a programmer

      ## Full-time faculty member for 30-plus years in DePaul's College of Computing and Digital Media

      ## Long-term experience in programming production planning-scheduling systems (steel industry mostly) and

         product configuration systems (truck manufacturing mostly)

    # Show me the code! It's what really counts in our profession.

    # Feel free to contact me at: kalin@cs.depaul.edu

                                  condor.depaul.edu/mkalin

    Best of luck in your web app programming!

    Marty Kalin

 -- Course overview: lightweight Java web development, deployment, and security

    # Guiding principle: the more working code examples, the better

      ## Code-oriented introduction to web-app programming in Java

    # Requirements: programming familiarity with core Java 5 or greater--the more recent, the better

    # The programming APIs:

      -- HTML5/CSS3: information structure and visual design

      -- Java servlets and JSP (Java Server Pages) pages: the basic APIs

         ## Includes EL (expression language) old and new, and JSTL (Java Standard Template Library)

      -- JSF (Java Server Faces) pages and @ManagedBeans: a higher-level web framework 

      -- JavaScript and the jQuery framework (including some jQueryUI)

    # Supporting tools:

      -- Tomcat: a Java-centric, production-grade web server

      -- PostgreSQL: a free, high-powered RDBMS with some modern 'no-sql' features

         ## JDBC and JPA to communicate with the DB

      -- Utilities such as 'curl' for quick testing, standard browsers--your choice

         ## An Ant script to compile and deploy all of the examples used in the course

      -- Regular expressions for data validation

      -- Wire-level security (HTTPS) and users/roles security (authentication/authorization)

 -- Tomcat security realms

    # In the 'urSecure' web app, we used the default Tomcat security 'realm' and its associated file,

      TOMCAT_HOME/conf/tomcat-users.xml.

    # A 'realm' is a datastore with user identities (e.g., login  names), credentials (e.g., passwords),

      and security roles.

      ## A given realm also includes whatever code infrastructure is required for realm use.

      ## In general, realms are created and configured in the main Tomcat config file, TOMCAT_HOME/conf/server.xml

      ## For convenience, 'auth/auth info' refers to user-authentication/role-authorization information.

    # Background technologies:

      ## JNDI: Java Naming and Directory Interface, an API for:

         ## Associating names with resources within a prescribed syntax (the 'Naming' part).

            -- Sample name from the skiDB.jsp script:

                  url = "jdbc:postgresql://localhost:5432/skistuff"  ## JNDI-compliant name

         ## Associating names with resources and specifying attributes on such 'bindings' (the

            'Directory' part)

         ## Typically described as the Java EE 'naming and directory service'.

            ### JNDI is the 'interface', and a 'provider' furnishes the implementation.

    # The built-in security realms are:

      -- JDBCRealm: auth/auth info is stored in a relational database, and accessed through a JDBC driver.

      -- DataSourceRealm: auth/auth info is stored in a relational database, accessed through a named

         JNDI JDBC 'DataSource'.

      -- JNDIRealm: auth/auth info is stored in an LDAP based directory server, accessed through a JNDI provider.

      -- UserDatabaseRealm: auth/auth info stored in an UserDatabase JNDI resource, which is typically

         persisted as an XML document on the local file system, with TOMCAT_HOME/conf/tomcat-users.xml as

	 the default. This realm is the default, and well suited to development.

         -- UserLockOutRealm: subtype to prevent brute-force attacks that guess passwords ('dictionary attacks')

      -- MemoryRealm: in effect, an earlier version of UserDatabaseRealm 

      -- JAASRealm: auth/auth info access through the JAAS (Java Authentication and Authorization Service) framework,

         with complete flexibility in how the info is persisted.

      ## Users can create and configure additional realms.

         -- Example from TOMCAT_HOME/conf/server.xml:

         <Realm className="org.apache.catalina.realm.LockOutRealm">

           <!-- This Realm uses the UserDatabase configured in the global JNDI

                resources under the key "UserDatabase".  Any edits

                that are performed against this UserDatabase are immediately

                available for use by the Realm.  -->

           <Realm className="org.apache.catalina.realm.UserDatabaseRealm"

                  resourceName="UserDatabase"/>

         </Realm>

  -- Exercise for users/roles security

     # In the 'urSecure' web app, the default Tomcat security realm is in play: the UserDatabaseRealm, with

       auth/auth info persisted in the file TOMCAT_HOME/conf/tomcat-users.xml.

       ## This is ok for development, but not suitable for production.

       ## In general, managing auth/auth information is challenging, and DB tools are a great

          help in addressing this challenge.

     # The exercise is to switch the 'urSecure' app over to a different realm, the JDBC realm by

       default. 

       ## If you've experience in this sort of thing, you might a take a crack at JNDI or even

          JAAS realms.

     # Assuming the JDBC realm, here's an overview of the set-up on both the DB side and

       the Tomcat side.

       -- Create a pair of tables, one to hold usernames and passwords, and another to hold

          the roles for given users. The database schema might look like this, given that we're

          designing with Tomcat's expecatations in mind:

             ### One entry per registered user.

             users(username as varchar, password as varchar)       ## username is primary key

             ### One entry per role for a user

             user_roles(username as varchar, rolename as varchar)  ## username-rolename pair is primary key

         ## Other table designs are possible, of course: Tomcat can handle such designs so long as the

            columns it needs are present.

      # Back up and then edit TOMCAT_HOME/conf/server.xml.

        ## Tomcat must be restarted after any change to this file for the change to take effect.

        ## Here's a sketch of the change to this file:

           <Realm className     = "org.apache.catalina.realm.JDBCRealm"

                  driverName    = "org.postgresqlDriver"

                  connectionURL = "jdbc:postgresql://localhost/:5432/skistuff?user='fred'&password='secret'"

                  userTable     = "users" 

                  userNameCol   = "username" 

                  userCredCol   = "password"

                  userRoleTable = "user_roles" 

                  roleNameCol   = "rolename" />

           ### At most one Realm entry should occur uncommented in TOMCAT_HOME/conf/server.xml. For this

               exercise, the above is a sample of an uncommented Realm entry.

        ## The PostreSQL driver JAR file should be placed in TOMCAT_HOME/lib. Again, Tomcat needs to be

           restarted for it to find this file.