pubcookie

The [install instructions for mod_pubcookie|http://www.pubcookie.org/docs/install-mod_pubcookie-3.0.html] need to be customized but only slightly. This is because the Apache user is likely to have to set up this configuration mostly on their own. There is simply less predictable work that we can do on the Unix platform, unless certain platforms are selected.

The areas that need customization in the base documentation are:
* where to find the granting certificate
* configuring the pubcookie config file (keymgt_uri)
* in general, example.edu can be replaced with uab.edu
* httpd.conf setting for Pubcookie module

The mod_pubcookie module requires Apache 1.3.x. In other words, pubcookie doesn't work with Apache 2.x.

It's possible that when a user bookmarks an application that uses weblogin, that they will wind up bookmarking the weblogin page and not the application page. This is because the first time the user goes to the application, they will likely be redirected automatically to the weblogin page to log in. When they see the user/passwd prompt, they will likely save the bookmark. Unfortunately this will record only the weblogin url and not the actual application they are trying to use.

It's important that a user wait until they have successfully logged in to their web application before setting their bookmark. This will ensure they are setting a bookmark for the correct web server.

important issue. the app servers need to be in the same subdomain as the login server (is this true? - lab can auth from metric, but does it really?

A very important issues for pubcookie to work is that it requires a 1024 bit private key for the certificates. the default is a 512 bit key so, if you don't have a 1024 bit key you need to issue a new CSR with a 1024 bit key and get a new cert from verisign (at uab).

items to support on our site: custom example.reg file, custom zip download, our sites pubcookie_granting.cert, our ca's cert.pem file. these could be put in our uab-pubcookie-3.0.0-win32.zip

We need to customize the the [pubcookie ISAPI instructions|http://www.pubcookie.org/docs/install-filter-3.0.html] to refect the UAB config.

Specifically:
* Verify your privite key size is 1024
* Same "export and convert" step
* Separate ssl cert and private key with more detail on what you will see when opening wordpad
* The "setup supporting files and registry settings" will already include the supporting files
* We need more detail on how to customize the .bat file
* The example.reg should be name uab-pubcookie.reg and be ready to go
* In "request encryption key" our command example needs to have the right names for the files if they are different, we should also fix the item in 3

I spoke with Jim today about the state of the drupal, shib integration, and the state of the cms.

We concluded that the state of the art isn't that great. You either get all or nothing from a vendor/system. It's very hard to do best of breed integration: combining tools that do their function well into a unified whole.

DoIT is already running a [collection of tools| http://arch.doit.wisc.edu/jim/sites.html] for publishing ([geeklog|http://www.geeklog.net/]), bloging ([blosxom|http://www.blosxom.com/]), and tasking ([tasks|http://www.alexking.org/index.php?content=software/tasks/content.php]) and turned to drupal in hope for some integration of these and leverage of some existing modules like project. Ran into limitation of poor granularity of authz on objects in drupal. There is some effort/desire in durpal community for finer grain access but it does seem to be going anywhere.

the switch identity option really needs to replace the logout option (or maybe be in addition to it). this has an impact on the scope of the session.

it's a good question to think on who we are accross all these applications. our login identity really needs to span all the applications that we will integrate. so there needs to be a single def of our role or logged in id.

so if we switch to an annoymous user we are really logging out not only of the local app but of the site webiso session as well (and all other site applications). this is somewhat complicated since is means destroying the pubcookie sess cookie for all apps in our domain and then ensure that each per-app session is aware of the identity change. the question also arrises what this all means in a shib context or if I switch from one "global" user identity to another.

I'm to the point where the role change concept should definitly replace the login concept. You are "logged in" when your session starts, not when the login button is pressed.

The first time you come to the site, the only thing that will happen is that you will be identified as an anonymous user. You'll have the option of changing your role. The user block will be changed to a role selection tool and it will reflect your current role, a summary of permissions with that role, and give you the option of changing your role.

Pressing the change role botton/link will take you to an ssl protected page. This is to enable the reading of any existing secure cookies for the domain, eg. webiso cookies. The page will have options similar to the following with radio button selection capability