As mentioned in the section called “Planning”, the first task is to set up a Shibboleth Identity Provider (Origin) Server including PubCookie. This documentation assumes that the URL for your Blackboard server is: http://blackboard.uni.ac.uk/
The basic steps in the process are to set up a Shibboleth Target for the Blackboard server; join it to a federation if required; enable SSL encryption on the Blackboard server;
If you opt for joining a federation, ensure that you SSL certificate provider (e.g. Globalsign) is supported by the federation
modify the Blackboard configuration files, specifying the Shibboleth Identity Provider Server; and finally change the authentication method to Shibboleth in the Blackboard system administration panel.
Blackboard has been working on enabling its course management software to use Shibboleth as an authentication and attribute transport tool. There is a description on the Internet2 website which guides you through a demo with a 'shibbolised' Blackboard server[5]. As yet, Blackboard is not ready for a production Shibboleth service.
In order to maximise portability, enterprise systems must be able to seamlessly exchange data in a secure manner. The Internet2 Middleware Working Group on Shibboleth has been working to test and refine the ability for learners and instructors to seamlessly move from one learning platform to another across campuses and3 geographic boundaries without having to re-authenticate.
The Blackboard Learning System includes out of the box support for Enterprise interoperability - the ability to integrate Blackboard with student information systems, central authentication systems and library systems; and to shibde information about users, courses, enrolment records and grades. Blackboard’s ability to support back office integration follows several standards, including the IMS Enterprise Specification, authentication integration with LDAP, Kerberos and DCE as well as Internet2 Shibboleth integration, see: http://www.blackboard.com/docs/AS/Blackboard_Whitepaper_Standards_QE.pdf
The basic steps to obtaining a certificate are as follows:
Log in to the Blackboard Web server as root
Check to see if openSSL is already installed on your system. Ensure that the PATH includes the openSSL code provided by Blackboard, or a compatible version:
PATH=/usr/local/blackboard/apps/openssl/bin:$PATH
export PATH
If it does not already exist, create the following directory for storing your new certificates:
mkdir
/usr/local/blackboard/apps/httpd/conf/certs
Then change to this directory:
cd
/usr/local/blackboard/apps/httpd/conf/certs
Generate an unencrypted RSA private key – back it up and keep this file safe it should only be readable by root
openssl genrsa -out server.key
1024
Create a certificate signing request (CSR) for the server RSA private key - use instructions from the CA or run the following command which will ask you several questions – the common name should be the machine name as it will appear in the URL of the Blackboard server e.g. 'blackboard.uni.ac.uk' in our example
openssl req -new -key
server.key -out server.csr
Depending on the requirement of the CA you may have to set an expiry date (e.g. 365 days) at this point. GlobalSign did not require this, but if your CA does, run this command instead:
openssl req -new –days 365 -key
server.key -out server.csr
Then read and check the details you put in the signing request using:
openssl req -noout -text -in
server.csr
Finally, send this file server.csr to the CA for signing. They should generate a server.crt file for you. You now have your signed certificate.
These notes were developed using Blackboard Learning System (Enterprise ) version 6.3.1.374-hf1, running on Red Hat Linux Advanced Server Release 2.1AS/i686. This clean install was initially set to use Blackboard's Challenge-Response authentication mechanism (although later it will be changed to authenticate via Shibboleth).
These instructions are essentially the same as those you would use to configure any other Apache server to communicate using SSL, with a few extra changes made to Blackboard's configuration files.
The Apache Web Server must be correctly configured to communicate over SSL before you try to enable SSL Choice from the Blackboard GUI (using the System Administrator Panel) or you will lock yourself out of the server.
The mod_SSL package required to run Blackboard under SSL was not bundled with early releases of Blackboard. Users of versions prior to 6.0.11 will have to follow some additional steps detailed in the Blackboard Setup Guide for UNIX to add this package. Users of versions of Blackboard after 6.3.1 should check the Blackboard Setup Guide for UNIX to ensure that the procedure hasn't changed significantly since these notes were developed.
The following list of points should be followed:
Obtain a certificate from your chosen Certificate Authority (CA) e.g. GlobalSign. The CA should provide installation instructions, or see the Apache documentation at http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#aboutcerts [see section 3.1.3]
The next step is to check that the main Apache configuration file httpd.conf has the necessary flag set to make it use SSL. The Blackboard Setup Guide for UNIX instructs you to add a new line to the file /usr/local/blackboard/apps/httpd/conf/httpd.conf, but on our clean installation, we found it was already present at the very end:
Include
conf/ssl.conf
Blackboard comes with some self signed (and expired!) SSL certificates, you should replace these.
Your new server key file (server.key) should be placed into this directory: apps/httpd/conf/ssl.key
Your server certificate file (server.crt) should be stored here: apps/httpd/conf/ssl.crt If you are running 6.3 or 6.2, the Blackboard Setup Guide for UNIX instructs you to inform the server of their location by modifying the bb-config.properties file located at: /blackboard/config/bb-config.properties by adding these two lines:
SSLCertificateFile
/<path>/server.crt SSLCertificateKeyFile
/<path>/server.key
This instruction appears incorrect. A search of the file showed that two similar entries were already in place:
#####################################################################
############## UNIX - Platform Configuration #################
#####################################################################
#####################################################################
########################################################################
################## ssl configuration settings ##############
########################################################################
bbconfig.unix.ssl.certificatefile=/usr/local/blackboard/apps/httpd/conf/ssl.crt/server.crt
bbconfig.unix.ssl.certificatekeyfile=/usr/local/blackboard/apps/httpd/conf/ssl.key/server.key
Therefore we did not make any further changes to the bb-config.properties file If you are using an older version of Blackboard the Blackboard Setup Guide for UNIX instructs you to add (or check for the existence of?) similar lines in this file instead:
/usr/local/blackboard/apps/httpd/conf/ssl.conf
We expect that this is where you would really have to add these two lines:
SSLCertificateFile
/<path>/server.crt SSLCertificateKeyFile
/<path>/server.key
Now stop and restart your Blackboard server so that these changes take affect.
From /usr/local/blackboard/tools/admin/
issue the command:
ServiceController.sh
services.webserver.restart
You can now test the configuration is correct by going to the https version of your normal blackboard URL: https://blackboard.uni.ac.uk/. If this page opens and then automatically redirects you to the normal (insecure) login page (http://blackboard.uni.ac.uk/) without complaining about certificates then everything is working. Blackboard will not accept login via SSL until you complete the process by enabling SSL from the System Administrator panel (see Section 3.2.2: Part 2).
If you get complaints about unsigned certificates read the section on Certificates signed by an Intermediate below.
If your CA has issued a certificate that is itself signed by an intermediate certificate, you will require a chain of one or more certificates to get to one of the root certificates the browser will trust. Otherwise you will see a range of certificate warnings when you point your browser at this URL.
You can use this command to see what authority your certificate is signed by:
openssl x509 -noout -text -in
server.crt
In our case the certificate was not signed directly by an authority listed in the file: apps/httpd/conf/ssl.crt/ca-bundle.crt Thus we needed to download the intermediate certificate(s) in PEM format from the CA. In the case of the GlobalSign website, we visited the 'GlobalSign Trust Hierarchy' section and downloaded two files: primserver.pem and ServerSign.pem. With these extra files you can either:
Save these two PEM files to the apps/httpd/conf/ssl.crt/ directory, and append ".crt" to the end of the filenames (e.g. to create primserver.pem.crt and ServerSign.pem.crt)
Run make in that directory
make
Assuming your blackboard installation is at
/usr/local/blackboard add this line to the file
apps/httpd/conf/ssl.conf
:
SSLCACertificatePath
/usr/local/blackboard/apps/httpd/conf/ssl.crt/
Note that these changes to apps/httpd/conf/ssl.confb
will be overwritten the next time you run PushConfigUpdates.sh unless you also make
them to the file apps/httpd/conf/ssl.conf.bb. Or,
alternatively:
Concatenate the two PEM files together to give a single certificate file (eg. called ca.crt)
Put this file in the apps/httpd/conf/ssl.crt/
directory
Assuming your blackboard installation is at
/usr/local/blackboard add this line to the file
apps/httpd/conf/ssl.conf
:
SSLCertificateChainFile
usr/local/blackboard/apps/httpd/conf/ssl.crt/ca.crt
Either way, after stopping and restarting the server, this should allow you to go to the https address of your Blackboard site without certificate warnings.
SSL configuration options are set from the Blackboard System Administration panel. Typically a user must have System Administrator rights to alter this setting. To locate the SSL choice option:
Log on to your blackboard server with an account which has System Administrator rights
Click on the System Admin tab to display the Administration Panel
Under the heading Security, click on the option SSL choice
A standard Blackboard stepped page is shown. The key choice is made in step 2. The three options are essentially: - SSL disabled system-wide - SSL enabled system-wide - SSL enabled only for specified areas (specified in steps 3 - areas, step 4 - tools and step 5 - system extensions).
The option enable SSL system-wide was selected for maximum security and minimum maintenance. Depending on the configuration of your servers and usage patterns, you might find this gives too great a performance hit. In this case you may want to only enable SSL communication in selective areas. This will require you to review SSL settings when you add new course tools or system extensions (building blocks).
After you have made your choice, press the Submit button (step 6) to complete the process.
You should now be able to connect to your Blackboard server using SSL: https://blackboard.uni.ac.uk/.
Typically a Blackboard installation includes a second web server which runs the Java-based Virtual Classroom and Chat tools. This server is known as the collaboration server and needs to be separately configured for SSL communication.
As this has no relevance to the Shibboleth project, the reader is referred to the standard configuration options given in chapter 5 of the Blackboard Setup Guide for UNIX . They would also be advised to review recent postings about App Pack 3, SSL and the Collaboration Server on the BBADMIN-L listserver: (http://is.asu.edu/instruction/faq/usingBBADMIN-L.html).
The key thing to watch out for during the installation is which system you will authenticate against, e.g. your local Active Directory Server; this is only an issue as Blackboard may be authenitcating locally, using its internal store of passwords. Note that a Blackboard test server should be used so that you can experiment without messing up the production service. Blackboard is not ready for a production Shibboleth service yet.
In this case the institutional managers only need to know that the authentication mechanism is being switched to Shibboleth, and it would be useful for them to understand why this will be required in future. The Blackboard implementation itself should not be altered. Also, the out of the box Blackboard does not support WAYFs.
Existing agreements within the institution should cover local users' access to Balckboard. However, access to Shibboleth-controlled resources available from within the federation you joined may require separate agreements to be set up.
It is likely that the biggest issues with carrying out the above installation will arise from gaps and lack of clarity as to the necessary steps to be taken in the documentation supplied with Blackboard. For example, in the Shibboleth Integration overview, supplied at http://www.blackboard.com/docs/r7/70/en_US/admin/bbas_r7_0_a... [NB NEED FULL URL FROM MALCOLM] under the installation instructions:
“3. Download the correct Shibboleth package for the operating system and install it...”
with no further explanation offered. This has been fed back to Blackboard, and they have responded that for the next version the instructions will be improved.
There are currently no attribute issues as the out of the box Blackboard does not support WAYFs - the Shibboleth Identity Provider server's address has to be written into the code in the configuration file. Blackboard have also been made aware of this.