On Tue, Nov 1, 2016 at 4:23 PM, John Dennis <jdennis(a)redhat.com> wrote:
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
> 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
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
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.
Which out of band mechanism you mean? I am not aware of any standard one.
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.
Key ID in query parameter (or any additional query parameter) in the
parameter would not protected by the signature, only
SAMLRequest/SAMLResponse, RelayState, and SigAlg are. Including it in SAML
protocol message has hence benefit in Key ID protection.
9) Mellon does not currently support key rotation, It would be an
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.
That would be valuable.
10) I believe Shibboleth v3 supports key rotation, if so it would be
valuable to see how they approached the problem.
I agree, thanks for the pointer.