OpenSAML user discussion

["Scott Cantor" <>]

> it would verify any saml assertion. Right now the
> security requirement is requiring all saml assertions
> are signed. Those assertions may generated by java, c,
> any program languages, or any federated ID management
> servers that follow SAML 1.1.

Right, that's a pretty nice "perfect storm" of potential places for the
signature to get corrupted.

> I need to write a
> program which can recognize all kind of popular format
> of certificates and use them to verify the signature
> of saml assertion. Based on your answer to my last
> question, signing an assertion may not work in all
> cases.

I'm just saying my code is far from perfect, and I don't think I'm the worst
programmer around, so expect a few problems. Some might be in my code, and
worst case some might not. So far, verifying signatures in my C++ has been
relatively robust. It wasn't easy to get to that point.

> Does that indicate our security requirement for
> all saml assertions must be signed not be realistic?

I wouldn't presume to tell you, but if the interactions are point to point,
my experience is that TLS is a little harder to configure but much more
reliable. SAML assertions tend to be short-lived. The usual motivation for
signing them is when you're forwarding them from one relying party to
another, not as much just as a means of protecting them between the issuer
and the relying party, although sometimes this is necessary.

> I also would like to ask you do me a favor of giving
> some code which can read normal format of certificate
> storage if you ever have.

I've written a little bit of code that you can find in the Shibboleth
file-based CredResolver class that might help (or maybe it sucks and you can
give me what you write if it's better).

http://anoncvs.internet2.edu/cgi-bin/viewcvs.cgi/shibboleth/c/xmlproviders/C
redResolvers.cpp

My goal generally is to get from raw data to OpenSSL objects. If you're
doing something different, you may need a different approach.

-- Scott