12:48 p.m.
Hi All,
re KEYCLOAK-1881 [1]: Key rotation in SAML needs to distill key ID used
for signing for every signature (assertion/document-level) to validate
the signature with the correct key. In POST binding, dsig:KeyInfo
element bears this information in dsig:KeyName both for signed
assertions and for the whole document (a.k.a. protocol message).
For REDIRECT binding in SAML, there is currently no place where KeyID
can be inserted on document level. The document signature in REDIRECT
binding has to be removed from the document (line 578 in [2]) and
replaced by the Signature query parameter, so it is not advisable to put
key ID there.
To solve this, there are multiple options:
1) Modify SAML assertion by adding <Extensions> element that would
include document signing key ID. For consistency reasons, this would
also be present for POST binding SAML documents. This only works for
SAML 2.0 but that does not matter as REDIRECT is new to SAML2.0 anyway.
2) Pass signing key ID in REDIRECT query parameter (next to Signature
and SigAlg parameters) - seems not strictly against the spec but weird
3) Pass signing key ID in custom HTTP header - this might impact
clustering setup and is even weirder than the previous item
4) Claim REDIRECT binding not supporting signatures signed with key
rotation and only support them for POST bindings (for REDIRECT, it would
only work for preset public keys). This is not a viable option for
dynamic key retrieval, so including just for completeness.
Seems like Option 1 or 2 is the one to go. Any thoughts/suggestions?
Thanks
--Hynek
[1] https://issues.jboss.org/browse/KEYCLOAK-1881
[2] https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf
2:09 p.m.
On 10/31/2016 07:48 AM, Hynek Mlnarik wrote:
Hi All,
re KEYCLOAK-1881 [1]: Key rotation in SAML needs to distill key ID used
for signing for every signature (assertion/document-level) to validate
the signature with the correct key. In POST binding, dsig:KeyInfo
element bears this information in dsig:KeyName both for signed
assertions and for the whole document (a.k.a. protocol message).
For REDIRECT binding in SAML, there is currently no place where KeyID
can be inserted on document level. The document signature in REDIRECT
binding has to be removed from the document (line 578 in [2]) and
replaced by the Signature query parameter, so it is not advisable to put
key ID there.
To solve this, there are multiple options:
1) Modify SAML assertion by adding <Extensions> element that would
include document signing key ID. For consistency reasons, this would
also be present for POST binding SAML documents. This only works for
SAML 2.0 but that does not matter as REDIRECT is new to SAML2.0 anyway.
2) Pass signing key ID in REDIRECT query parameter (next to Signature
and SigAlg parameters) - seems not strictly against the spec but weird
3) Pass signing key ID in custom HTTP header - this might impact
clustering setup and is even weirder than the previous item
4) Claim REDIRECT binding not supporting signatures signed with key
rotation and only support them for POST bindings (for REDIRECT, it would
only work for preset public keys). This is not a viable option for
dynamic key retrieval, so including just for completeness.
Seems like Option 1 or 2 is the one to go. Any thoughts/suggestions?
Thanks
--Hynek
[1] https://issues.jboss.org/browse/KEYCLOAK-1881
[2] https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf
I'm confused because I don't understand what problem you're trying to
solve. It sounds like you want to lookup up a key based on an ID
received in a SAML message. But you already know the keys associated
with the client because they are bound to the client via the client's
entityID. Could you clarify please?
--
John
2:22 p.m.
The use case is to support key rotation with SAML, where the realm keys
are used for signing the assertions, similarly to key rotation support
for OIDC introduced in 2.3.0 ( KEYCLOAK-905). Hence the keys are bound
to a particular realm (IdP to SP direction, SP verifies IdP's
signature), and can be rotated at IdP on demand. IdP can provide
multiple valid keys for the realm, e.g. current and previous
certificates for signature validation to allow seamless key rotation.
Hence key ID information needs to be included with the assertion/message
to provide hint on which key was used for signing. For details, please
see comments KEYCLOAK-1881 [including comments].
--Hynek
On 10/31/2016 02:09 PM, John Dennis wrote:
On 10/31/2016 07:48 AM, Hynek Mlnarik wrote:
> Hi All,
>
> re KEYCLOAK-1881 [1]: Key rotation in SAML needs to distill key ID used
> for signing for every signature (assertion/document-level) to validate
> the signature with the correct key. In POST binding, dsig:KeyInfo
> element bears this information in dsig:KeyName both for signed
> assertions and for the whole document (a.k.a. protocol message).
>
> For REDIRECT binding in SAML, there is currently no place where KeyID
> can be inserted on document level. The document signature in REDIRECT
> binding has to be removed from the document (line 578 in [2]) and
> replaced by the Signature query parameter, so it is not advisable to put
> key ID there.
>
> To solve this, there are multiple options:
>
> 1) Modify SAML assertion by adding <Extensions> element that would
> include document signing key ID. For consistency reasons, this would
> also be present for POST binding SAML documents. This only works for
> SAML 2.0 but that does not matter as REDIRECT is new to SAML2.0 anyway.
> 2) Pass signing key ID in REDIRECT query parameter (next to Signature
> and SigAlg parameters) - seems not strictly against the spec but weird
> 3) Pass signing key ID in custom HTTP header - this might impact
> clustering setup and is even weirder than the previous item
> 4) Claim REDIRECT binding not supporting signatures signed with key
> rotation and only support them for POST bindings (for REDIRECT, it would
> only work for preset public keys). This is not a viable option for
> dynamic key retrieval, so including just for completeness.
>
> Seems like Option 1 or 2 is the one to go. Any thoughts/suggestions?
>
> Thanks
>
> --Hynek
>
> [1] https://issues.jboss.org/browse/KEYCLOAK-1881
> [2]
> https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf
I'm confused because I don't understand what problem you're trying to
solve. It sounds like you want to lookup up a key based on an ID
received in a SAML message. But you already know the keys associated
with the client because they are bound to the client via the client's
entityID. Could you clarify please?
2:56 p.m.
On 10/31/2016 09:22 AM, Hynek Mlnarik wrote:
The use case is to support key rotation with SAML, where the realm
keys
are used for signing the assertions, similarly to key rotation support
for OIDC introduced in 2.3.0 ( KEYCLOAK-905). Hence the keys are bound
to a particular realm (IdP to SP direction, SP verifies IdP's
signature), and can be rotated at IdP on demand. IdP can provide
multiple valid keys for the realm, e.g. current and previous
certificates for signature validation to allow seamless key rotation.
Hence key ID information needs to be included with the assertion/message
to provide hint on which key was used for signing. For details, please
see comments KEYCLOAK-1881 [including comments].
Yes, I understand the key rotation issue, what I don't understand is why
you need a key id. Both the SP and the IdP can identify the key based on
the entityID in the SAML message. In the case of key rotation there is
an ordered list of keys. You obtain the list based on the entityID and
iterate over the list trying each key in succession.
What value is there in sending the key id in the SAML message? It's an
optimization that only works if each party knows how to interpret that
value and to the best of my knowledge there is no interoperability
mechanism defined for this. Remember it's the receiving party that must
select the correct key to verify the signature or decrypt a message.
Only the sending party can insert the key id into the message, so even
if you included the key id I don't understand what it's accomplishing
because the receiving party would have to interpret that value (the
sending party which knows the key based on ID but it would never see the
key id in a message).
--
John
3:53 p.m.
That trying to test every key is exactly what I'm trying to avoid.
You're right that the verifying party needs to understand how to
determine key ID. Fortunately, in the case where Keycloak is both
signing and validating so this condition is satisfied.
I guess I'd have to go that way you suggest for REDIRECT if no other
option proves viable, but trying to test every and each available public
key to a verification of SAML signature seems both suboptimal and
guessing - which is not a good sign of a secure solution. Though this
may be needed for a communication between KC and non-KC, for KC-to-KC
communication, this type of guessing should be avoided if a valid way
exists.
On 10/31/2016 02:56 PM, John Dennis wrote:
On 10/31/2016 09:22 AM, Hynek Mlnarik wrote:
> The use case is to support key rotation with SAML, where the realm keys
> are used for signing the assertions, similarly to key rotation support
> for OIDC introduced in 2.3.0 ( KEYCLOAK-905). Hence the keys are bound
> to a particular realm (IdP to SP direction, SP verifies IdP's
> signature), and can be rotated at IdP on demand. IdP can provide
> multiple valid keys for the realm, e.g. current and previous
> certificates for signature validation to allow seamless key rotation.
> Hence key ID information needs to be included with the assertion/message
> to provide hint on which key was used for signing. For details, please
> see comments KEYCLOAK-1881 [including comments].
Yes, I understand the key rotation issue, what I don't understand is
why you need a key id. Both the SP and the IdP can identify the key
based on the entityID in the SAML message. In the case of key rotation
there is an ordered list of keys. You obtain the list based on the
entityID and iterate over the list trying each key in succession.
What value is there in sending the key id in the SAML message? It's an
optimization that only works if each party knows how to interpret that
value and to the best of my knowledge there is no interoperability
mechanism defined for this. Remember it's the receiving party that
must select the correct key to verify the signature or decrypt a
message. Only the sending party can insert the key id into the
message, so even if you included the key id I don't understand what
it's accomplishing because the receiving party would have to interpret
that value (the sending party which knows the key based on ID but it
would never see the key id in a message).
4:13 p.m.
On 10/31/2016 10:53 AM, Hynek Mlnarik wrote:
Fortunately, in the case where Keycloak is both signing and
validating so this condition is satisfied.
When is KC both signing a SAML message and validating the same signature?
Though this may be needed for a communication between KC and non-KC,
for KC-to-KC communication, this type of guessing should be avoided
if a valid way exists.
In SAML messages are one-way. There is KC-to-SP communication and
SP-to-KC communication. What is this KC-to-KC communication you refer to?
--
John
4:36 p.m.
Surely KC implements both SAML SP and IdP. I am afraid that in a strict
sense, there is also no KC-to-SP or SP-to-KC communiication. But by
natural extension of concepts, by "KC-to-KC", an IdP-to-SP communication
is meant where KC is implementor of both parts. SAML 2.0 is designed to
be extensible and allows Implementation specific extensions that are not
interpreted if the receiving party does not know how to handle them.
This is interoperable as long as the meaning of the original SAML
message retains the same meaning. Hints like key ID are hence valid use
of this extension.
Just for the record - SAML IdP is represented by KC server, SAML SP part
is handled by KC adapters.
--Hynek
On 10/31/2016 04:13 PM, John Dennis wrote:
On 10/31/2016 10:53 AM, Hynek Mlnarik wrote:
> Fortunately, in the case where Keycloak is both signing and
> validating so this condition is satisfied.
When is KC both signing a SAML message and validating the same signature?
> Though this may be needed for a communication between KC and non-KC,
> for KC-to-KC communication, this type of guessing should be avoided
> if a valid way exists.
In SAML messages are one-way. There is KC-to-SP communication and
SP-to-KC communication. What is this KC-to-KC communication you refer to?
6:14 p.m.
On 10/31/2016 11:36 AM, Hynek Mlnarik wrote:
Surely KC implements both SAML SP and IdP.
KC is mostly an IdP. The only case I'm aware of where KC operates as an
SP is when KC federates to another IdP (i.e. KC is an identity hub that
is configured to authenticate against other IdP's). For the optimization
you're discussing to be workable the other IdP must also understand the
key id usage (i.e. is another KC instance) *and* share the key id's.
That seems to me to be an uncommon deployment.
I am afraid that in a strict sense, there is also no KC-to-SP or
SP-to-KC communiication.
Really? SAML is mostly IdP-to-SP and SP-to-Idp communication.
But by natural extension of concepts, by "KC-to-KC", an
IdP-to-SP
communication is meant where KC is implementor of both parts.
See above.
SAML 2.0 is designed to be extensible and allows Implementation
specific extensions that are not interpreted if the receiving party
does not know how to handle them. This is interoperable as long as
the meaning of the original SAML message retains the same meaning.
Hints like key ID are hence valid use of this extension.
Sure, but I still don't understand when you could take advantage of this
(see above). How often do you think KC is going to federate to another
KC instance that shares the same key ids?
Just for the record - SAML IdP is represented by KC server, SAML SP
part is handled by KC adapters.
--
John
7 p.m.
Well, this discussion drove completely away from the original question.
I prefer to focus on resolving the actual issue.
Just to summarize:
1. In SAML, typically IdP to SP communication and vice versa is relevant.
2. KC implements IdP (server) and securing part of SP (adapter). Indeed,
it does not implement actual service provider's functionality, only the
part that in involved in SAML-related communication.
3. There are other IdP and SP SAML implementors than KC.
4. There is high chance, even though definitely not 100%, that KC IdP
would communicate with SP secured by KC-native adapter. Please see the
KC guide for further information [1].
5. KC SAML adapters should be able to take advantage of knowledge of key
ID to have signature validation performed using the right key on the
first try.
The original question was how to achieve Item 5 in terms of how to pass
the key ID - whether in SAML protocol message or outside of it.
Thank you
--Hynek
[1]
https://keycloak.gitbooks.io/securing-client-applications-guide/content/v...
On 10/31/2016 06:14 PM, John Dennis wrote:
On 10/31/2016 11:36 AM, Hynek Mlnarik wrote:
> Surely KC implements both SAML SP and IdP.
KC is mostly an IdP. The only case I'm aware of where KC operates as
an SP is when KC federates to another IdP (i.e. KC is an identity hub
that is configured to authenticate against other IdP's). For the
optimization you're discussing to be workable the other IdP must also
understand the key id usage (i.e. is another KC instance) *and* share
the key id's. That seems to me to be an uncommon deployment.
> I am afraid that in a strict sense, there is also no KC-to-SP or
> SP-to-KC communiication.
Really? SAML is mostly IdP-to-SP and SP-to-Idp communication.
Did I say anything
else?
> But by natural extension of concepts, by "KC-to-KC", an IdP-to-SP
> communication is meant where KC is implementor of both parts.
See above.
> SAML 2.0 is designed to be extensible and allows Implementation
> specific extensions that are not interpreted if the receiving party
> does not know how to handle them. This is interoperable as long as
> the meaning of the original SAML message retains the same meaning.
> Hints like key ID are hence valid use of this extension.
Sure, but I still don't understand when you could take advantage of
this (see above). How often do you think KC is going to federate to
another KC instance that shares the same key ids?
> Just for the record - SAML IdP is represented by KC server, SAML SP
> part is handled by KC adapters.
10:04 a.m.
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.
On 31 October 2016 at 18:14, John Dennis <jdennis(a)redhat.com> wrote:
On 10/31/2016 11:36 AM, Hynek Mlnarik wrote:
> Surely KC implements both SAML SP and IdP.
KC is mostly an IdP. The only case I'm aware of where KC operates as an
SP is when KC federates to another IdP (i.e. KC is an identity hub that
is configured to authenticate against other IdP's). For the optimization
you're discussing to be workable the other IdP must also understand the
key id usage (i.e. is another KC instance) *and* share the key id's.
That seems to me to be an uncommon deployment.
> I am afraid that in a strict sense, there is also no KC-to-SP or
> SP-to-KC communiication.
Really? SAML is mostly IdP-to-SP and SP-to-Idp communication.
> But by natural extension of concepts, by "KC-to-KC", an IdP-to-SP
> communication is meant where KC is implementor of both parts.
See above.
> SAML 2.0 is designed to be extensible and allows Implementation
> specific extensions that are not interpreted if the receiving party
> does not know how to handle them. This is interoperable as long as
> the meaning of the original SAML message retains the same meaning.
> Hints like key ID are hence valid use of this extension.
Sure, but I still don't understand when you could take advantage of this
(see above). How often do you think KC is going to federate to another
KC instance that shares the same key ids?
> Just for the record - SAML IdP is represented by KC server, SAML SP
> part is handled by KC adapters.
--
John
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
4:23 p.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
4:49 p.m.
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
> 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.
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
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.
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.
5:46 p.m.
On 11/01/2016 11:49 AM, Hynek Mlnarik wrote:
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.
By out of band I mean a non-standard exchange of information, not back
channel. So yes, the only standard way I know is via metadata.
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.
The recommendation is such messages be exchanged over a secure transport
such as TLS, since this is an HTTP-Redirect binding that means HTTPS.
That means all the query parameters are pretty safe. Even if the keyID
were modified by a nefarious actor what would the practical consequences
be? I suppose that might depend on how strict your implementation is,
here is the basic choices as I see them:
1) keyID lookup fails, you fail the protocol exchange.
2) keyID lookup succeeds but fails to validate signature. You fail the
protocol exchange.
However if either of the two above cases occur you could be more
forgiving and treat it as if no keyID had been passed and fall back to
iterating over the keys bound to the entity, something you have to
implement anyway because the keyID will often be absent.
The xmlSig spec is silent on what happens if the keyID (actually the
KeyName) does not produce a known key. It does not specify if one may
fallback to application specific context or not.
I personally feel it's OK to use application specific context, if one
accepts that then the keyID if present becomes a hint not a mandate.
In summary, I don't see tampering with the keyID a significant risk over
HTTPS or if it's treated only as a hint a serious problem that could be
used to compromise the communication.
--
John
2754
days inactive
2755
days old
12 comments
3 participants
participants (3)
-
Hynek Mlnarik -
John Dennis -
Stian Thorgersen