OpenSAML user discussion

["Girish Sundarraj" <>]

Hi Scott,

One quick question! Can we by any way exclude log4cpp from our openSAML
C++ build. Is there any provision to do so? If so what would be the
impact? If not possible can we alter openSAML code such that we 
remove the reference to log4cpp and build the library? What would u
suggest. This is the question raised by our legal department to check
for the possibility & feasibility.

Thanks & Regards,
 
Girish Kumar. S
Lead - RPM AnalyticServer
Direct Line        : +91.80.4136.7506
Main Number    : +91.80.5129.8400
Mobile                 : +91.98455.64329
Fax                      : +91.80.5129.8500

 
Symphony Services
Embassy Heights, 9th Floor,
#13 Magrath Road,
Bangalore - 560 025.
www.symphonysv.com
 

This electronic transmission (and any attached documents) contains
information from Symphony Services and is for the sole use of the
individual or entity it is addressed to. If you receive this message in
error, please notify me and destroy the attached message (and all
attached documents) immediately.

 

-----Original Message-----
From: Scott Cantor 
[mailto:]
 
Sent: Wednesday, May 03, 2006 8:38 PM
To: Girish Sundarraj
Cc: 

Subject: RE: Encryption Software

> Thanks for the response. I am in the process of evaluating the 
> openSAML
> C++ libraries for SAML.

There isn't much/any documentation, and we're working on the 2.0
libraries right now, which will have docs, so you may be better off
waiting depending on your time frame.

> So what I understand is usage of following libraries does not mandate 
> exposing our source  code, even if we download and build the source 
> code for each of them. Also we would be just dynamically linking these

> libraries with our source code and have no intension to alter the 
> source code.

I believe that all but log4cpp have Apache or BSD-style licenses that
allow basically any derivative work, including hacking on the code
itself, without revealing source. The LGPL may be different, I think it
explicitly permits inclusion of binaries in a product, but if you hack
the source, you need to make *that* changed source code available. But
nothing that's linked to the library itself is covered.

Basically, if you're dealing with licensing, get a lawyer, unless you're
just taking all the code as is and distributing binaries or pointing to
other copies. Then you're probably safe.

> Apart from these I have couple of other questions:
> 
> 1. Our product is supported for windows 32/ 64 x-86, SOLARIS 32/64- 
> SPARC  and LINUX 64 X86.  Do we have binaries for all above mentioned 
> libraries readily available? Or we need to build each of them from 
> source?

There are almost no 64-bit builds. I did one set for Red Hat on Opteron
and that's it. I believe the current released OpenSAML code does *not*
build cleanly under any newer MS compiler. I used VS 6.0 until I started
work on the next release, and that's old and 32 bit.

I have copies that build on newer versions so it's not that hard to fix,
but I haven't done any 64 bit Windows builds.

Regardless, you'd be insane to distribute code yourself and rely on
somebody else's binaries anyway.

> 2. In the FAQ in the link http://www.opensaml.org/faq.html#02 Question

> "what is openSAML? " has the answer "C++ libraries support requesting 
> only". What do they exactly mean here?

There is no server side SOAP support, only client side SOAP requests.

> Does it just say that browser artifact is not supported? Does openSAML
> C++ library support both push & pull (SOAP based artifcact) mechanism?

Only the underlying mechanics are supported. Huge amounts of code are
required to implement a SAML SSO system on top of OpenSAML. This is a
library, not a SSO system.

> Actually we are intending to use openSAML C++ library to implement 
> SAML based SSO where we have to write code for client to fetch 
> assertion and write implementation logic for Service Provider.

I think you'd be a lot better served looking at Shibboleth, which
already does all that.

-- Scott