10:23 a.m.
On 11/01/2016 05:04 AM, Stian Thorgersen wrote:
Hynek - your responses seems to be missing the list. Maybe you
didn't
use reply to all?
If SAML is missing a standard way to specify an id for the keys used
that's just stupid IMO. Signature validation is expensive and if there
are multiple keys available it would be plain stupid to have to iterate
over all to check. Granted in most cases we're only talking about a few
keys.
Sounds like the extensions approach is the best one. The id should be
within the assertion and not passed separately.
John - Keycloak has SP libraries as well, so this is an
extension/optimalization that our adapters can use. Do other SP libs
(i.e. mod_auth_mellon) go through the list of keys in order? If so we
just need to make sure the list is sorted by most recent (and active
key) first so there's a high probability the first key is the correct
one. With regards to federation not sure what your comment that the
instances needs to share keys is about. One IdP has a list of keys and
the other IdP needs to figure out which of the keys are the correct one
for an assertion.
1) SAML does have a mechanism to transmit a keyID, just not in the
singular case when the HTTP-Redirect binding is used. The reason being
the SAML message is transmitted as a URL query parameter which has
practical length limitations. I believe OAuth and OIDC, in conjunction
with JOSE, JWT etc. have similar restrictions to accommodate URL length
constraints (sorry, can't give you pointers right off the top of my head
for these other protocols).
2) In the singular case of the HTTP-Redirect binding you can still sign
the AuthnRequest but unlike all other SAML protocol messages there is no
official way to include a keyID. This was Hynek's issue/question.
3) The HTTP-Redirect binding is typically used to send a AuthnRequest
from a SP to an IdP. It's not the only SAML binding you can use to
transmit an AuthnRequest from a SP to an IdP, you can also use the
HTTP-POST or SOAP bindings which do not have the length constraint
imposed by the HTTP-Redirect binding.
4) Using another binding will not work for standard Web SSO because the
flow is different. But that's OK because the proposed mechanism will
only work with cooperating entities, e.g. both the SP and the IdP are
Keycloak implementations. But since this is proposed only for KC to KC
you're free to use whatever binding you want.
5) The only SAML message of concern here is AuthnRequest because only
the HTTP-Redirect binding is affected by the keyID limitation. Although
I believe it's legal to pass other SAML messages in a HTTP-Redirect
binding I'm not aware of any such usage, so this is a very specific case.
6) My comment about instances sharing keys (actually keyID's) was in
reference to the fact *both* parties have to know the keyID so you need
a mechanism to share that information, the entity metadata is the best
mechanism, but you could also do it via some out of band mechanism.
7) The period of time during in which multiple keys are in effect is
expected to be relatively short. The chance of selecting the correct key
on first attempt is high. The keyID issue affects only one protocol
message. The lack of a keyID affects only KC to KC messages. Add all
these together and you've got a very narrow case you're trying to
optimize for. Is this where you need to be spending your optimization
efforts? However this is an easy solution and goes directly to Hynek's
question/issue, see next ...
8) I believe adding the keyID as an additional query parameter for
HTTP-Redirect is the easiest and cleanest solution. SAML does not
prohibit additional query parameters. Query parameters are consistent
with the rest of the HTTP-Redirect binding. Of course one has to be
careful concerning the total URL length. Of course you could also use a
different binding as per item 3 because this is a KC to KC case.
9) Mellon does not currently support key rotation, It would be an RFE.
but one we would be interested in implementing. Actually I don't think
it would be implemented in mellon, rather it would need to be
implemented in the lasso library that mellon uses for SAML. While doing
that work we could also make sure keyID's are utilized.
10) I believe Shibboleth v3 supports key rotation, if so it would be
valuable to see how they approached the problem.
--
John