Supporting multiple authentication methods

[wrygiel]

The problem

This thread deals with this particular quote (taken from this thread):

These "four security aspects" don't seem to clash with each other much, it seems that we can design a way of replacing any single one without affecting all the others.

The primary questions here are:

• How the server will communicate to the client which authentication/encryption methods it supports (or requires) for a particular API?
• How the client will communicate to the server which authentication/encryption method it uses, and which it wants the server to use?

Previously, when there were only two combinations to support, the server added the <allows-anonymous-access> element to specific API entries in his manifest file. Now however, we will have many more combinations to support (and even more will be added in the future, as certain security features are deprecated in time).

Solution 1 (http-security element)

Our initial proposal is to include a <http-security> section in all API entries. It would look, for example, something like this:

<ewp:http-security>
    <ewp:client-auth-methods>
        <!-- <ns1:anonymous/> -->
        <!-- <ns2:tlscert/> -->
        <ns3:httpsig/>
    </ewp:client-auth-methods>
    <ewp:server-auth-methods>
        <ns4:tlscert/>
        <ns5:httpsig/>
    </ewp:server-auth-methods>
    <!--
    <ewp:request-encryption-methods>...</ewp:request-encryption-methods>
    <ewp:response-encryption-methods>...</ewp:response-encryption-methods>
    -->
</ewp:http-security>

In this particular example, the server states that:

• It doesn't allow Anonymous Client Access (because there is no <anonymous/> entry in <ewp:client-auth-methods>).

• It doesn't allow TLS Client Certificate Authentication (because there is no <tlscert/> entry in <ewp:client-auth-methods>). If we removed the comment from around the <ns2:tlscert/> above, then the server would state that it supports both methods of client authnetication at this endpoint (this might be a good idea, especially during the transition months).

• It requires clients to authenticate using HTTP Signatures (because it's the only entry present under <ewp:client-auth-methods>).

• It supports signing responses, but only if the client exlicitly requests that it wants the responses signed. Otherwise it will fall back to standard unsigned TLS responses (because it supports both in <ewp:server-auth-methods>).

• It requires client's requests to come over TLS with no additional body encryption. If <ewp:request-encryption-methods> is missing (as in this example), then it takes its default backward-compatible value of "trusting TLS with encryption".

• Declaring supported/required encryption methods would work in the same way. In this particular example, the server doesn't support any additional response body encryption. It trusts the TLS transport to properly secure the response (this will be the default setting, when no <ewp:request-encryption-methods> nor <ewp:response-encryption-methods> will be provided in the <ewp:http-security> element).

@erasmus-without-paper/all-members

[wrygiel]

Done.

What we ended up with is very similar to the solution described above (which no-one commented on, so we assumed everyone was fine with it). The only differences are:

• The http-security element will not be present in the ewp: namespace, but in the API's namespace. This allows API designers to have multiple http-security elements when needed (e.g. a different one for each endpoint).

• The direct children of http-security also won't be present in the ewp: namespace, but in the newly create namespace described in the Version 2 of the Authentication and Security document.

[wrygiel]

BTW - note, that this issue was NOT about introducing new security methods. It was only about allowing server implementers to choose which security methods they support.

(As to the new security methods, we will introduce them soon.)