Building Blocks Conference Notes

Blackboard Developers Conference
Georgetown University, 2004

Monday, July 26

09:00–09:45 a.m.
Keynote Session
Matthew Pittinsky

Highlights:

• We are in the midst of a transition from e-learning applications in individual courses to a campus-wide network learning environment involving all members of the institution
• Blackboard is now a public company
• One third of this year's conference attendees attended last year's conference as well
• The Blackboard Developers Network (BbDN) has grown from 115 (2003) to 245 (2004)
• 6141 Building Blocks SDK downloads
• 7276 Building Blocks (B2) downloads
• Of the 104 Building Blocks in the catalogue, 74 are for the Academic Suite, and 50% are free
• .NET SDK released Feb 2004
• Commitment to standards continues (IMS e-Portfolio, SIF integration)

Top 10 Building Blocks:

1. 10. User Performance Module (USF)
2. 9. SCORM 1.2 Compliant Player 1.0
3. 8. Discussion Grader (JJC)
4. 7. Dictionary and Thesaurus
5. 6. User Participation Portal Module (USF)
6. 5. My Journal (Baylor U)
7. 4. Blackboard Link Checker
8. 3. Who's Online Portal Module (Seneca)
9. 2. Bb Content Player (IMS, SCORM, etc.)
10. 1. Advanced Group Management (FSU)

Sneak Peaks:

• Application Pack strategy continues
• App Pack 2 due in about a month
  • Content System SDK
  • built-in SCORM support
  • internationalization
  • ChalkBox
    • "chalktitles" offered by Houghton Mifflin, Pearson Education, Thomson Learning
    • synchronize rosters, SSO, post to gradebook
  • Continued development of Content System
    • v1.2 Q3 2004
    • v2.0 Q4 2004
  • Academic Suite 7.0 due Q1 2005

2003–2004 Priorities:

1. Increase access to BbDN
   • Free accounts to Academic Suite clients (enterprise)
   • "Not quite free" accounts to Commerce Suite clients
2. Comply with evolving standards (SAKAI membership sought)
3. Improve developer support
   • Provide comprehensive test data
   • Provide B2 training courses (such as B2 Essentials)
4. Grow market receptivity (e.g., "Blackboard Enabled" program)
5. Hire Building Blocks Architect/Evangelist

09:45–10:30 a.m.
What is .NET?
Bruce Jackson

Take-Home Lesson:

.NET is a web application framework modeled after J2EE

Important Fact Learned:

CLR runs on Windows only

Important Fact Learned:

Passport is going away!

Notes:

• Common Language Runtime (CLR) manages .NET "managed code"
• Primary advantage of .NET is code agnosticism
• Source code compiles to "intermediate language" (IL)
• CLR manages memory automatically (like Java)
• IL code is portable across architectures (32b, 64b, etc.)
• .NET is not yet UI independent- .NET addresses security issues (big changes coming!)
• Objects passed by value (not reference), which assumes copius bandwidth
• Service Oriented Architecture (SOA) is emphasized
• WS-Security, a form of "federated trust", is supported
• WS-Security and Liberty Alliance may be merging!
• [Even Liberty Alliance and Shibboleth are talking!]
• Kerberos remains a major player

10:45–11:30 a.m.
Data Storage and Migration (Java)
Bob Alcorn

Take-Home Lesson:

Data storage possibilities are somewhat limited

Important Fact Learned:

Can not write into the Blackboard database!

Notes:

• Goals: Portability and structured data
• Types of data:
  1. private data (config data, e.g.)
  2. content data
  3. tool data (discussion tool, e.g.)
  4. extended attributes
• Private data stored in properties files in local directories (see blackboard.platform.plugin.PlugInConfig)
• Extended data provided via "registries" (see blackboard.data.registry)
• Content organized by course
• Use @X@object.attribute@X@ template variables (which have a corresponding API)
• Tool storage:
  • Properties files (the lowest common denominator)
  • XML documents
  • 3rd party storage (e.g., Berkeley DB, Lucene)
• Migration from R5 to R6 is one-time operation
• Course Copy is a handy tool

11:30–12:15 p.m.
My First Building Block (.NET)
Biran Zhang

Take-Home Lesson:

.NET/C# is very similar to J2EE

Important Fact Learned:

Visual Studio is required for .NET development

Notes:

• A Building Block (B2) is a web application
• See package blackboard.security.authorization for access control
• Possible uses of B2:
  • bridge to external system
  • publish a web service
  • content type
  • tools
    • student tool
    • course tool
    • system tool
    • communication tool
  • portal module
• MS .NET framework requires Visual Studio .NET
• File structure is similar to J2EE (/WEB-INF directory, e.g.)
• MS Virtual PC development environment permits standardization

01:30–02:15 p.m.
.NET APIs in Detail
Biran Zhang

Notes:

• Blackboard .NET namespace is very similar to Java API
• See blackboard.data.announcement, e.g.
• Strongly typed enumerations are useful

02:15–03:00 p.m.
Java APIs in Detail
Bob Alcorn

Take-Home Lesson:

A comprehensive Buidling Block will touch numerous APIs

Important Fact Learned:

Use new reflection-based persistence methods instead of standard persisters and loaders

Notes:

• General in-depth introduction to B2 Java APIs
• Base object: blackboard.data.BbObject
• Data objects
  • Content: blackboard.data.content
  • Course: blackboard.data.course
  • Gradebook: blackboard.data.gradebook
• Persistence objects
• Use new reflection-based persistence methods (e.g., persist)
• The persistance manager is proprietary
• Service lookups via BbServiceManager
• Other services:
  • Context: blackboard.platform.context
  • Session: blackboard.platform.session
  • File System: blackboard.platform.filesystem
  • Log: blackboard.platform.log
  • Security: blackboard.platform.security
• Note: Not all clients honor cookies, so sometimes session data is encoded in the URL (URL rewriting)
• Don't use BbList and BbEnum in package blackboard.base (since J2SE 1.5 is coming)
• blackboard.base.FormattedText provides "smart" text handling
• blackboard.base.GenericComparator for sorting
• Portal: blackboard.portal.external
• Tag libraries facilitate UI standardization and integration
• XML manifest file enables deployment

03:30–04:15 p.m.
Blackboard and Content Types
Tracy Engwirda

Notes:

• Updated JSPs can be dropped into place without restarting the server
• Enable the /webapps/manager context in development environment
• Custom style sheets can not be applied (in a standard way) to custom content
• External data is stored in properties files

05:00–08:00 p.m.
International Spy Museum

Appetizers, libations, and a delicious catered dinner were provided at the International Spy Museum in downtown Washington, D.C. After dinner, we toured the museum, which was very entertaining! (The highlight exhibit was a working replica of James Bond's Austin-Martin getaway car.) An hour and a half was barely enough time to scratch the surface.

Tuesday, July 27

09:00–09:45 a.m.
Java Event API
Tracy Engwirda

Take-Home Lesson:

The event API is a real-time alternative to the snapshot mechanism

Important Fact Learned:

Event API data model based on IMS specification

Important Fact Learned:

The "event" API is geared towards data integration, not "events" in the usual sense of the word

Notes:

• In Bb6, the event API is exposed by package blackboard.admin.*
• Read:
  • Advanced Integration and Data Management Manual
  • Administrative API Specifications
• The event API data model mirrors the snapshot mechanism
• The data model is based on the IMS 1.01 Enterprise Specification)
• In terms of data model, the event API is an extension of the B2 API (entities and persisters)
• Classes are stored in cms-admin.jar (add this JAR file to your classpath)
• Using the event APIs:
  • command-line application
    • on Bb app server
    • on other server via snapshot client
  • Building Blocks application (but use care)
  • Web Service
  • RPC wrappers
• Event handlers are constructed with database triggers (outside of the LS)
• Event listener classes will be added in future APIs

09:45–10:30 a.m.
Blackboard 6 Authentication
Tom Scavo

Take-Home Lesson:

A custom authentication module should extend BaseAuthenticationModule

Important Fact Learned:

A lightweight web service can provide validation services to arbitrary web applications

Notes:

• Blackboard 6 Standard Authentication
  • Authentication Types
  • Authentication API (HttpAuthModule)
  • BaseAuthenticationModule
  • Authentication Framework
• Blackboard 6 Custom Authentication
  • LogAuthenticationModule
  • AbstractAuthModule
  • GenericAuthModule
  • Installation
• BGSU Authentication
  • BGAuth and BGAuthValidator
  • BGAuthModule
• Developer's Workshop

10:45–11:30 a.m.
Building Blocks and Web Services (Java)
Bob Alcorn

12:45–01:30 p.m.
Security and Authentication with Building Blocks (Java)
Tom Joyce

Take-Home Lesson:

Blackboard security built on Java security model

Important Fact Learned:

Custom authentication is not possible in .NET because Bb security is built on the Java security model

Notes:

• General security concepts
  • Authentication
  • Authorization
  • Privacy
  • Integrity
• Declaring permissions in the manifest file is often a trial-and-error process
• Blackboard security is based on the Java security model:
  • Java Secure Sockets Extension (JSSE)
  • Java Cryptography Extensions (JCE)
  • Java Generic Security Services (GSS) API
  • CertPath API
  • Java Authentication and Authorization Service (JAAS)
  • Code Security Model
• Authentication services are available to Building Blocks via AccessManagerService
• Authorization services are also available to Building Blocks (see PlugInUtil)
• Two types of roles: system (e.g., admin) and course (e.g., TA)
• Security information available via java.lang.Class

02:00–02:45 p.m.
Building Blocks and Blackboard—A Look Ahead
Bob Alcorn, Dan Cane, David Yaskin

Notes:

• Internal event queues are coming (forced by the introduction of the Content System, which must coordinate with the Learning System)
• e-Portfolios provided by the Content System
• Selective release of content is coming
• Transaction System Account Management
• JJC's Discussion Board Grader would be useful to faculty

Web Security

Basic security principles include:

• Availability
• Integrity
• Authentication
• Confidentiality
• Non-repudiation

Secure Sockets Layer (SSL), a web encryption technology originally developed by Netscape, provides basic web security. All HTTP traffic over SSL (https) is encrypted (in both directions). Beneficial consequences include:

• Confidentiality: The contents of messages are unreadable by 3rd-party observers
• Integrity: The contents of messages can not be altered or tampered with in transit
• Authentication: The sender and receiver are assured of each other's identity

Most browsers ship with SSL certificates installed. On the server, SSL modules (e.g., openSSL) and certificates (from Verisign, e.g.) must be installed. A crypto card can alleviate server bottlenecks.

The SSL network layer lies between IP and HTTP on the protocol stack. Versions include SSL v2.0 and SSL v3.0. Transport Layer Security (TLS) is an extension of SSL proposed by the Internet Engineering Task Force (IETF). TLS v1.0 is roughly equivalent to SSL v3.0. When an SSL connection is established, a client and server negotiate the best combination of cryptographic techniques.

To avoid security issues, the following are recommended:

• Store only hashed passwords in the database
• Submit the login page over SSL, otherwise the password is passed in the clear and may be sniffed
• Make passwords difficult to guess and install intruder alarms that detect random or systematic guessing of passwords
• Avoid sensitive data in URLs (i.e., GET requests) since URLs are logged
• To avoid GET requests (the result of redirects), return an HTML form with an onload handler that automatically POSTs the hidden fields in the form

A session ID (like a password) must be protected. To prevent session hijacking, a session-based application must run over SSL. If the session mechanism uses cookies:

• Set the secure attribute on the cookie, otherwise it will be passed over insecure (non-SSL) connections
• Avoid setting a timeout on the cookie, even a short timeout, since browsers might then write the cookie to disk

Set session timeouts (on the server) as short as possible. Like passwords, make the session ID difficult to guess and install intruder alarms that detect random or systematic guessing of session IDs.

Do not use IP addresses in an attempt to prevent session hijacking (since it doesn't work and only raises support issues). Remember: Logging out is a user's single best defense against session hijacking.

Access Control

The roles table discussed earlier provides Role-Based Access Control, a typical approach. It would be better, however, if the application were precluded from making access control decisions. Other types of access control are possible (a complex topic). Another approach involves groups and resources, which we discuss now.

For Group-Based Access Control, define groups and resources as follows:

• groups( group, description )
• resources( resource, url, link_text )

The url field is the URL of the protected resource. The link_text field is suitable for constructing hyperlinks (on a portal page, for instance).

The groups table has two columns:

CREATE TABLE groups (
  group       VARCHAR(12)  NOT NULL,
  description VARCHAR(60)  NOT NULL,
  PRIMARY KEY (group) );

The resources table has three columns:

CREATE TABLE resources (
  resource   VARCHAR(16)  NOT NULL,
  url        VARCHAR(80)  NOT NULL,
  link_text  VARCHAR(40)  NOT NULL,
  PRIMARY KEY (resource) );

The group and username fields are the primary keys of the groups and users tables, respectively.

A number of intersect tables are defined:

• group_membership( group, username )
• group_access( group, resource )
• user_access( username, resource )

The group_membership table assigns users to groups. It has two columns:

CREATE TABLE group_membership (
  group      VARCHAR(12)  NOT NULL,
  username   VARCHAR( 8)  NOT NULL,
  PRIMARY KEY (group,username) );

The group_access table attaches groups to resources. It has two columns:

CREATE TABLE group_access (
  group      VARCHAR(12)  NOT NULL,
  resource   VARCHAR(16)  NOT NULL,
  PRIMARY KEY (group,resource) );

The group and resource fields are the the primary keys of the groups and resources tables, respectively.

The user_access table attaches individual users to resources. Like the group_access table, the user_access table has two columns:

CREATE TABLE user_access (
  username   VARCHAR( 8)  NOT NULL,
  resource   VARCHAR(16)  NOT NULL,
  PRIMARY KEY (username,resource) );

Individual user access is primarily for convenience.

What groups does a particular user belong to?

SELECT group FROM group_membership
  WHERE username = 'username';

What groups have access to a particular resource?

SELECT group FROM group_access
  WHERE resource = 'resource';

What users have direct access to a particular resource?

SELECT username FROM user_access
  WHERE resource = 'resource';

Now assume the web service knows the name of the protected resource that requests it. The web service does the following:

1. Validates the session ID
2. Authorizes the corresponding user

The latter depends on whether the user belongs to a privileged group.

What users have group access to a particular resource?

SELECT username FROM group_membership
  WHERE group IN (
    SELECT group FROM group_access
      WHERE resource = 'resource'
  );

Rewriting the subselect as a join:

SELECT username FROM group_membership, group_access
  WHERE group_membership.group = group_access.group
  AND resource = 'resource';

List all users having access to a particular resource:

SELECT username FROM user_access
  WHERE resource = 'resource'
UNION
SELECT username FROM group_membership
  WHERE group IN (
    SELECT group FROM group_access
      WHERE resource = 'resource'
  );

Recall that the default login target is a portal home page. Any authenticated user is allowed access to the portal page. The web service returns a list of URLs to the portal page, which it uses to construct a personalized home page.

What resources does a particular user have direct access to?

SELECT resource FROM user_access
  WHERE username = 'username';

What resources does a particular user have group access to?

SELECT resource FROM group_access
  WHERE group IN (
    SELECT group FROM group_membership
      WHERE username = 'username'
  );

Rewriting the subselect as a join:

SELECT resource FROM group_access, group_membership
  WHERE group_access.group = group_membership.group
  AND username = 'username';

What are the URLs of all the resources a particular user has access to?

SELECT url, link_text FROM resources
  WHERE resource IN (
    SELECT resource FROM user_access
      WHERE username = 'username'
    UNION
    SELECT resource FROM group_access
      WHERE group IN (
        SELECT group FROM group_membership
          WHERE username = 'username'
      )
  );

The URLs and the corresponding text are sufficient to construct a list of links.

Authentication Web Service Components

Assume the database components and web components for authentication/SSO are already in place. The next step is to integrate an application into the authentication/SSO framework.

Any given application must validate the session ID stored in the client-side cookie. Validation occurs at the time a protected resource is requested. Rather than install elaborate validation components in the application itself, we describe a validation web service that accepts validation requests via HTTP. To make use of the web service, an application need only do two things: 1) make an HTTP request, and 2) parse an XML document. These modest requirements make it relatively easy to integrate an application into the authentication/SSO framework.

The web service and the authentication controller share the same database (but are otherwise separate). When the web service receives a validation request, it checks to see if the given session ID is in the database. Validation succeeds if and only if the session ID is in the database. Subsequently an XML document is returned to the client application. The XML document encodes the validation response.

The web service relies on an XML template. This template is used to formulate a validation response. The XML DTD may be of ad hoc design or standard design (e.g., SAML).

The web service supports one action: validate. The corresponding URL is:

/auth/service?action=validate&SID=sid

A request for the validate action always results in an XML document. Both parameters (action and SID) are required. For enhanced security, a request for the validate action should be a POST request with SID parameter encoded in the body of the request.

When requested, a protected resource performs the following steps:

1. Extract the cookie (SID) from the request
2. If the cookie does not exist, redirect the client to the login page with parameter target=self
3. If the cookie does exist, request the web service with SID as parameter
4. If the parsed XML indicates failure, redirect the client to the login page
5. If the parsed XML indicates success and the user possesses the desired role, return the requested resource to the client

When requested, the web service performs the following operations. If the session ID is in the sessions table, the request is valid:

SELECT username FROM sessions
  WHERE SID = 'sid';

Since the SID is the primary key of the sessions table, this query will return 0 or 1 results. If the request is valid, the web service determines the corresponding roles:

SELECT role FROM roles
  WHERE username = 'username';

The resulting roles are encoded in the XML and returned in the response along with the username.

It is up to the client application whether to enforce access restrictions. If the desired role is contained in the list of roles returned from the web service, access is allowed. Other approaches to access control (discussed later) remove this decision-making process from the application.

Authentication Web Components

Once the database components have been installed, the web components may be implemented. The web components needed for authentication include a login page and a controller. The login page has four form elements:

1. a text field (username)
2. a password field (password)
3. a hidden field (target)
4. a submit button (Login)

When the Login button is pressed, the form is submitted to the controller.

The controller processes all login and logout requests. After processing, the controller issues an HTTP 302 redirect or forwards the request to another component (e.g., the login page). The controller does not return HTML (or other markup).

The controller supports two actions: login and logout. The corresponding URLs are:

/auth/controller[?action=login[&target=target]]
/auth/controller?action=logout[&target=target]

The default action is the login action. A GET request for the login action results in the login page. A POST request for the login action includes two additional parameters: username and password. A POST request for the login action always results in a redirect.

A POST request for the login action causes the following steps to occur (in order):

1. authenticate the user
2. update the sessions table
3. create the cookie
4. redirect the client

Each step depends on the success of the previous step.

To authenticate the user, the controller hashes the password and queries the users table:

SELECT username FROM users
  WHERE username = 'username'
  AND password = 'hashedPswd';

The username and hashedPswd are the input username and the MD5 hash of the input password (resp.). The login action proceeds to the next step if the SELECT returns a result.

Next the controller creates and stores an unique session ID:

INSERT INTO sessions VALUES
  ( 'sid', 'username' );

These two steps constitute a database transaction, which must be executed atomically. A better approach is to write a database stored procedure:

stored_proc( 'username', 'hashedPswd' ) ==> 'sid'

The stored procedure authenticates and creates a session in one step.

If the login action succeeds, a cookie is created on the client:

Set-Cookie: SID=sid; path=/; domain=.my.com; secure

This creates a secure cookie visible throughout the my.com domain. The cookie persists for the life of the browser (max).

If authentication is unsuccessful, the controller redirects to the login page. If the authentication is successful and the request has a parameter called target, the controller redirects the client to the target URL. If there is no target parameter, the user is redirected to a personalized portal page.

A request for the logout action always results in a redirect. A GET logout request is equivalent to a POST logout request. In either case, the session ID is invalidated in the sessions table:

DELETE FROM sessions WHERE sid = 'sid';

Instead of physically deleting the session, it may be marked for deletion in the sessions table (with associated cleanup issues).

To complete the logout action, the cookie is expired on the client:

Set-Cookie: SID=; path=/; domain=.my.com; secure; 
  expires=Thursday, 01-Jan-70 00:00:00 GMT

This is a relatively minor issue however, since the corresponding entry in the sessions table has been invalidated. Any subsequent validation attempt will fail.

The target parameter allows seemless integration of the authentication framework. The value of the (optional) target parameter is an absolute URL. The controller redirects to the target URL after completing the action. The default login target is a portal page. The default logout target is the login page.

Authentication Database Components

Three database tables are required to implement a minimal authentication/single sign-on solution:

1. users( username, password )
2. sessions( sid, username )
3. roles( username, role )

Alternatively, an LDAP directory may be used in lieu of a relational database.

The users table has two columns:

CREATE TABLE users (
  username  VARCHAR(8)  NOT NULL,
  password  CHAR(32)    NOT NULL,
  PRIMARY KEY (username) );

For security reasons, the password is stored as an MD5 hash (or other suitable hash value). In particular, cleartext passwords are not stored in the database. Instead, passwords are one-way hashed using MD5:

INSERT INTO users VALUES
  ( 'trscavo', MD5( 'nopass' ) ), ...

Regardless of input, an MD5 hash value is precisely 32 characters:

SELECT MD5( 'nopass' );
==> 0945fc9611f55fd0e183fb8b044f1afe

The sessions table has two columns:

CREATE TABLE sessions (
  sid       CHAR(13)    NOT NULL,
  username  VARCHAR(8)  NOT NULL,
  PRIMARY KEY (sid) );

The session ID (sid) is a unique sequence of 13 characters (or other suitable ID).

The roles table has two columns:

CREATE TABLE roles (
  username  VARCHAR(8)  NOT NULL,
  role      VARCHAR(20) NOT NULL,
  PRIMARY KEY (username,role) );

Access to protected resources is based on roles, which are assigned by the system administrator:

INSERT INTO roles VALUES
  ( 'trscavo', 'user' ),
  ( 'trscavo', 'administrator' );

Any given user may be assigned multiple roles.

Authentication Overview

Basic topics of interest:

• Authentication
• Single sign-on
• Validation
• Authorization

Authentication answers the question "Who are you?" The authentication process requires user credentials, typically a username and password. The credentials are passed to an authentication server and compared to credentials stored in a database or LDAP repository.

Single sign-on (SSO) alleviates the need to authenticate more than once. This may be accomplished by saving state (a session ID) in a client-side cookie, for example. The session ID is then associated with a username in a sessions table.

Single sign-on can occur at various levels:

• Application
• Server
• Intranet
• Extranet

We will concentrate on SSO at the intranet level, that is, across servers throughout a domain. (Later we will discuss SSO across domains.)

Validation is the process that protects web resources. When a protected resource is requested, the session ID is extracted from the cookie. If the session ID is valid (in the sessions table), the request is satisfied.

Authorization answers the question "Do you have access to this resource?" Authorization occurs in conjunction with validation. If the session ID is valid and the username associated with the session ID possesses the desired role (in a roles table), the request is satisfied.

The following system components are required to implement a simple authentication/SSO solution:

• auth database
• login page
• auth controller
• auth web service
• XML template

We start by examining the database components necessary to support authentication and single sign-on.

Gearing Up for the Conference

I'm giving a presentation entitled "Blackboard 6 Authentication" at the 2nd Annual Blackboard Building Blocks Developers Conference on July 27, 2004. Initially, I'll use this blog (thanks Blogger!) to flesh out some ideas related to authentication and single sign-on (SSO) at the enterprise level (intranet), and then perhaps speculate a bit about the current state of federated identity management solutions at the inter-enterprise level (extranet). During the conference (7/26–7/27), I'll capture my view of the conference proceedings here as well.

Briefly, Blackboard is a web e-learning platform. The enterprise version of Blackboard (Bb) has an extensive set of APIs for enhancing and extending the platform. In particular, there is a Java-based authentication API with hooks into the Bb authentication system, which allows institutions to integrate Blackboard into an existing enterprise authentication/SSO framework.

This assumes, of course, that an authentication/SSO framework already exists at the enterprise level, so we'll start there...what might such a framework consist of? Minimally, the framework I have in mind provides for 1) authentication services, 2) single sign-on, 3) validation services, and 4) authorization. We will give a brief introduction to each of these topics in what follows.