Skip to Content.
Sympa Menu

shibboleth-dev - Re: non-web services integration

Subject: Shibboleth Developers

List archive

Re: non-web services integration


Chronological Thread 
  • From: Mark Allen Earnest <>
  • To:
  • Subject: Re: non-web services integration
  • Date: Thu, 29 Jun 2006 09:21:22 -0400

giacomo tenaglia wrote:
Hi,
I'm an italian computer science student and I'm working on a thesis
project about SSO in digital library environment, for services such as
document delivery, inter-library loan, and a p2p document-oriented
file-sharing program.

I've decided to use Shibboleth and I'm setting up a testing environment
between web services.. and I'm wondering how to integrate the p2p one.
I've figured out some different ways to achieve this:

- simply interoperate with the web browser, but it's too much
application-dependent
- use GridShib, but maybe it's too "big" for my purposes
- integrate Shibboleth SP specs into the file-sharing program (it's
written in Java), but the cookie problem persists

Do you have any suggestion ?

We integrated Shib with a p2p program (specifically gnutella/limewire) called lionshare ( http://lionshare.its.psu.edu )

To get around the cookie issue we ended up replacing the SSO component completely with something we call the SASL-CA

The SASL-CA functions as a short term (or "junk") certificate signing authority that authenticates the user (it negotiates the authentication method using SASL) and signs a certificate signing request with a cryptoshibhandle as the DN.

When a user wants to access a protected file, rather than having the "server" peer make the call to the AA, we have the "client" peer call it and request attributes about themselves. This was they can act as their own attribute release policy engine in real time when requesting files.

To do this we modified the AA to verify that the client cert has a DN which matches the one in the SAML attribute request (remember it is the cryptoshibhandle from the SASL-CA) and it also places that client cert into the SAML attribute response as holder of key confirmation data. This way when the "server" peer gets a request from the "client" peer asking for a file, it can verify that the client peer is the holder of the key in the assertion (it has to be a mutual auth SSL connection obviously).

Lionshare is written in java and is open source (GPL) so you can take a closer look at how we did it. Also feel free to email me directly if you have any questions or want further clarification (the above description is pretty simplified).

Mark Earnest

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature




Archive powered by MHonArc 2.6.16.

Top of Page