Subversion Status

ChangeLog

19:34 bdauvergne rev 4924 [Core] add lasso_node_set_signature and lasso_node_get_signature Those two methods allows to associate signature parameters to any node. They keep it inside the CustomElement quark. Using a private structure may be more performant.
19:34 bdauvergne rev 4925 [Tests/python] add test case for WebSSO with providers using encrypted keys
19:34 bdauvergne rev 4926 [Core] dump custom signature parameters in lasso dumps The signature parameters are serialized as global attributes from the http://lasso.entrouvert.org/lasso/namespaces/0.0 named: SignatureType SignatureMethod PrivateKey PrivateKeyPassword Certificate
19:34 bdauvergne rev 4927 [Core] add a password parameter to lasso_query_sign We force use of the password through a custom OpenSSL password callback.
19:34 bdauvergne rev 4928 [Code] add a lasso_node_export_to_query_with_password method
19:34 bdauvergne rev 4929 [Core] add password parameter to lasso_sign_node
19:34 bdauvergne rev 4930 [Core] Change lasso_apply_signature to use quark stored annotated signature parameters The node containing signature do not handle the private keys passwords. As the fields for signature parameters are part of the public ABI we cannot add the password field to the public structure for those nodes. Instead we use the new quark annotation accessed through lasso_node_get/set_signature, and if the sign_type parameter is non-NULL we use it instead of the parameters stored in the public structure. This is a gross hack :( but at least it is documented.
19:34 bdauvergne rev 4931 [ID-FFv1.2] move all user of lasso_node_export_to_query to lasso_node_export_to_query_with_password
19:34 bdauvergne rev 4932 [SAMLv2] add support for encrypted private keys * support private key with new internal API in signature setting methods Plug lasso_node_set_signature into lasso_profile_saml20_setup_message_signature and lasso_server_saml2_assertion_setup_signature. * also use lasso_node_get_signature in has_signature * add forgottent LASSO_PROFILE_SIGNATURE_VERIFY_HINT_FORCE in switch cases For AuthnResponse checking the semantic is now that if HINT_FORCE is used we verify message signature *and* assertion signature. If HINT_MAYBE is used we check the assertion signature if its issuer differs from the message issuer.
19:34 bdauvergne rev 4933 [ID-FFv1.2] add missing namespace declarations
19:34 bdauvergne rev 4934 [Binding java] return empty list for NULL GList value, not null