Shibboleth Developers

[Peter Williams <>]

Want to do some pure experiments?

I have some JCE providers that over IP delegate to a HSM. Consistent with 
Shib , the provider only does SSL and other cryptoscheme's crypto primitives 
- it leaves trust management to applications. So, shib stays in control over 
trust stores, with certs, not-certs etc. At the same time, more trusted app 
coding can leverage the trusted cert store of the HSM to enforce trust 
models, if they want to take advantage of the trust management policies 
afforded by the level 3 controls of HSMs.

There are two experiments I'd like to  do (and I personally own the necessary 
hardware, and have the FIPS 140-1 level 3 configuration skill):

1. simply delegate via JCE config to the HSM operating in my garage - 
operating in crypto provider mode. This requires me having access over remote 
desktop to 30mins of the host configuration of the Shib IDP , in which a 
user-mode trusted NTLS (transport layer service) client is installed and 
configured, where the protocol controls access to the certain compartments of 
HSM by those hosts that the associated NTLS compartment trusts (for some 
trust scope). Ive never actually done this on other than windows, but should 
be able to figure out a equivalent install on a reasonably standard linux 
platform.

2. take perhaps an older version of shib, one that works on an older version 
of tomcat, and literally host the Shib IDP inside the tomcat server inside 
the HSM. This may turn out not to be possible with Shib IDP, as only pure 
webapps can be handled this way - only war files transferred through the 
HSM's FSIP 140-1 admin port can augment the HSM's trust platform.

If some of that works, we could test limits. One of the HSM (we operate as a 
pair) could be shipped to the data center of the IDP. One could see if it can 
be remotely controlled by its pair - the only that has the required user 
arming devices (which maintains level 3 policy). Then, we could see if the 
PKCS#12 clustering could be exploited so either unit (local or remote) could 
be used for dsig crypto ops. One coudlsee what Ipv6 routing options would 
make most sense, to control failover and rapidly converge the IDP instances 
(in terracotta) + HSM cluster.

> -----Original Message-----
> From: Paul Hethmon 
> [mailto:]
> Sent: Saturday, April 04, 2009 11:34 AM
> To: Shibboleth Dev
> Subject: Re: [Shib-Dev] IDP crypto
>
> Pretty sure you have to configure Bouncycastle as a provider for Shib
> IdP. Using the Java standard providers method. I'm sure you could use
> another as long as it provides the needed operations.
>
> Paul
>
> Sent from my iPhone
>
> On Apr 4, 2009, at 1:07 PM, "Peter Williams" 
> <>
> wrote:
>
> > Does the shib IDP use the java crypto providers?
> >
> >
> >
> > I.e. using standard JVM configuration, can I supplant the crypto
> > provider Shib IDP uses?
> >
> >
> >
> > Has anyone done it, if possible?