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 security related options within the IdP. 
These options predominately occur at the end of the relying-party.xml 
configuration file.

Following are things I currently plan to change/add:

- Allow the metadata trust engines to be defined within the metadata 
provider configurations themselves.  References to a separately 
configuration trust engine will still be supported.

- Allow PKIX/credential data to be loaded from multiple sources. 
Currently you can load all of the data from a URL or the filesystem. 
This change would allow you to CRLs, certs, and private key from 
different sources individually (e.g. CRLs from URLs and cert/key from 
the filesystem).

- Support the new XML DSig 1.1 specification.

- Support elliptic curve cryptography algorithms.

- Allows signed requests to bypass ACS URL checks.

- Expose configuration options to control crypto algorithms used when 
signing and encrypting (e.g. using AES256 in signatures).  Currently the 
IdP uses the lowest common denominator for each option. This was 
mentioned in previous email as well.

- Expose configuration options that allow certain crypto algorithms to 
be blacklisted such that they will not be accepted if the SP uses them. 
 This allows the IdP deployer to "ban" algorithms that they feel are 
too weak.

- Support the use EncryptionMethod in metadata in order to help 
determine how to best encrypt data to the SP.

- Move the content found in the relying-party.xml, after the "Security 
Configuration" section header, in to a separate file.  The idea is that 
this would become another file that the vast majority of people never 
touched.

- Create a new Spring application context that loads in all the security 
data in the new security config file.  All service contexts would 
descend from this context.  This allows all the security information to 
be available to the entire IdP (e.g. trust engines would be available to 
the authentication engine and could be used for doing X.509 cert 
authentication).

- Allow credentials and PKIX validation info to be defined at the first 
level of the new security file and referenced by multiple trust engines.

There are currently no items which I am considering but have not yet 
decided on.

There are currently no items that were proposed but rejected.

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