pubcookie

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

the myVocs demo went well and along with Jim's work, seems to make a very nice system environment. struck again how clearly bogger.com, technocati's and del.icio.us have the potential to become the major new applications of you desktop with these technologies. amazing to see the type of system experience that can be defined with so many interfaces available. interesting trend graphs to namespace creation and management.

am working on getting the demo in an on-line followable version and will add a link when I ha

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.

• Login user automatically with user's blazerid

In index.php check if $_SERVER['REMOTE_USER'] has been set (which means pubcookie authentication is enabled) and $_USER['uid'] hasn't been set (which means user hasn't logged in). If that is the case, redirect to users.php by setting a Refresh header. I have also tried the Location header, which always leads to a pubcookie error page saying the user has already loged in.

In order to prevent user from seeing the blinking effect of redirecting, the php processing is terminated with exit() after setting the header.

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.

http://mailman.u.washington.edu/pipermail/pubcookie-users/2004-May/000468.html

One (insecure) way of getting port 80 redirects to work for pubcookie.

the lists.u.washington login sequence is a simple wayf, if from
u.washington login here else login there. this type of
"enterprise&friends/others" wayf will be a typical user collection
senario.

thinking about the cosign implementation and comparing to pubcookie and
shib, you can think of them as an ever increasing scope of user bases.
pubcookie is single domain, cosign is two domains (enterprise and friends)
both "hosted" but the same site, and shib is a 2 or more solution though
the complexity of shib suggests you better have a lot to justify the work.