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 


This email deals with the IdP distribution, its installer, and 
configuration files.  The combines effects of the first 5 items will be 
that after installation most sites will have an IdP that can perform SSO 
and will only need its attribute filter adjusted.

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

- IdP distribution will come bundled with Jetty (sites don't have to use 
it if they don't want).

- A new "extensions" directory within IDP_HOME will house extension jars 
which will be picked up by the installer when upgrading to new versions 
of the IdP.  So deployers don't have to remember to copy them over from 
the previous version's "src" tree to the new version's.

- Installer will ask for the following information during initial 
installation and save it to a properties file in the IDP_HOME/conf 
directory:
  - server host name and optionally port
  - front-channel SSL certificate and key
  - metadata URL and optionally verification certificate
  - LDAP URL (includes host name, port, and basedDN) and optionally 
username and password
  - IP address of other cluster nodes and cluster password, both optional

- Jetty will be configured to use the hostname, port, front-channel, and 
back-channel (generated by installer) certs/key specified in the 
properties file generated by installer.

- Simplify IdP configuration files as described here: 
https://spaces.internet2.edu/display/SHIB2/IdPSimplifyConfig

- New scripts capable of:
   - generating a new IdP keypair and cert (with options of key length, 
cert validating period, and others)
   - generating IdP's metadata
   - testing that the IdP configuration is loadable
   - start/stop the IdP running inside the provided Jetty container

- Expose configuration options for adjusting signature and encryption 
algorithms and other appropriate paramters.

- Expose configuration option for prioritizing the name identifier 
format used for a particular relying party such that multiple 
attributes, capable of being encoded as a name identifier, can be 
released to a relying party and the IdP will use the most preferred if 
it has a value, then the second most preferred, etc.

- Add ability to validate XML signature on loaded configuration files 
(they all currently support being signed but there is no code to do the 
checking).

- Remove all schema validation and move to wholly programmatic 
validation of configuration files, putting us in control of all the 
error messages.

There are currently no items that have been proposed which I am 
considering but upon which I have not made a decision.

The following features I've considered but ruled out for this release:

- Pretty much any other bit of IdP configuration, not already mentioned 
above, being represented in the configuration property file.  The goal 
of that file is to address the simple 80% use case. It is NOT a 
replacement for the XML configuration files.  If sites want to go beyond 
what the property file offers they will need to edit the XML files just 
as they do today.

- Configuration scripts capable adjusting any of the IdP's XML 
configuration files.

- Ability to specify relying party groups based on a entity attributes 
in the metadata.

--
Chad La Joie
http://itumi.biz
trusted identities, delivered