weblogin

[phpwiki]
weblogin.ac.uab.edu is now using ldaps to access the LDAP service for authentication. Serveral problems existed which had prevented this from working. The default libldap2 binary on debian woody 2.4 is not built with tls enabled. This was the main problem. The fix was to rebuild the openssl source package on the debian build box:

apt-get source libldap2
cd openldap-2.0.23
dpkg-buildpackage -uc -b

and then install resluting libldap2.deb file on weblogin

dpkg -i libldap2-2.0.23.deb

The next step is to tell libldap where to find the trust definition for the UAB ldap SSL interface. This requires the Equifax root. Put that in /usr/lib/ssl/cert/ca-bundle.crt. The location is defined in /etc/ldap/ldap.conf with the values TLS_CACERT (for the bundle file) and TLS_CACERT_DIR (for the hash based files). While I prefer the later only the TLS_CACERT file option seemed to work.

If you use rewriting rules to define the login path that triggers a pubcookie weblogin (or any ssl-based url reference) and you get a "not found" error from the web server after you successfully log in, make sure you have enabled the rewrite rules in the SSL vhost. Rewrite rules and engine settings don't inherit to vhosts by default so you need to do a RewriteEngine on and RewriteOptions inherit for each vhost you want the global config to influence.

http://webapp.lab.ac.uab.edu/~cyy/patch01.txt

(1) Access Control

Since the phpBB application allows a guest to enter his discuss in the forum, our access control would just
be set in login part. I created a login directory, copied the login.php there, created the .htaccess under the login directory, and then made all necessoary changes.

(2) change/add files

page_header_admin.php
pagestart.php
groupcp.php
page_header.php
usercp_email.php
posting.php
privmsg.php
profile.php
search.php
viewforum.php
viewtopic.php
index.php
login.php
.htaccess

(1) Login with Pubcookie

Start from the index.php file, and it's redirected to Weblogin page. After the user is logged in, it's directed back the index page. Add the code to check the user session. If the user doesn't login, the user is redirected to the login page. In the login page, remove checking the parameter "login", set the static password in the code, get "REMOTE_USER" as a username, and then verify the user with the username and password against the database. After done with that, back to the index page.

(2) Add New User

If this is a new user, the page is redirected to the profile page. In the profile page, set some POST parameters, such as username, password, email etc. and then execute registration.

Original index.php used POST to pass username and password to login.php.
Original login.php accepted username and password from index.php and
performed authentication with function authenticate().

Changes:

• The present index.php does away with the POSTs and control is passed by
  refreshing to login.php. It gets username from $REMOTE_USER and has a dummy
  password set. Email address is set to username@uab.edu

USAGE SCENARIO

1) Login: When the index page is first hit, user is redirected to the weblogin page for BLAZERID authentication. On successful authentication, the user is redirected back to the index page of Mambo. Here the user can browse anonymously. To edit or add content, user has to click on the 'LOGIN' button provided. User does not have to input username or password as it is provided by the weblogin service.

2) First-time login: The user should have a valid BlazerID to access Mambo. An account is automatically created the first time a user accesses the site.

IMPLEMENTATION STEPS

Here are some notes about issues confronted during the webiso integration for serveral applications.

This problem is fixed by specifying a PubcookieAppID for the cookies to use. once the app id is in place all the requests successfully use the this as the "tag" for all sub-tree requests and don't go hopping over to the login server for individual authentication which tends to compete and break other threaded get requests from the client.

different systems often have a different concept about what a user is.
some systems use a simple username, some use a structured user name.

bugzilla uses a login name structured as an email address. The login name
serves both to identify the user and as a contact address for the user.
The user@domain structure in names helps bugzilla span virtual org
boundaries, an environment it's typically deployed in.

bugzilla uses a login type of DB or LDAP to determin the correct
behavior. seems i should introduce a new authn method, maybe EXTERNAL, to
tell it how to behave with remote user. will need to also define a default