Shibboleth Developers

[Chad La Joie <>]

STOP! Before reading the main contents of this email please be sure you 
have read this:
http://groups.google.com/group/shibboleth-dev/browse_thread/thread/1fcab032218f8ffb 


Note, I will be mostly unavailable the next three weeks so there will be 
a 3-4 week pause between this topic and the next.

This email deals with the authentication engine, the component 
configured by means of the <LoginHandler> in handlers.xml and the 
login.config file (if you're using JAAS).

Following are the things I currently plan to change/add:

- Break the authentication process in to two parts: credential 
extraction and credential validation.  The extractors (and there can be 
multiple) will be responsible for pulling credentials off the request. 
The validators will take the set of extracted credentials and determine 
if there is enough there to authenticate the suer.  This two step 
process is required in order to support non-browser based services 
(a.k.a web services) which have no truly standard way of delivering 
credentials.

- Credential extractors that support extracting:
   - username from REMOTE_USER
   - username/password from a web form and WS Security token
   - X.509 client certificate from the SSL session and WS Security token
   - IP address from request

- Credential validators that support validating username, 
username/password, X.509 v3 certs, IP address

- Move the login form and error pages outside the IdP WAR file so that 
it can be maintained separately.  This also means people upgrading the 
IdP won't need to remember to copy their customized pages in to the IdP 
src directory before running the install/update script.  A side effect 
of this change will be that the pages will no longer be JSPs, since 
those can only function within the container.  Velocity, the same 
template system used in the attribute resolver, will likely be used for 
the pages.

- Disabling SSO (i.e. previous session support) based on:
   - IP address of the request
   - user input (e.g. a checkbox on the login page)

- Provide a relaying party configuration option that allows a list of 
allowed authentication methods.  Only those listed will be usable to log 
in to that service.  Sites can turn off SSO for the relying party config 
by not listing the previous session method.

- Performance metrics for: time it takes each credential extractor to 
run, time it takes each credential validator to run, total 
authentication time

Following are the things I am currently considering, but not committed to:

- Detect "replayed" authentication requests caused by use of back-button 
and send the user back to the SP.  I've not yet thought about all the 
data that would need to be tracked to do this so I'm not sure if it's 
really possible in all cases.  Seems like it should be though.

- Move all authentication "transaction" data into cookies.  This would 
allow for (in-memory) stateless IdPs *if* an IdP chooses not to support 
artifacts, attribute queries, and logout.  This is describing more IdPs 
as time goes on.  That is to say, no clustering technology would be 
needed in order to have a cluster of IdPs.  Whether I do this or not is 
mostly a question of whether I can fit all the data that needs to be 
tracked into cookies and can get the cookies to behave properly.

- Ditching the JAAS interface in favor of something else.  The way that 
JAAS works has a number of limitations, mostly because it was never 
meant to be used with web apps, and having something specifically 
designed for such a use case might be better all around.

There are currently no ideas that I've considered and decided against.
--
Chad La Joie
http://itumi.biz
trusted identities, delivered