Redmine Entr’ouvert: Demandeshttps://dev.entrouvert.org/https://dev.entrouvert.org/favicon.ico?15861920342010-07-19T13:49:16ZRedmine Entr’ouvert
Redmine Lasso - Development #167 (Nouveau): Support different signing keys for different roleshttps://dev.entrouvert.org/issues/1672010-07-19T13:49:16ZBenjamin Dauvergne
<p>LassoProvider currently only support two keys for all its role: a signing one and an encrypting one. But the metadata format allows a pair of key by supported role. There should be a way to acces those keys. Maybe through adding real support for elements of the SAMLv2 metadata namespace.</p> Lasso - Development #161 (Nouveau): Add a python full matrix testhttps://dev.entrouvert.org/issues/1612010-07-12T14:56:07ZBenjamin Dauvergne
<p>This test should do the following workflow:<br />- SSO Request \in { Redirect, POST }<br />- SSO Response \in { ARTIFACT, POST }<br />- SLO request \in {asynchronous: SOAP, synchronous: { Redirect, POST } } x { IdP-initiated, SP-initiated }<br />- SLO response \in {asynchronous: SOAP, synchronous: { Redirect, POST } } depending upon the request initial method<br />- FedTerm request \in {asynchronous: SOAP, synchronous: { Redirect, POST } } x { IdP-initiated, SP-initiated }<br />- FedTerm response \in {asynchronous: SOAP, synchronous: { Redirect, POST } } depending upon the request initial method</p>
<p>The test would repeat the work-flow as long as needed to test all matrices combinations. That would replace much of the need to run the integration tests. It accounts for nearly 400 cases. If should be possible to run an ID-FF 1.2 or SAMLv2 full test.</p> Lasso - Development #104 (Nouveau): Make lasso_server_get_first_providerID_by_role use provide->p...https://dev.entrouvert.org/issues/1042010-06-19T09:40:58ZBenjamin Dauvergne
<p>It should allow to progressively stop using the ->role field which should be enforced at caller level. Lasso should not enforce its own policies, but only check declarations (i.e. metadata) and standard mandated policies.</p> Lasso - Development #87 (Nouveau): Move all conditions checking to lasso_saml2_conditions namespacehttps://dev.entrouvert.org/issues/872010-06-09T14:30:05ZBenjamin Dauvergne
<ul>
<li>Take all methods from saml2_helper.c defined on assertion to check conditions and recretate them to check directly on Conditions objects</li>
<li>Use the new methods for the Saml2Assertion methods</li>
<li>Add comparable new method for Samlp2AuthnRequest (which also have a Conditions field)</li>
</ul> Authentic 2 - Development #69 (Nouveau): Simple cookie identity providerhttps://dev.entrouvert.org/issues/692010-06-04T12:16:29ZBenjamin Dauvergne
<p>Implement a simple and custom (or find an existing one well-done) shared cookie SSO server protocol.</p>
<p>This bug can serve to discuss the design of such a protocol and its implementation.</p> Lasso - Bug #54 (Nouveau): Python: support more than one output parameterhttps://dev.entrouvert.org/issues/542010-05-22T07:56:44ZBenjamin Dauvergne
<p>All output parameters should be agregated in a returned tuple or dict.</p> Lasso - Bug #53 (Nouveau): PERL: Support out arguments for strings, xml nodes, nodes and listshttps://dev.entrouvert.org/issues/532010-05-22T07:06:13ZBenjamin Dauvergne
<p>int is already implemented, continue with strings, xmlNode, nodes and lists of thoses.</p> Lasso - Development #52 (Nouveau): For ID-FF 1.2 and SAML 2.0, check that issuer of response is t...https://dev.entrouvert.org/issues/522010-05-22T06:56:09ZBenjamin Dauvergne
<p>Currently it can happen that we accept a response, or an assertion not <br />coming from the expected issuer. We should always check for it, if <br />possible (for asynchronous binding, if the user did not keep the <br />original profile object, we will not be able to know which provider was <br />s targeted by a request).</p>
<p>It should be possible to desactivate this check for debugging purpose.</p>
<p>From the point of view of a caller using an asynchronous binding (redirect or POST) it should be simple, no dumping of the whole profile should be necessary. The two things to match are that the response is to a request we emitted (so check inResponseTo attribute) and that the issuer is the one targetted by the request.</p>
<p>The first can be done by the profile himself if the request is still present, if it's not an accessor must be provided to get to the inResponseTo field easily for ID-FF 1.2 and SAMLv2 (lasso_profile_get_in_response_to() would be ok).</p>
<p>The second one can also be done easily if the request is still in the profile object are by the caller through other means helped by an accessor.</p>
<p>A flag on the profile should indicate that the caller will do the job instead of Lasso, otherwise the absence of the request would result in a failure.</p> Lasso - Development #51 (Nouveau): Check Assertion in AuthnResponse as mandated by the specificationhttps://dev.entrouvert.org/issues/512010-05-22T06:47:53ZBenjamin Dauvergne
<p>Currently we just loop over all assertion checking basic things like issuer and signatures.</p>
<p>There should be more assertion checking in the sense that the caller of lasso could juste ask the Login profile which assertion resulted in the SSO process successing.</p>
<p>The specification mandate that the received AuthnResponse must at least contain one assertion with an authentication statement from the targeted IdP. We should check this exactly. Then we should report through the assertion field the winning assertion.</p> Lasso - Development #50 (Nouveau): Add a strict mode for lasso_node_init_from_xmlhttps://dev.entrouvert.org/issues/502010-05-22T06:40:10ZBenjamin Dauvergne
<p>We already have some form of schema through the XmlSnippet structures. I think we could add more strict checking with some more flags and checking.</p>
<p>First we could check strict ordering since XSchema suppose it. That is we would match the sub-elements in-order unless specified otherwise (they are in an <xs:choice/>). As the XmlSnippet cannot be nested, the flag would be put on the sub-elements contained in the choice and would mean "don't care about my order", SNIPPET_UNORDERED wouldbe a good name.</p>
Second we could check cardinality. I think there is only three cardinalities used in SAML standards:
<ul>
<li>needed (1)</li>
<li>optional (0 or 1)</li>
<li>optional-free (0 or more)<br />that could be mapped to three new flags: SNIPPET_NEEDED, SNIPPET_OPTIONAL and SNIPPET_OPTIONAL_FREE.</li>
</ul>
<p>We could even implement a script to check that all SNIPPET_OPTIONAL_FREE points to properly declared GList fields.</p> Lasso - Development #49 (Nouveau): Report which assertion is signed and who signed ithttps://dev.entrouvert.org/issues/492010-05-21T20:26:09ZBenjamin Dauvergne
<p>Extract from a comment in mod_mellon in auth_mellon_handler.c:936 :<br />«<br /> /* TODO: lasso only verifies the signature on the <em>first</em> asserion
* element. Therefore we can't trust any of following assertions.
* If the Response-element is signed then we can trust all the
* assertions, but we have no way to find what element is signed.<br /> */<br />»</p>
<p>It would be useful to add a quark attachement to nodes giving their signature<br />validation status, mainly request/response messages and assertions.</p> Lasso - Development #46 (Nouveau): Add a way to verify SubjectConfirmationData->Recipient with th...https://dev.entrouvert.org/issues/462010-05-21T20:14:45ZBenjamin Dauvergne
<p>We need helper API to validate this field with the value given by the SP<br />AssertionConsumer handler for its URL.</p> Lasso - Development #45 (Nouveau): Add an utility function to complete an AuthnResponse with the ...https://dev.entrouvert.org/issues/452010-05-21T20:14:33ZBenjamin Dauvergne
<p>See page 19 of document saml-core-2.0-os.pdf ("Assertions and Protocols for the<br />OASIS Security Assertion Markup Language (SAML) V2.0")</p>
<p>Extracted from the referenced page (page 19 of document saml-core-2.0-os.pdf)</p>
<p>Attributes:<br />« Address [Optional]<br />733<br /> The network address/location from which an attesting entity can present<br />the assertion. For example,<br />734<br /> this attribute might be used to bind the assertion to particular client<br />addresses to prevent an attacker<br />735<br /> from easily stealing and presenting the assertion from another location.<br />IPv4 addresses SHOULD be<br />736<br /> represented in the usual dotted-decimal format (e.g., "1.2.3.4"). IPv6<br />addresses SHOULD be<br />737<br /> represented as defined by Section 2.2 of IETF RFC 3513 [RFC 3513] (e.g.,<br />738<br /> "FEDC:BA98:7654:3210:FEDC:BA98:7654:3210").<br />739 »</p> Lasso - Development #44 (Nouveau): Add to the doc the basic necessity of SAML securityhttps://dev.entrouvert.org/issues/442010-05-21T20:12:44ZBenjamin Dauvergne
<p>We can add lot of verification between request/response (that the ID match,<br />that the reponse is qualified toward the SP, etc....), but there will always be<br />thing we cannot verify inside Lasso, like the IP of the client (if the IdP add<br />it as a verification means to the AuthnResponse) or if the notBefore, notAfter<br />attribute are respected (we are not sure of the time at the SP).</p>
<p>We should explicitely mention all those things that the SP could and should<br />verify aroun SAML exchanges but that are not in the scope of Lasso. It should<br />eventually be a section of the documentation.</p> Lasso - Development #30 (Nouveau): Add node objects for the SAMLv2 metadata schemahttps://dev.entrouvert.org/issues/302010-05-20T11:51:59ZBenjamin Dauvergne
<p>LassoNode subclass must be generated from the schema of SAMLv2 metadata files.</p>